#ubuntu-devel 2005-09-05
<CarlFK> huh - reboot and now usb shows: 046d:092c Logitech, Inc.
<CarlFK> which is close to USB ID 046d:0920...
<CarlFK> oh good.  "Need to get 0B of archives."
<ogra> Kamion, still around ? 
<jordi> Does anyone know how the MoveToOFTC spec is progressing?
<jordi> Ubuntu/Canonical stuff is the only stuff I can't easily get rid of to be feenode free.
<kent> jordi, MoveToOFTC, what is that?
<jordi> https://wiki.ubuntu.com/GetOffFreenodeSpec?highlight=%28freenode%29
<Kamion> ogra: not really
<Nafallo> jordi: wasn't that denied? :-)
<Kamion> ogra: I'll read messages later
<jordi> Nafallo: dunno.
<jordi> It'd be sad.
<Seveas> jordi, it's not progressing at all
<ogra> Kamion, i just wanted to ask if you could have a quick look at the daily build script, it has stopped yesterday it seems
<Seveas> in fact, Ubuntu is in the progress of registering as a group on freenode
<jordi> because it'll totally defeat my struggle to get off this network
<jordi> Seveas: urgh.
<ogra> Kamion, for edubuntu indeed
<bob2> bah
<mdz> ogra: are you sure you have the same versions of everything on ltsp and the local install?
<bob2> the battery applet stopped noticing that I have ac power
<bob2> so I was fairly convinced my power supply was screwed until I ran "acpi -V"
<ogra> i upgraded my local install before testing, the ltsp install is from this afternoon
<bob2> also, -V = --version, kthxbye
<ogra> so i'd suppose yes, the version is the same...
<ogra> but i run a amd64 laptop as client... it could be arch specific
<Kamion> ogra: this morning's build didn't happen because mdz was running a manual build at the time
<ogra> (ltsp == i386, local == amd64)
<mdz> ogra: wait, you are talking about two different machines?  if so, that isn't surprising
<Kamion> ogra: it'll happen tomorrow assuming the same thing doesn't happen again
<ogra> mdz, nope i talk about my laptop being used in i386 mode
<Kamion> there's nothing actually wrong with the cron job
<mdz> I thought you meant it was different on the same hardware as an LTSP client vs. a standard boot
<ogra> Kamion, ok, just wanted to be sure to have a CD to look at tomorrow :)
<mdz> Kamion: is there any particular reason that the daily builds are all scheduled separately?
<mdz> Kamion: rather than just running everything sequentially starting at a given time
<ogra> mdz, its the same HW, but different SW on top... 
<mdz> ogra: try it with the same software
<Kamion> mdz: not really, historical
<ogra> hmm...
<Kamion> plus I think different people wanted them at different times originally
<ogra> do we have working liveCD builds currently?
<Kamion> it would be quite irritating to have to wait for a load of jobs to complete before starting a manual one, though, rather than just waiting for one
<Kamion> I think a master job would want to leave some space in betwen
<Kamion> between
<ogra> hey AndyFitz 
<AndyFitz> g'day ogra
<AndyFitz> ready for another drop ?
<ogra> any news on the icon front ?
<Nafallo> morning AndyFitz :-)
<ogra> yeah, absolutely
<AndyFitz> morning Nafallo
<AndyFitz> ogra,  great I'll email you the tarball
<ogra> yeah
<ogra> AndyFitz, did you follow the latest ML thread ? 
<ogra> i'm not sure if i like the idea of a fullscreen splash...
<ogra> especially since it doesnt scale... you'll need a huge pic 
<mdz> ogra: the current i386 live build works (or the most recent one I tried)
<AndyFitz> holy crap. that was a splash ?  I only had time to look at the picture.  I thought it was a GDM login 
<ogra> mdz, just downloading to test with it... but it looks like it will take some hours, i have no live to rsync here
<ogra> AndyFitz, nope that was a proposal for a fullscreen splash
<AndyFitz> I do like apple's policy of taking a snapshot of the desktop (and each blank application window ) and loading it next time to hide all that yucky widget loading in the background 
<AndyFitz> ogra,  I'll try one at my resolution and see if it works  ( I'm kinda scared )
<ogra> yes, i think the splash has to be something around 2048 width at least... 
<ogra> to cover all resolutions...
<ogra> this will load slooow
<opi> Rosetta is additive
<mdz> ogra: what are the edubuntu blockers for preview?
<ogra> mdz, sorting the preseeding ... i didnt want to abuse Kamion today already but have it on my list for tomorrow...
<mdz> ogra: what needs to be changed with the preseeding?
<mdz> ogra: everything else works?
<ogra> mdz, edubuntu-server is not in the default install, ltsp-build-client should run automatically, postfix should be preseeded for local transport only
<ogra> mdz, additionally the current default should move to an optional workstation install
<ogra> mdz, edubuntu-artwork isnt completely sorted since i have to sort out which license it has to be under (almo is on it with sabdfl)
<ogra> s/almo/elmo
<mdz> ogra: postfix?
<ogra> mdz, yes, something depends on it... i'll have to touch the server seed anyway, i'll look if i can get rid of it
<mdz> ogra: don't install postfix by default
<ogra> mdz, how do i supress it if a server package depends on it... 
<mdz> ogra: you fix the server package
<ogra> let me look which, one second
<mdz> or don't install it
<Burgundavia> jdub, are the p.g.o rss feeds dead?
<ogra> mdz ok
<ogra> mdz, mysql ... 
<mdz> ogra: fix it or don't install it; we don't want an MTA by default
<ogra> mdz, but that can go since we dont have mediawiki and moodle works with either postfix or mysql... i preferred postfix from the start...
<pitti> ogra: sure that you don't mean postgresql?
<mdz> postfix or mysql?
<ogra> pitti, err, yes
<ogra> mdz, i meant postgres... sorry
<mdz> ogra: you meant postgresql from the beginning? or only in your last sentence?
<ogra> only in the last sentence
<ogra> mysql depends mailx, mailx depends <anymailserver>
<ogra> that draws in postfix... i'm just changing the seed
<AndyFitz> ogra,  unless there is a way to size the splash resolution from the gnome-set resolution   the login splash is absurd
<ogra> yup
<AndyFitz> I'll be right back
<ogra> sabdfl, wb
<sabdfl> breezy update went fine. well done guys
<sabdfl> now running warty->hoary->breezy
<pitti> sabdfl: does hal run properly after you rebooted your box? elmo did a h->b upgrade today, which broke
<mdz> mako: do you have some clarity on the input method situation yet?
<mdz> sabdfl: if you have an IDE disk, check that you didn't end up with DMA disabled
<sabdfl> mdz: how do i check?
<sabdfl> pitti: hmm... /etc/init.d/dbus restart shows hal restarting
<sabdfl> but
<zyga> pitti: if you have a moment I'd like to ask you about an issue with various .po files I tried to explain yesterday
<sabdfl> on loging, i get a dialog warning abut not being able to talk to HAL
<pitti> sabdfl: $ sudo hdparm /dev/hda
<pitti> sabdfl: you get that dialog before or after restarting dbus?
<sabdfl>  using_dma    =  1 (on)
<sabdfl> pitti: after a reboot
<bob2> is dbus still restartable at all?
<sabdfl> on login
<sabdfl> hey bob2!
<ogra> bob2, why shouldnt it ? 
<sabdfl> restarting dbus gives 4 [ ok ] 's
<pitti> sabdfl: ok, I ask because many apps don't reconnect to hal after you restart it
<ogra> bob2, its not nice to do it... but you can :)
<pitti> sabdfl: ok, so it wasn't running properly after system boot?
<bob2> ogra: I saw talk on the dbus list of not supporting it at all
<pitti> sabdfl: this sounds like elmo's problem, I try to reproduce it tomorrow
<bob2> heya sabdfl
<pitti> sabdfl: thanks
<ogra> bob2, yes, in the future... currently you can still do it.. and things like network-manager do it by default for example...
<bob2> ah, I see
<pitti> bob2: right, we eventually gave up restarting it automatically on upgrades since all of the upstreams are against us
<pitti> and we can't patch the world
<bob2> yeah :|
<mdz> mako: all I have ever seen so far is "this works for my use case"
<pitti> ogra: no, don't; you will break the desktop if you restart dbus now
<ogra> pitti, we can, we are just not enough yet :)
<ajmitch> pitti: ouch - restarting dbus is needed for more & more stuff :(
<ogra> ajmitch, nope
<ajmitch> ogra: no?
<ogra> ajmitch, the opposite is right
<pitti> ajmitch: don't, at least not in breezy
<mdz> pitti: er, so upstream expects that whenever dbus is upgraded, the user must reboot?
<ajmitch> ogra: the opposite just doesn't work in some cases
<mdz> that seems arrogant
<pitti> mdz: yes, sadly
<bob2> mdz: yes
* lamont -> home
<ajmitch> ogra: take avahi for example - dbus won't pick up the new avahi info when it is installed
<pitti> mdz: there was a long and heated discussion about it, and we tried to defend our strategy
<bob2> it seemed to be a SuSe guy in favour of it
<ogra> ajmitch, at least for registering new services it works
<pitti> mdz: eventually we got gnome-volume-manager and update-notifier right
<bob2> guess they're not used to incremental upgrades ;)
<ogra> ouch
<ajmitch> ogra: I prefer not to get involved in such things, really :)
<pitti> mdz: but that still left us with a plethora of dbus-using apps that don't reconnect
<pitti> ok, good night guys; I'm terribly tited
<pitti> tired, even
<bob2> seeya, pitti
<pitti> d'oh
<jdub> pitti: night :)
<ogra> night pitti 
<bob2> hehe
<jdub> GOOD MORNING FREEDOM LOVERS!
<pitti> Hi jdub
<ogra> morning jdub
<bob2> jdub: de-ensconse yourself
<ajmitch> morning jdub 
<sabdfl> mdz: will call now
<_derek__> mdz: are you around?
<mdz> _derek__: yes, but about to receive a phone call
<_derek__> mdz: alright, no biggie, let me know when you have a minute
<pef> I leave, good night !
<jdub> jbailey: around?
<_derek__> anyone know what wnck-applet is? or what package its in?
<ogra> gnome-applets ? 
<_derek__> ogra: so thats in main not universe?
<ogra> most liekly, yes
<_derek__> so i don't think thats fubaring my comp
<ogra> some people call it the tasklist ;)
<ogra> or bar...
<_derek__> call what the tasklist?
<_derek__> oh
<_derek__> wnk-applet
<_derek__> gotcha
<_derek__>   can anyone post what a normal .xsession-errors should look like?
<bob2> ideally empty
<_derek__> hmmm, ideally, yes, in practical implementations is it?
<opi> or with some warning if you try to use unsupported modules
<opi> mostly warnings
<_derek__> according to mdz, mine looks like it started x normally, but i have a lot of errors
<bob2> X itself doesn't say anything there
<bob2> s/X/the X server/
<ogra> that goes to /var/log, but stops if the X server is up
<_derek__> hmm, my /var/log shows it being up, so what would the xsession-errors pertain to?
<_derek__> just gdm?
<ogra> your X session...
<ogra> no matter if gdm, kdm or xdm ;)
<bob2> X clients
<_derek__> hmmm, ok
<_derek__> what do errors like this mean:
<_derek__> _IceTransTransNoListen: unable to find transport: tcp
<_derek__> _IceTransmkdir: ERROR: euid != 0,directory /dev/X will not be created.
<_derek__> _IceTransmkdir: ERROR: Cannot create /dev/X
<bob2> is /tmp normal?
<_derek__> are you asking me? i have no idea if it is or isn't
<ogra> i wonder what app needs tcp for a X connection... tcp is disabled by default ...
<bob2> I was guessing that /tmp might be trashed
<bob2> so ICE went to using tcp instead of a fifo
<ogra> so this error is normal, but there obviously is a bug in an X app
<bob2> or socket or whatever
<_derek__> bob2: how do i fix that?
<ogra> ah, as fallback you mean
<bob2> yeah
<ogra> _derek__, look if /tmp or the partition holding it is full
<_derek__> ogra: as in tmpfs?
<bob2> no
<_derek__> cuz i have one partition
<bob2>  /tmp is by default on /
<_derek__> and that has 30gigs free
<_derek__> yeah
<bob2> and ls -ld /tmp
<_derek__> _IceTransTransNoListen: unable to find transport: tcp
<_derek__> _IceTransmkdir: ERROR: euid != 0,directory /dev/X will not be created.
<_derek__> _IceTransmkdir: ERROR: Cannot create /dev/X
<_derek__> sorry for the wront c/p
<_derek__> drwxrwxrwt  10 root root 98304 2005-08-30 19:44 /tmp
<_derek__> bob2, ogra does that look ok?
<ogra> yup
<_derek__> so now i basically have to go one by one removing packages from universe until i find it?
<_derek__> what is causing it?
<bob2> er, no
<_derek__> bob2: mdz reccomended removing all universe apps
<bob2> hah
<_derek__> bob2: i really didn't want to do that
<_derek__> bob2: so what do you have in mind?
<bob2> strace'ing things until you find it
<bob2> or poking /tmp more
<bob2> good luck
<_derek__> stracing? 
<bob2> the magic of strace
<desrt> is there a registration fee for BelowZero?
<Burgundavia> desrt, no
<desrt> so what's this "sponsorship" deal?
<Burgundavia> desrt, funding people to get there and stay there
<desrt> ahh.  that's very generous
<desrt> thanks for the info
<_derek__> bob2: what do you mean by poking /tmp? i don't know what i am looking at in here
<_derek__>  ogra, are you still around?
<ogra> partially..
<_derek__> are you able to give me anymore guidance
<ogra> i have no idea what is causing it... i suspect a broken app... most likely from universe...
<_derek__> ogra: would that show up in my ps aux?
<ogra> you seem to have something running that needs a tcp X connection which is wrong...
<ogra> probably...
<mdz> _derek__: please take this to #ubuntu
<_derek__> mdz: ok
<ogra> whee, powerpc looks bad on the daily report ...
<Nafallo> ogra: royal had no harddrive space a while :-)
<ogra> yup
<reb> can anyone tell me why metacity is dying on breezy?
<reb> can't log into gnome, kde, xfce work fine
<Nafallo> it isn't here :-)
<ogra> it reflects very well in the daily build report of edubuntu here... 56 uninstallable packages for ppc
<bob2>  /topic
<reb> err sorry
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<mjg59> Robot101: I believe so
<Robot101> mjg59: and the RTC?
<mjg59> Robot101: Not yet
<lunitik> just out of curiosity... are there technical reasons why Ubuntu still uses discover1 (1.7.6) when discover is at version 2.0.4?
<lunitik> (2 seperate packages)
<lunitik> discover 2.x is supposed to be much better... perhaps it will be more successful with soundcards?
<jdub> lunitik: we don't really actively use discover at all
<lunitik> jdub: I thought it was still used during install?
<lunitik> hmm... one more thing... Davyd states in his preview of 2.12 that GNOME includes a clipboard feature now... however this doesn't seem to have gotten into Ubuntu... why is this?
<daniels> lunitik: (btw, we only use discover1 to pick which video card to use, that's it)
<lunitik> daniels: oh... many people (including myself with my old box) had issues with snd-via82xx with discover1 ... don't recall any issues with discover... this is why I brought it up...
<lunitik> Seems almost all sound card issues in the help channel are related to that module though... at least 4-5 people in the last day have had the issue... no other cards seem to have this issue though afaik
<jdub> lunitik: it is in breezy
<jdub> lunitik: it's not a clipboard manager in the gui sense of the word
<lunitik> jdub: I'm using Breezy... if it is there... its certainly not working....
<daniels> lunitik: then it's nothing to do with discover vs discover1, because we use hotplug for that.  that being said, snd-via82xx always worked fine for me in my i386.
<lunitik> (I just closed firefox, wanting to copy text to my Gaim convo... and it didn't work...)
<lunitik> daniels: worked fine for me about 90% of my installs also... however, sometimes I encountered issues... and others are having simular ones...
<daniels> lunitik: specific bug reports would be nice, because 'sometimes I encountered issues, and others are having similar ones' isn't really that helpful tbh
<lunitik> daniels: certainly, someone with the technical know how might want to look into it... 4-5 people in one day with the same issue is probably not a good sign  :)
<lunitik> daniels: basically... according to all things you can look at... it _should_ have been working... /dev/dsp was there... user in audio group... module loaded etc... but no sound... hard to give further details when it appears there aren't any  :(
<bddebian> Any C++ guru's awake?
<infinity> Who is our resident java toolchain guru?
<elmo> jbailey and wasabi
<jdub> elmo's version of "NOT ME!"
<bddebian> Heh
<jbailey> infinity: Is this something worth staying awake for?
<jdub> jbailey: oh, just to mention that scsi seems to be a sticking point in general for initramfs atm
<jdub> jbailey: had some comments from vmware about it
<bddebian> jbailey: No, but I'm sure mine is! ;-)
<jdub> jbailey: we should hook up for that sysfs testing you watned to do
<jdub> at a more appropriate juncture :)
<jbailey> jdub: Right. There's a bug about vmware that's assigned to benc.  I don't have the number handy.  But it's to make the BusLogic PCI bits in the kernel actually provide a pci mapping.
<jdub> aha, that'd be it
<jbailey> jdub: Yup, had a friend over this evening.  About 4 hours before this time tomorrow work for you?
<jdub> yeo
<jdub> yep
<jbailey> jdub: Your SATA stuff not working bothers me, since my SATA works.
<jbailey> And the drivers do appear to be present.
<jbailey> Oh well, sleep now.
<jdub> night!
<fabbione> morning
<bddebian> Hello fabbione 
<fabbione> jbailey: eh no.. you can't go to sleep before i wake up :)
<infinity> jbailey : No, I'll bug wasabi instead. :)
<elmo> nobody   19279  119  0.5  33720 20452 ?        R    04:39   0:02  \_ /usr/bin/rsync --no-detach --daemon --config /etc/rsyncd.conf
<elmo> okay, what kind of math is that?
<elmo> 119% CPU?
<fabbione> meh..
<robitaille> elmo I have a laptop with a battery fully-charged at 118%.  Must be Ubuntu's fuzzy math...
<infinity> elmo : multiple CPUs, each accounting for 100%?
* netjoined: irc.freenode.net -> calvino.freenode.net
<infinity> mdz : ping.
<mdz> pong
<infinity> Do you still maintain the whole mythtv dependency chain?
<mako> mdz: on a certain level all we're every going to get is "this works for my case" in terms of input methods
<infinity> mythgallery and mythmusic never got updated for the new mythtv dev packages.
<mako> mdz: i think we should settle for the best integration with the range of libraries available and with gnome (and kde also if possible)
<mdz> mako: for breezy I think it's too late for anything other than "this is the one true course we can all agree on"
<mako> at the moment, that's SCIM, but every language is still going to need to be solved one-by-one.. sometimes more than once
<mdz> mako: I don't think we should start bundling random packages because someone likes them, not now
<jdub> IIIMF seems to be 'teh future'
<mdz> infinity: depends on your notion of "maintain"
* mako nods to jdub
<mako> the problem is that almost none of these solutions are mutually exclusive
<mdz> infinity: I "maintain" them in my "spare time"
<infinity> Yeah, I don't know anyone who uses Chinese inputs, so I have no hard data there, but SICM seems to do the job for japanese input.
<mako> infinity: well, japanese with a backend.. often anthy
<infinity> mdz : Right.  Any guesses about how badly they'll blow up if I just change the build-deps to use the new -dev packages, rather than finding 0.18 upstream sources for them?
<mdz> infinity: badly
<infinity> mako : Yes, SCIM+anthy was what was tested here with some success.
<mdz> infinity: fortunately, I already packaged the new versions and they just need syncs
<infinity> mdz : Ahh.  Cool.
<mdz> infinity: deb-src http://dijkstra.csh.rit.edu/~mdz/debian unstable mythtv
<mdz> some of the ones that I don't use aren't quite right.  I need co-maintainers.
<infinity> mdz : I don't see mythmusic and mythgallery there.  Are they deprecated, or lacking round tuits?
<mdz> infinity: they should be there
<mdz> infinity: well, mythgallery is a round tuit I tihnk
<mdz> infinity: mythmusic has binaries but no source
<infinity> Right, then.  I'll just leave them FTBFS for now.  Maybe you can poke an MOTU to do your dirty work for you. :)
<mdz> infinity: all this interest in mythtv; want to be a co-mainatiner *nudge* *wink*
<infinity> Is it non-free for reasons I'd have moral objections to, or just crazy patent issues or osmething similar?
<infinity> I've been meaning to play with it at home, so I suppose if I actually find it useful, I could sign up.
* bur[n] er assumes non-free due to codec things?
<jdub> does hppa not have a functioning installer?
<jdub> in debian or ubuntu?
<jdub> hrm, no there appears to be images on the debian site
<jdub> weird
<infinity> It works fine in Debian.
<infinity> As an SCC in Ubuntu, I have no idea what its status is, but you should ask lamont if you're curious.
<jdub> yeah
<jdub> infinity: "port" :)
<infinity> Tomato, Tomahto.
<jdub> marketing nous, marketing mouse :)
<pitti> Hi
<pitti> infinity: any chance to get some security builds on *any* powerpc buildd?
<sabdfl> daniels: good news, laptop hoary -> breezy update went fine, X Just Worked (tm)
<tepsipakki> should usb card readers work out-of-the-box, ie. if I plug a card in it gets mounted?
<daniels> sabdfl: excellent news
<sabdfl> tepsipakki: yes, i believe so, file a bug and ping pitti if not
<daniels> sabdfl: still having trouble with fglrx?
<sabdfl> he will likely want to know the low-level usb and card details
<sabdfl> daniels: yes
<daniels> sabdfl: okay, I'll kick ATI
<pitti> tepsipakki: right, they should; http://wiki.ubuntu.com/DebuggingRemovableDevices
<sabdfl> daniels: here's the situation
<sabdfl> the new ATI package creator was smooth
<pitti> tepsipakki: would be nice if you could do the steps there and file a bug (or just mail me the files)
<sabdfl> except that i still had to compile the kernel source separately
<tepsipakki> pitti: ok, so there's some daemon polling on them, because plugging the card does not create any usb-event.. ?
<tepsipakki> pcmcia-reader seems to work just fine ;)
<pitti> tepsipakki: yes, hal polls those devices to notice an insertion
<tepsipakki> ok, will look into it
<pitti> tepsipakki: you have a really up to date breezy?
<daniels> sabdfl: interesting, that should Just Happen as part of the process
<pitti> tepsipakki: I fixed some hotplug bugs recently
<tepsipakki> updated yesterday
<sabdfl> daniels: now, i have kernel module 8.16, and xorg-driver-fglrx 8.16
<Lathiat> does the l-r-m stuff not work?
<sabdfl> it starts fine, but I've noticed two problems
<sabdfl> hmm... two problems, and a possible third
<sabdfl> the first is that GL is not native,it's mesa
<daniels> seb128: morning sabarino
<sabdfl> i looked at dpkg -l libgl1-mesa
<pitti> tepsipakki: that should be recent enough :-)
<sabdfl> and noticed that the main libraries were diverted but the optimised ones were not
<sabdfl> so i diverted them manually
<daniels> sabdfl: hmm, they should be providing their own /usr/lib/libGL.so.1.2
<daniels> sabdfl: oh, right! optimised builds.  blah.
<sabdfl> daniels: yes. so please could you make fglrx divert the optimised ones too?
<sabdfl> and nudge ati with that bug?
<sabdfl> however,
<seb128> hey daniels pitti sabdfl
<pitti> seb128!!!
<pitti> welcome back
<seb128> thanks ;)
<sabdfl> sebmaster!
<tepsipakki> pitti: lets hope its just some pseudo-user missing (yes, we have a perverse system for those)
<pitti> seb128: you cheated, you uploaded some packages yesterday :)
<sabdfl> daniels: even diverting them locally did not bring up GL however
<daniels> sabdfl: sure
<daniels> sabdfl: oh, interesting
<sabdfl> i'm not sure why
<pitti> tepsipakki: might be
<daniels> sabdfl: actually, I think I have a fair idea
<daniels> sabdfl: try dropping back to xserver-xorg 6.8.2-53
<sabdfl> what's that?
<daniels> sabdfl: i've pinged them about that problem too
<sabdfl> daniels: i won't have time to do that, but if you could fix it in today's upload i'll test it tonight
<sabdfl> so, second issue
<sabdfl> DRI is inactive
<sabdfl> disabled
<sabdfl> in the Xorg.log.0 it talks about disabling it because it found DRI version 5.0.0 and was expecting 4.x
<seb128> pitti: yeah, but all this shiny GNOME tarballs ... :p
<sabdfl> which is interesting because it's their kernel driver, and their xorg driver, so i would think the version expectaction would be consistent
<sabdfl> any idea?
<pitti> seb128: I know that you can't resist the temptation
<desrt> seb128; odd metacity crashes that go away when i dpkg-buildpackage from the sources for myself
<sabdfl> desrt: it's the magic hand waving ;-)
<desrt> seb128; basically, metacity crashes outright whenever a error dialog pops on the screen.  i see this with 'applet has quit unexpectedly dialogs'... tberman gets it when gaim tells him he got disconnected from the server
<sabdfl> seb128: rhythmbox is crashing on breezy, is that a known issue?
<Lathiat> desrt: yeh theres a bug about that
<Treenaks> desrt: Gaim "You've been invited to <jabber channel>" dialogs make metacity crash too
<Lathiat> desrt: ive been meaning ot get a more usefull backtrace
<Lathiat> Treenaks: gajims do it too
<Lathiat> as do variosu other dialogs
<Lathiat> i rebuilt it with nostrip and its harder to make happen
<desrt> Lathiat; i have a bug on gnome.org about it.  is there an ubuntu #?
<daniels> sabdfl: right, the server has 5.0.0, but their client library is 4.0.x
<daniels> sabdfl: there's no real difference though, so I've asked them for a recompile
<desrt> ubuntu #14145
<sabdfl> daniels: and the third problem is  this
<sabdfl> the new driver/kernel mod comes up nicely on startup
<sabdfl> but after X starts I'm unable to swtch to VT1-6
<sabdfl> if I tr, the screen goes black
<jdub> yo seb128!
<sabdfl> then DPMS kicks in and it switches off
<sabdfl> hey jdub
<jdub> seb128: what do you think about reverting evo?
<jdub> hey sabdfl 
<seb128> sabdfl: yep, will be fixed within 1 hour with the new GTK
<seb128> jdub: reverting?
<daniels> sabdfl: hrm.  i think there's a bug open about that one upstream.
<seb128> jdub: hey hey :)
<jdub> seb128: going back to 2.2
<daniels> sabdfl: i'll get together with them when they get into the office this morning.
<seb128> desrt: weird
<seb128> jdub: no way, why?
<jdub> seb128: luis and i have been talking about doing it upstream, too
<rob^> jdub, whats wrong with 2.3?
<jdub> seb128: it's, ah, not wonderfully stable
<fabbione> desrt: what happen if you build it in a clean chroot?
<seb128> jdub: 2.2 neither
<desrt> fabbione; hmmmm...?
<desrt> fabbione; i -just- installed colony 3 tonight
<jdub> seb128: ok, gotta go for a while, back later
<Lathiat> has anyone noticed when replying to messages, sometimes you get a blank quote, sometimes you get somethign like a 'g' and soemtimes get the message? (evo)
<seb128> jdub: k
<fabbione> desrt: can you compare the build log from the one you do yourself and the one on the buildd?
<seb128> Lathiat: maybe you select something? it quotes the selection
<desrt> sure
<fabbione> desrt: there might be a slighly difference, and spot the reason
<rob^> Lathiat, no
<desrt> personally, i'm suspicious that the ubuntu build cluster is cursed :)
<desrt> will dpkg-buildpackage generate a log or do i redirect stdout/err?
<Treenaks> desrt: Bring in the holy water & virgin blood!
<pitti> Hi JaneW 
<desrt> fabbione; k.. seriously... 1) where do i get the buildlog from the official package and 2) how do i make one for me?
<fabbione> desrt: you do dpkg-buildpackage > log 2>&1
<desrt> fabbione; you can do &>
<fabbione> desrt: official logs are at: http://people.ubuntu.com/~lamont/buildLogs/
<desrt> thanks :)
<fabbione> desrt: whatever ;)
<pitti> Moin mvo
<mvo> hey pitti 
<mvo> good morning all
<seb128> hey mvo
<desrt> this is a job for meld!
<mvo> hey seb128, wb
<mae> oooo I like the new usplash except on dual monitor the right screen is skewed :\ maybe thats just my CRT
<mae> wasn't like that with text mode
<hunger> mae: And it does not handle user input gracefully either,
<mae> hunger, :) well nonetheless I think it is _very_ nice for the amount of time it was put together in
<hunger> mae: I thought my box had hanged when nothig happened... I just had to switch to the proper VT to get to the input.
<mae> and a much more elegant solution than the graphical boot of fedora where it launches a whole x-session
<mae> it will be polished :d
<desrt> fabbione; only superficial changes
<hunger> mae: I am sure of that!
<desrt> fabbione; like the names of my directories are different than the ones used on the build
<desrt> fabbione; otherwise the same... right down to the warnings that gcc throws
<fabbione> desrt: hmm weird
<desrt> more like 'evil'
<desrt> looks like i may want to set me up one of these chroot thingies
<pitti> argh, toshset debconf foo on hoary->breezy
<pitti> mjg59: here?
<mdz> fabbione: the live cd builds are in progress
<mdz> I probably won't stay awake until they finish, but the live builds are fairly foolproof
<fabbione> mdz: yes.. i read that on #u-k
<sabdfl> daniels: can we catch up quickly by phone?
<mdz> when 20050831.1 appears on cdimage, they will be OK
<fabbione> mdz: fine.. thanks
<daniels> sabdfl: 'kay
<mdz> fabbione: which can you test
<mdz> ?
<fabbione> mdz: i can test both as soon as they appear.. both install and live
<mdz> fabbione: I mean which architectures?
<mdz> I haven't started an install CD build yet
<fabbione> only i386
<fabbione> i don't have any others here...
<mdz> ok
<fabbione> and we don't build sparc .. so
<sabdfl> daniels: 0210 or 8445?
<mdz> we can't do parallel builds yet, so the install needs to wait until live is finished
<fabbione> mdz: i will probably buy a ppc in not too long from now...
<fabbione> yeps.. i know
* fabbione needs a new laptop
<daniels> sabdfl: 8445; 0210 doesn't get to me at all anymore
<mvo> mdz: I can test i386 and amd64 
<mdz> elmo: can we replace little with the same class of box that jackass is now?  :-P
<pitti> daniels: file conflict between xrgb and xorg-common (/etc/X11/rgb.txt); known bug? it breaks the hoary>breezy upgrade
<mdz> pitti: #14340
<sivang> morning all
<pitti> mdz: ok, thanks
<pitti> Hi sivnag
<pitti> sivang, even
<sivang> pitti: =)
<mae> what would cause both sound-juicer and rhythmbox to both crash on startup, could it be that the current gstreamer in breezy is borked?
<seb128> sivang: hi, what have you changed on gnome-panel?
<seb128> mae: GTK bug, will be fixed RSN (new package is building atm on my box)
<mae> seb128, ahh fixed in gtk 2.8.3?
<seb128> should be
<mae> seb128, thats a relief, breezy was all working but i was really bummed i couldn't "juice" an album i just bought :0
<seb128> we will be sure when the new version is here
<sivang> seb128: I added launchpad integration to context menu of panel itself and applets that come in gnome-panel pkg
<mae> :)
<Treenaks> mae: there's always cdparanoia -Bvs ;)
<sivang> seb128: how was your vacation?
<mae> Treenaks, bleh, I am too used to using sound-juicer
<seb128> sivang: have you pinged an usuability guy about that? (just curious)
<daniels> pitti: already fixed
<mae> i could brave using grip but i don't want to spend 30 mins configuring all the options how i want them.
<rob^> is there something we need to do to enable usplash?
<pitti> daniels: hm, then apparently not yet on today's CD
<pitti> daniels: but that's fine, thanks
<daniels> pitti: probably not; no worries
<sivang> seb128: hrm, no, I'm sorry I probably had to ask jamesh before ...
<daniels> pitti: you have a new upload hitting the really-old suite soon, too
<pitti> ah, great
<mae> just what is the "launchpad" what component is everyone referring i see this all over ubuntu.com
<pitti> daniels: btw, our powerpc buildds are very unhappy, also with other uploads...
<pitti> out of memory, or something like that
<seb128> sivang: jamesh is not an usuability guy afaik, that's just you make the context menu complicated by putting new items here
<seb128> sivang: and that was not a part of the spec 
<Lathiat> mae: launchpad.net
<daniels> pitti: ouch
<sabdfl> mae: http://launchpad.net
<mae> ic
<sivang> seb128: Well, I discussed patching the context menu with you, and we can get it off easily...just drop my patches
<mae> is this like, (bugzilla meets gettext meets web-revision-control)-ng
<sivang> seb128: (I don't recall you were opposing this, and if you did, I'm sorry I've probably missed that)
<mae> or close :)
<seb128> sivang: yeah, and I said I'm not convinced that's the right thing to do ... but whatever, let's wait for bugs
<Treenaks> mae: nice tagline ;)
<mae> hehe
<tepsipakki> pitti: I think I found the culprit.. hal is not in plugdev-group ;)
<pitti> ouch
<pitti> tepsipakki: how did you install that machine?
<tepsipakki> netboot
<mae> bah! no wonder bugzilla.ubuntu.com seems so stagnant *just found out about launchpad*
<tepsipakki> pitti: thats our fault
<pitti> tepsipakki: I mean, clean breezy install or any upgrade?
<sivang> seb128: who can we discuss this futher? I mean, I think the panel should be one clickable to launchapd, but if context menu is not the right thing, let's ask an expert , who are the other usability guys?
<pitti> tepsipakki: you don't use /etc/groups?
<tepsipakki> pitti: clean, but I mean that the passwd/group -files are rdist'd
<seb128> sivang: mpt?
<pitti> humm
<pitti> tepsipakki: so adduser doesn't do anything on your system?
<pitti> tepsipakki: that will break a whole lot of other things
<seb128> mae: "stagnant"? ;)
<sivang> seb128: k, I'll talk to him
<seb128> thanks
<mvo> is NM supposed as our long-term solution for dialup too?
<tepsipakki> pitti: well, basically yes, but I've tried to make sure every pseudo-user is there
<mae> err.. well actually nevermind no one seems to be using launchpad for bug tracking on breezy
<tepsipakki> pitti: those files are created right after base-install, so adduser notices that hal is already there ;)
<seb128> mvo: query doesn't work?
<mae> gosh bugzilla needs a facelift though..
<seb128> mvo: probably yep
<tepsipakki> pitti: but yeah, it sucks right now. uids<200 should be left to the system
<pitti> tepsipakki: oh, I see; but it tries "adduser hal plugdev" separately
<Mithrandir> doko: why?  ia32-libs-openoffice.org is useful for ooo1 as well, and that doesn't require lib32gcj6.
<seb128> arg
<mvo> seb128: thanks
<pitti> tepsipakki: < 1000 actually
<seb128> "* Unregistered users cannot currently send private messages due to spambot problems. please register! ( http://freenode.net/faq.shtml#nicksetup )"
* seb128 kicks freenode
<mae> get registered :)
<sivang> lol
<mae> I bet asuffield did that, hes a jerkoff
<ivoks> and, what would registration accomplish?
<tepsipakki> pitti: well, for real-users of course, but pseudo-users live under 1000
<ivoks> we would have registred spamers :)
<mae> hehe
* desrt becomes annoyed
<mae> actually i'm glad they did that, yesterday i was idling about 10 hours came back with about 50 spambots msging me with porn links
<mdz> fabbione: daily-live build finished
<fabbione> mdz: perfect.. rsyncing now
<desrt> seb128; it's perplexing that 2 official ubuntu releases in a row have the same problem, yet a dpkg-buildpacakge locally fixes it
<Treenaks> desrt: the dailies aren't "official releases"
<mdz> fabbione: install CDs are building now, but will take some time (jigdo etc.)
<Treenaks> at least, not in the "it's supported" sense
<fabbione> mdz: sure.. no problem
<seb128> desrt: what pb?
<desrt> seb128; the metacity thing
<seb128> desrt: weird yep
<desrt> i'm definitely too tired to think about it anymore.  nite :)
<seb128> desrt: have you sent a backtrace upstream ?
<seb128> 'night desrt
<desrt> seb128; ya
<desrt> seb128; but they think it's ubuntu's fault :)
<seb128> desrt: why ?
<crispin> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=314442
<seb128> desrt: bug number ?
<desrt> seb128; because it only happens to breezy users
<desrt> ya.  what he said :)
<seb128> and nobody can get a debug backtrace?
<seb128> that would be useful :)
<desrt> nobody can get a non-official build to crash
<desrt> even vanilla
<desrt> nevermind with debug symbols
<Mithrandir> seb128: is it a known issue that evince eats loads and loads and loads and loads of CPU time?
<mvo> and crashes all the time?
<desrt> anyway.  good luck :)
<pitti> hm, is there any reason to keep mozilla-firefox in universe?
<seb128> Mithrandir: not by me, or that's somewhere with the 300 bug mails I got since saturday
<seb128> mvo: what crashes?
<mvo> evince 
* desrt has an evince crasher filed against breezy too :P
<seb128> too many bugs for me; GNOME guys please go upstream
<mvo> seb128: it crashs on quite a few of the documents I use
<seb128> (note for desrt by example)
<desrt> seb128; again -- bug doesn't occur upstream
<seb128> thanks ;)
<Mithrandir> seb128: heh, sorry, forgot you're backlogged. :-)
<mvo> seb128: dholach will visit me today, I'll kick him to do bug triage :)
<desrt> seb128; lending to my belief that the ubuntu buildservers are cursed :)
<mvo> (but I'm afraid he has to prepare his thesis presentation)
<desrt> seb128; you guys basically don't vendor patch evince at all (except launchpad stuff), yet i get the bug with the ubuntu package but not evince cvs
<crispin> do the build servers use different compiler flags (and or compiler) from what locally built packages use ?
<mdz> desrt: building cvs on ubuntu?
<desrt> crispin; i just diff'd my build log of metacity against that of the buildserver... nothing except trivial changes
<seb128> desrt: maybe fixed between current and CVS
<desrt> seb128; the only thing that's changed is a darwin compatibility fix
<seb128> weird
<seb128> does it crashes on poppler ?
<tepsipakki> pitti: yeah, now it works.. adding hal to plugdev and fiddling around a bit helped
<desrt> no.  it looks like it has something to do with the egg recent document stuff
<desrt> (it throws some console warnings just before the crash)
<desrt> i'll look again tomorrow.  cheers.
<pitti> sabdfl: your hal still doesn't start properly after system boot? can you please tell me the dbus version you upgraded to?
<sabdfl> pitti: 0.36.2-0ubuntu1
<sivang> infinity: is there a way to verify that that my debmirrored archive is current and consistent? rerun the creatino command?
<pitti> sabdfl: ok, thanks
<sabdfl> pitti: a bug in postgres breezy
<sabdfl> it didnt install plpython, though that was installed on hoary
<sabdfl> also, it seems to have lost tsearch
<daniels> pitti: note that 0.36.2-0ubuntu1 moved the init script back to S12
<pitti> daniels: I know, and that might break something
<pitti> sabdfl: ok, I will add a transition package for it
<fabbione> mdz: ping?
<mdz> yes?
<doko> Mithrandir: could you update OOo1 to 1.1.4 for amd64? currently uninstallable.
<Mithrandir> doko: sure.
<doko> nice
<daniels> pitti: i was pretty careful to remove all the old symlinks
<daniels> pitti: (the transition from dbus-1 -> dbus left around dbus-1 symlinks also)
<mdz> fabbione: yes?
<mae> Is confirming bugs useful or is it better for me to look for new ones, or provide detailed bug reports for other confirmed bugs?
<mae> is gtk 2.8.3 upped yet?
<sivang> Kamion: I saw you added chrp boot option to debian-cd, do we have images ready already for testing?
<infinity> pitti : ping.
<pitti> hi infinity 
<pitti> infinity: any chance to get the powerpc buildds running again?
<seb128> mae: yep, why?
<infinity> They are running.
<mae> seb128, cuz i want to juice :)
<mae> and i don't mean steroids
<zyga> hello
<pitti> infinity: but failing to build a couple of packages (out of memory?)
<Treenaks> mae: eww!
<seb128> infinity: thanks for all the glitz rebuilds ... not really needed because a new GNOME pile is planned before next week, but it's done now which is cool :)
<infinity> seb128 : Well, a mess of stuff other than GNOME was broken too, and it was nice to get it all cleared up.
<seb128> infinity: hum, there was any breakage out of the dep not required?
<fabbione> daniels: xfs #14139 is an upstream bug.. it doesn't define -DFONTCACHE
<fabbione> daniels: i am fixing it locally and let you know
<seb128> just for my information :)
<tepsipakki> pitti: do you know if CF-cards formatted in Canon digicameras should work? I'm not able to mount them, tried on 2.4.31 (sarge) and breezy
<pitti> sabdfl: darn, the dbus version on the current CD is too old, so I upgraded hoary->0.35->0.36.2, which works; can you please send me the output of "ls -lR /etc/init.d /etc/rc2.d"?
<infinity> seb128 : -EPARSE
<seb128> infinity: there was any build breakage or something due to glitz, or that's just to get ride of the unneeded Depends on libgtliz1?
<pitti> tepsipakki: no idea
<pitti> tepsipakki: what does pmount -d device say?
<infinity> seb128 : There were lots of mentions of glitz in .la files, causing other stuff to FTBFS.
<infinity> seb128 : Took some effort to iron that out an all arches (some were worse off than others)
<infinity> seb128 : Makes a good argument for versioned build-deps the next time you do that. :)
<daniels> fabbione: okay, thanks
<seb128> infinity: I've versionned most of main libs when doing it
<seb128> infinity: will try to do better next time :)
<jdub> lamont: ping
<seb128> jdub: wb
<jdub> yo seb128 
<tepsipakki> pitti: hmm, can't test now, but I remember seeing on dmesg that no valid fat/vfat-partition was found
<pitti> tepsipakki: ok, that's a more fundamental problem then
<tepsipakki> pitti: I'll get another card to test later, the owner says that fc2/3/4 mounts it ok
<seb128> jdub: so, what's up with evo?
<seb128> jdub: evo is crap but that's not new ....
<jdub> seb128: 2.3 seems quite a bit worse than 2.2
<seb128> jdub: my bugzilla has no evidence of that
<seb128> jdub: and dunno if you read the changelog for 2.3.8/1.3.8 the list of bugs fixed is impressive
<tepsipakki> garr, when will gnome-screensaver be added to malone...
<seb128> is there any packaging bug on it?
<tepsipakki> I'm not sure
<tepsipakki> it always locks the screen
<Lathiat> i gave up on it, i was sick of it takign 10-30 seconds to show up the unlock dialog
<tepsipakki> If the logout-thing works, it's a saviour
<Lathiat> yeh its called ctrl+alt+backspace :)
<seb128> tepsipakki: upstream bug
<tepsipakki> ok, I'll bug them
<Treenaks> pitti_: would it be possible/hard to make the "This device seems to be encrypted" dialog work the same as the gksudo one?
<Treenaks> pitti_: I sometimes lose it now
<tepsipakki> will there be a mass-migration from bugzilla to malone some time?
<jdub> tepsipakki: yes
<seb128> jdub: ping? :)
<pitti> Treenaks: hm, can you please file a bug? I'm busy right now
<tepsipakki> jdub: great
<tepsipakki> jdub: i mean really ;)
<jdub> seb128: yeah?
<seb128> jdub: some point on this evolution discussion, some issues to point or something?
<jdub> seb128: see gnome bugzilla
<jdub> seb128: i'm not sure too many people file bugs when it seem so unstable
<seb128> jdub: I do browse it quite often ...
<seb128> jdub: it was the same for 2.2
<zyga> pitti: do you have a moment?
<pitti> zyga: well, just ask
<Treenaks> pitti: ok
<zyga> pitti: I'm trying to fix an issue with polish .po files of various packages, they were labeled as latin2 while in reality they were utf8, in effect many messages are corrupted
<zyga> pitti: I can fix them but I wanted to ask you
<seb128> jdub: anyway, reverting is not really an option. That would probably mean downgrading e-d-s too, which would break oo.o2, gnome-panel, etc
<pitti> zyga: we need to fix them right in the source packages
<zyga> pitti: do I have to get the source of every single package or is there any magic way I could get all the pl.po files?
<jdub> seb128: we have to be prepared to do so, however
<jdub> seb128: it may hurt, but we do need to be capable of doing it :)
<zyga> and second issue, will fixing them in the source packages automatically fix them in rosetta?
<pitti> zyga: you can get the pl.po files from language-pack-[gnome-] -pl[-base] 
<seb128> jdub: are you kinding me?
<jdub> .
<jdub> seb128: in general
<jdub> we need to be able to revert if necessary
<seb128> we can't revert a central piece like this one week before the preview
<pitti> zyga: you can change them, but in the end we do need to upload the actual source packages, not the langpacks
<zyga> okay
<seb128> most of the e-d-s libs have changed their API/soname
<jdub> seb128: i'm bringing it up for thought
<pitti> zyga: Rosetta will take the changes automatically, the langpacks will get the changes on next update
<jdub> seb128: if it makes sense, we'd probably have to do it post-preview
<seb128> jdub: yeah, "no way"
<zyga> okay then, could I send you all modified po files?
<seb128> jdub: it doesn't, there is no real issue on it, no reason to do that ...
<pef> hello
<jdub> seb128: we can't just reject these things out of hand
<pitti> zyga: well, you can, but it will take me a while to actually process them
<seb128> jdub: what "things"?
<pitti> zyga: if you have some time, I'd rather take debdiffs of source packages :-)
<jdub> seb128: if there was a choice between a painful reversion and a seriously broken piece of software, we'd have to choose reversion
<seb128> jdub: we want with the new yelp without GNOME for previous one, we can ship the new evo as well for this one
<Treenaks> pitti: (#14400, severity: enhancement)
<pitti> zyga: but mailing me the files is fine
<pitti> Treenaks: thanks
<jdub> seb128: the new yelp wasn't broken
<zyga> pitti: I'll try to my best, I'll check the langpacks now
<jdub> seb128: it had a11y regressions
<seb128> jdub: my point is that my box or bugzilla.ubuntu has no mention of the "seriously broken piece of software"
<jdub> seb128: that's okay, but we need to be open to reversion if necessary
<seb128> jdub: and evo dude have tackle like 100 bugs for 2.11.92
<jdub> i am not suggesting we need to do it, i'm bringing it up for discussion
<jdub> but in general (not about evolution), we do need to be open to reversion
<seb128> yeah, but I don't get why we discuss it rather discussion reverting gnome-applets
<seb128> right
<jdub> because there is a strong feeling at the moment that evolution is not ready to ship
<jdub> that is why i've brought it up
<seb128> hum
<seb128> from who and where?
<seb128> I just would like to get a pointer to some discussion about that
<jdub> bugsquad, luis, quite a lot of non-specific complaints
<seb128> bah
<jdub> luis is going to bring it up with r-t or d-d-l
<seb128> that was the same for 2.2
<jdub> not really
<seb128> 2.2 was broken over what 2.3 is now
<jdub> there was no strong suggestion that we not ship 2.2 last release
<seb128> every single 2.1 tarball had RC issues 
<jdub> ok
<seb128> no; but there could have been
<jdub> dude
<jdub> i'm preparing you for what's coming
<jdub> evo 2.4 may not ship with gnome 2.12
<seb128> k, let's wait for this
<jdub> we need to decide what we're going to do
<seb128> you should rather prepare mdz
<seb128> and I'm not taking the responsability to break the whole desktop like this
<jdub> seb, i'm not saying we have to
<jdub> i'm bringing it up for discussion
<seb128> k
<seb128> I'm strongly against it
<seb128> let's discuss with luis when he's around
<seb128> to know why he wants to bring that up
<seb128> maybe with a list of show stoppers I'll be convinced :)
* jdub tends to think a large amount of non-showstopper bugs is reason enough to slip too
* seb128 too
<seb128> but I'm pretty convinced that 2.2 has the same amonth of issues
<jdub> seb128: also, watch out, you are being hunted after being away on vacation
<Keybuk> mmm, "seb128 season"
<Keybuk> be dewy quiet, I'm hunting gtk bugz
<seb128> jdub: I was away 4 days and ready mails on days 3 and 4 ... that's quite ok :)
<jdub> there's sebs in them thar hills!
<sivang> Keybuk: lol
<seb128> jdub: anyway thanks for pointing the discussion, I'll ping luis when he's around
<jdub> ok
<seb128> jdub: I'm just a bit surprised because the evo guys tracked down a whole pile of bugs for some weeks, cleaned some hundred bugs to bugzilla and fixed like one hundred for 2.11.92
<seb128> jdub: anyway we have time to figure
<pitti> brb
* seb128 is away for ~1h, bbl
<mjg59> pitti: Hello
<pitti> Hi mjg59 
<fab_live> seb128: i am on livecd now.. the one from this morning.
<pitti> mjg59: on hoary->breezy upgrade (probably also at clean install) I get a debconf note for toshset; known bug?
<fab_live> i got "Hal cannot initialize" message at the loging
<fab_live> login even
<pitti> fab_live: sudo /etc/init.d/dbus cures it?
<mjg59> pitti: Fixed
<pitti> fab_live: if so, then I saw this somewhere
<pitti> mjg59: ok, thansk
<fab_live> pitti: dunno.. let me check..
<pitti> fab_live: I'll try the current live - i386?
<pitti> fab_live: check with "lshal" that it worked
<Keybuk> jbailey: ping (when you're up)
<fab_live> lshal prints tons of stuf--let me try logout/login again
<tepsipakki> lathiat: I think your gnome-screensaver-dialog vomits a lot of pango-warnings (invalid utf-8 string passed to pango_layout_set_text)?
<fabbione> pitti: yes.. restarting dbus helps
<pitti> fabbione: ok, so hal wasn't running before
<pitti> fabbione: i386?
<fabbione> pitti: yes. i386
<pitti> fabbione: anyway, I try today's live; I already tried a hoary->breezy upgrade to reproduce it, but failed (i. e. it worked)
<fabbione> i didn't check hoary -> breezy.. only the live
<fabbione>  682028 -rw-r--r--   1 root root  699566080 Aug 31 09:16 breezy-live-i386.iso
<pitti> mjg59: btw, the point where I dropped out of usplash is "Calculating module dependencies" - it takes > 10 seconds
<pitti> mjg59: so this is not an usplash bug, rather we should check what takes so long about module dep calc...
<fabbione> 87a432ad8aefb4657cac27f58261ff1d  breezy-live-i386.iso
<mjg59> pitti: Well, arguably it's a bootsplash bug
<mjg59> Uh, usplash
<pitti> mjg59: I think falling back to text mode by the watchdog is not entirely wrong
<pitti> mjg59: maybe the timeout should just be increased then
<mjg59> pitti: When we're expecting it to happen, it's reasonable
<pitti> mjg59: but in any case speeding up (or maybe  caching) module dependency calculation would boost boot speed nicely
<mjg59> Yes, but that's not necessarily brezyable
<pitti> right
<mvo> ping doko 
<doko> mvo: pong
<mvo> doko: I think I fixed the apt-listchanges problem, but I would like to know if the fix works for you as well
<infinity> mvo : Am I the only person who thinks it's competely broken that update-manager can't handle dist-upgrade cases (specifically, addition of packages, not necessarily removal, since a kernel security update that bumps ABI will leave a majority of confused users vulnerable)
<pitti> mvo: btw, removal would be nice as well - otherwise a hoary->breezy upgrade will still have xpdf & co
<mvo> infinity: no, there is a bug open about it. we have a much improved u-m in cvs, but it didn't made it for breezy in time. 
<mvo> pitti: u-m does not currently support dist-upgrades. but infinity is right, a normal upgrade is not sufficient for the kernel
<infinity> mvo : Shame.  I don't suppose anyone could get a hack in just for the "add new packages" case, since for kernels this could be Really Bad?
<zyga> mvo: hi
<pitti> infinity: well, it is not that bad since most users will have the meta packages
<mvo> infinity: I think someone should do that, yes (/me looks at it now)
<infinity> pitti : Removal shouldn't be as big a deal, since I would hope people won't attempt hoary->breezy upgrades via update-manager.
<infinity> pitti : The metapackage won't upgrade, that's the problem.
<pitti> infinity: why not?
<infinity> pitti : Requires new packages installed, update-manager tells you to "do something really complex" (run synaptic or apt-get)
<mvo> infinity: could you test http://people.ubuntu.com/~mvo/apt-listchanges_2.59-0.2ubuntu4_all.deb please? and see it it fails for you?
<Mirv> was there some specific contact for large scale Ubuntu CD shipments? I was contacted by one person who is interested in spreading Ubuntu to some Finnish schools (with additional guides etc.), and asked if there's some contact for this kind of CD shipments...
<zyga> pitti: help the clueless, I built fixed packages with dpkg-buildpackage, now I should rename them (like --fixed suffix) apt-get source them again, dpkg-buildpackage them again AND finally run debdiff?
<pitti> zyga: I /msg you
<fabbione> hi Saba_Z 
<Saba_Z> Hi
<fabbione> Saba_Z: did you get my mail at the end?
<fabbione> with the deb package?
<Saba_Z> yes
<fabbione> super
<Saba_Z> with seb?
<Saba_Z> when did you send it?
<fabbione> eh i meant the sources for the deb
<fabbione> yesterday ...
<Saba_Z> Yes, I have recieved
<fabbione> perfect...
<infinity> mvo : Still segfaults for me, but that was expected, since my segv seems to be deep in python-gtk, not anything apt-listchanges is doing wrong.
<fabbione> was it difficult to understand?
<Saba_Z> that was ok, I had changed the package and send it
<fabbione> Saba_Z: i just got the mail right now..
<Saba_Z> just 5 minutes ago!
<fabbione> give me 2 minutes to look at it
<Saba_Z> ok
<mvo> infinity: I was able to reproduce a segfault on my i386 here and the package fixed that one for me
<infinity> mvo : Hrm.  Still breaks for me. :/
<pitti> sabdfl: uh, the postgresql plpython transition is pretty tricky - hoary didn't have a separate package for the varios PG/PL{perl,python,tcl} languages; so I either force the installation of all extra packages during the transition, or leave it like it is now
<infinity> mvo : So, we must have had two different segvs.
<mvo> infinity: oh well :/
<fabbione>                 grep -v "/etc/sbs/named.conf.sbs" "$BINDCONF" > "$tempfile"  || true
<fabbione> Saba_Z: this is very dangerous to do
<fabbione> specially followed by cp "$tempfile" "$BINDCONF"
<infinity> mvo : I'm hoping it magically clears up as we get new GTK and new bindings uploaded, but if it's still happening after preview, I'll have to find someone with a giant brain to help me hunt it down beyond "oh look, the stack is smashed, yay"
<fabbione> if the previous operation fails, you will get to copy an empty file over a valid config
<mjr> 37
<infinity> mvo : On the other hand, my problem would sort of go away if calling apt-listchanges from a console with frontend=pager didn't import gtk in the first place.
<Saba_Z> =-O oh, yes. there was a problem on the last grep
<rob^> is anyone else having problems with usplash not appearing on startup?
<Saba_Z> I will correct it, and send you 
<fabbione> Saba_Z: otherwise it looks fine.. i suggest you to grab another package that is under the GPL licence and see how the copyrigth file is structured
<fabbione> because there is a shorter way than adding the overall GPL boilerplate ;)
<fabbione> and you need to add your name there too
<mvo> infinity: it has to do with the structure of apt-listchanges, I'm not sure it can be changed easily
<fabbione> copyright != licence, but for our target, they stay in the same file
<infinity> mvo : Ahh, suck.  Then I guess I need to work on finding the real bug. :)
<rob^> guess not
<Saba_Z> ok
<Saba_Z> I will send it within 10 minutes :)
<tseng> infinity: that gtk-sharp segv on the x86 buildd just fixed itself
<fabbione> Saba_Z: oh hmm
<fabbione> one second..
<tseng> infinity: so, cheers.
<Saba_Z> ok
<kent> Are bugreports on breezy going to bugzilla.ubuntu.com, or is there some other prefered place? (Rhythmbox segfaults for me, and it seems to not be one of the reported bugs.. but Im unsure)
<rob^> kent, it is reported
<fabbione> if [ -n "$BINDCONF" ] ; then
<fabbione>         if ! grep --quiet "/etc/sbs/named.conf.sbs" $BINDCONF; then
<fabbione> this is correct...
<mvo> infinity: I look at it again when I'm finished with update-manager
<fabbione> you forgot to do the same for the last config file
<fabbione> and there is another case we need to take into account...
<fabbione> Saba_Z: let's imagine the user isntall sbs..
<fabbione> but after he removes the sbs portion of config files from (for example) binds
<fabbione> bind9
<fabbione> at the first sbs upgrade, he will get them back
<fabbione> so you need to ensure to add your sections only at install
<fabbione> but not on upgrades.
<Saba_Z> :-?
<fabbione> ehhe ok.. example
<Saba_Z> one second ...
<fabbione> i install sbs
<fabbione> sure..
<kent> rob^, Thanks. I saw it now on bugzilla.  :)
<rob^> np
<Saba_Z> Can you please say the example :D 
<Saba_Z> fabbione: Can you please say the example :D
<fabbione> Saba_Z: yes.. you asked for a sec and i was waiting for you :)
<fabbione> let's say:
<fabbione> i install sbs
<fabbione> the packages add its stuff to the different bind.conf.local or whatever...
<fabbione> I, completely bastard admin, decide to remove the sbs entry from the bind config file because i want to manage it myself
<fabbione> sometimes in the future you upload a new version of sbs
<fabbione> and I decide to upgrade
<fabbione> your postinst script will readd the sbs entry in bind.conf.local
<fabbione> overriding my decision
<fabbione> this is bad
<fabbione> it shouldn't happen
<fabbione> so we need to do in such a way that the bind.conf.local will be preserved properly across upgrades
<Saba_Z> :-? so, is there any argument passed when upgrading ?
<fabbione> (bind.conf.local like all the other config files)
<fabbione> Saba_Z: yeps... 
<fabbione> Saba_Z: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
<Saba_Z> there is another problem, specially for webmin.catnames
<Saba_Z> the file "webmin.catnames" can be empty
<fabbione> what problem does that introduce?
<Saba_Z> so on postrm, grep -v "wizard" /etc/webmin/webmin.catnames  returns false
<fabbione> Saba_Z: check if the file is empty...
<fabbione>        -s file
<fabbione>               True if file exists and has a size greater than zero.
<fabbione> you can use that instead of -e
<Saba_Z> ok
<fabbione> so if the file is empty you don't care to grep in it
<Saba_Z> the file /etc/webmin/webmin.catnames is not empty, It has the line "wizards=Wizards" before removing the webmin-sb
<Saba_Z> s/webmin-sb/webmin-sbs/;
<fabbione> given that the user didn't change it manually...
<fabbione> since it's conf file you cannot assume it has something in it
<Saba_Z> If there was just the "wizards=Wizards" line, I should make it empty.
<fabbione> Saba_Z: there is no need to special case it. if there is only that line, the grep will do
<Saba_Z> the grep then returns false! that was the reason of adding || true to the lines
<fabbione> it returns false on a match?
<Keybuk> mvo, seb128: I've seen a bug about the non-shape-ness of the update-notifier notify bubble haven't I?
<Saba_Z> yes :D and with synaptic, it fails on completely removing
<daniels> /part/
<daniels> hm
<fabbione> Saba_Z: hmmmm weird.. 
<fabbione> i would probably just throw away the return code...
<mvo> Keybuk: do you run the latest notification-damoen (ubuntu9)? that should have fixed it
<mvo> Saba_Z: what fails to complettly removal?
<fabbione> mvo: no panic :)
<fabbione> it's a postinst returning something wrong
* mvo panics
<mvo> fabbione: ah, thanks
<fabbione> Saba_Z: well i think i know the problem.. 
<Keybuk> mvo: yeah, is ubuntu9
<fabbione> try adding exit 0 at the end of postinst and postrm
<Keybuk> though I may not have seen one with that
<fabbione> Saba_Z: i think i overlooked at them :)
<mvo> Keybuk: and it the notification-daemon was restarted since the upgrade to ubuntu9?
<Keybuk> maybe not
<Saba_Z> ok :)
<Keybuk> am doing an upgrade/reboot in a moment anyway, so will look then
<mvo> Keybuk: ok, thanks
<fabbione> Saba_Z: if there is nothing else urgent i would love to go and eat something..
<fabbione> Saba_Z: and i will be back in 30/40 minutes
<Diziet> Oh, hello Keybuk.  Did you get a chance to look at that email of mine about conffiles ?
<Keybuk> Diziet: not yet :-/  they were quite detailed <g>
<Saba_Z> ok, I will send the new package ;)
<fabbione> Saba_Z: perfect!
<Diziet> Do you mind if I just go ahead and do it ?
<Keybuk> not at all, was kinda hoping you would :)
<Diziet> Right, OK then :-).
<Keybuk> you're already up to speed on the diagnostics
<Kamion> sivang: as I said yesterday, this morning's CD builds should have the CHRP stuff I added; they seem to have completed successfully at around 09:23 London time
<jdthood> mdz: In lsb-base, "Use type instead of which".  I am curious about why that change was necessary.
<Keybuk> jdthood: which isn't a builtin
<Kamion> people were having problems with separate /usr
<Keybuk> and wasn't in $PATH at the time
<Kamion> (IIRC)
<jdthood> which is now in /bin/
<jdthood> ... in Debian
<pitti> Hi jdthood 
<Keybuk> something like that, I read that bug almost two cups of coffee ago
<jdthood> Anyway you have answered my question; thanks.
* pitti tests live cd
<jdthood> $ dpkg -L debianutils|grep which
<jdthood> /bin/which
<jdthood> /usr/share/man/man1/which.1.gz
<jdthood> /usr/share/man/fr/man1/which.1.gz
<jdthood> /usr/bin/which
<jdthood> The which program is in /bin/ in Ubuntu too.
<jdthood> There was a discussion about type and which in debian-policy.  It was argued that which is better than type because the latter is implemented differently in different shells.
<jdthood> What is "usplash_write"?
<opi> Hi
<jdthood> /lib/lsb/init-functions is testing for the availability of a "usplash_write" command.
<sladen> jdthood: it's a safe pipe writer that doesn't complain if the pipe doesn't exist
<jdthood> sladen: I presume it's an executable file, not a shell function?
<pitti_live> fabbione: yep, I can reproduce the hal bug
<jdthood> The potential advantage "type" has over "which" is that it finds shell functions.
<jdthood> The disadvantage is the non POSIXness of "type" and its varying implementation.  Worrisome that it's used in a shell function library such as /lib/lsb/init-functions.
<Mithrandir> is there any reason not to grab my "findcommand"?  It cuts the mustard for me.
<Mithrandir> (http://err.no/dotfiles/environment has the definition)
<jdthood> Mithrandir: Just that it's nice not to have to define a function before doing the equivalent of "which".
<jdthood> Mithrandir: IIRC, findcommand does what "which" does, right?
<Mithrandir> : tfheen@thosu ~ > findcommand emacs
<Mithrandir> /usr/bin/emacs
<pitti_live> fabbione: hmm, it could help if dbus would actually be started at boot :-) it just doesn't install an rc2.d symlink...
<Mithrandir> : tfheen@thosu ~ > findcommand gobblygook
<Mithrandir> : tfheen@thosu ~ > echo $?
<Mithrandir> 1
<Mithrandir> it can also do stuff like:
<Mithrandir> : tfheen@thosu ~ > findcommand gobblygook1 gobblygook2 ls
<Mithrandir> /bin/ls
<ajmitch> elmo: sync f-spot from sid, please :)
<jdthood> Mithrandir: Well, "which" does that too.  Except for the last one.  Nice feature.
<Mithrandir> jdthood: I use it for stuff like "set XTERM to the first one of those terminal emulators"
* jdthood nods
<fabbione> pitti_live: ehehehe
* fabbione -> food
<pitti_live> fabbione: good for daniels that he isn't online ATM :-)
<fabbione> :)
<jdthood> I am just raising the question here of why lsb-base has migrated from "which" to "type" even though the latter is less portable.
<jdthood> But it's a minor issue, especially in Ubuntu context.
<Kamion> I thought type was POSIX, but on inspection I see I was wrong
<Kamion> perhaps init-functions should do as Mithrandir suggests; that's what I've done in similar contexts
<Kamion> "which" broke for people. We got actual failure reports.
<Kamion> I don't know the exact reasons because I didn't investigate in detail
<jdthood> Kamion: Probably which was in /usr/bin/ in Hoary
<Kamion> but it seems entirely reasonable to want to use builtins where possible
<Kamion> jdthood: I don't think anyone involved was testing on hoary
<Kamion> it seems highly unlikely, considering the context was usplash
<infinity> Partial upgrades, if nothing has versioned deps on debianutils.
<Kamion> but, could be I suppose
<infinity> debianutils definitely installed which in /usr/bin only on hoary.
<thesaltydog> jdthood, which is in /usr/bin in hoary..
<infinity> So that's the most likely explanation.
<jdthood> In Debian, the "which" program moved from /usr/bin/ to /bin/ just a bit too late for sarge.
<Kamion> fair enough ...
<infinity> Anyhow, with everyone and their dog always complaining that booting takes too long, I'm all for switching to shell builtins where we can.
<Kamion> I'd definitely import the guts of which as a function, one way or another
<Kamion> after all the current /usr/bin/which started out as exactly that
<jdthood> Tes
<jdthood> s/T/Y/
<jdthood> Hmm...
<jdthood> Unpacking replacement linux-image-686 ...
<jdthood> Setting up linux-image-2.6.12-8-686 (2.6.12-8.12) ...
<jdthood> cpio: ./etc/udev/rules.d/001.rules: No such file or directory
<jdthood> Eww.
<infinity> Blame jbailey.
<jdthood> Is this something I want to investigate just before lunch?
<jdthood> ~$ ls -l /etc/udev/rules.d/001.rules
<jdthood> lrwxrwxrwx  1 root root 18 2005-07-07 13:03 /etc/udev/rules.d/001.rules -> ../alsa-base.rules
<jdthood> WTF?
<Kamion> I hate Ctrl-\
<Keybuk> *sulk* depmod took too long
<Diziet> k: You hate C-\ ?  I like it.
<Kamion> I hit it by accident a lot when aiming for C-z
<Diziet> stty it somewhere else ?
<Diziet> Oh, I know what your problem is.  You have ctrl in the wrong placew.
<Keybuk> what's C-\ ?
<Keybuk> other than the key to make dselect core dump? :p
<Kamion> Diziet: position of Ctrl isn't relevant, it's that \ and z are adjacent
<koke> well, on spanish keyboards is worse, it's Ctrl+AltGr+
<Kamion> but yeah, I keep meaning to stty it, I'd just have to do it everywhere or I'd get even more confused
<koke> you need two hands for it
<infinity> Then get a better keyboard, where \ is over [enter] , where it belongs.
* tseng remapped his new uk laptop to US layout
<Diziet> Aaargh, I HATE bugzilla !
<tseng> its nice to know where my " and # 's are
<Nafallo> Diziet: word
<Keybuk> tseng: " should be above 2 ... see ascii(7) if you don't believe me <g>
<tseng> Keybuk: not on any keyboard ive ever owned :)
<tseng> until this one
<infinity> mvo : Hrm, I think the last GTK upload made my python-gtk segv go away.
<jdub> mjg59: "New IrDA Spec Shoots for 100Mbit/s Data Rate"
<jdub> mjg59: "Of note, existing IrDA-enabled devices can be upgraded to the new protocol, thus offering the opportunity to accelerate the IrDA data transfer rates of devices in the field via a software update."
<jdub> :-)
<Nafallo> wow
<jdub> let's be getting some of THAT!
<Nafallo> 100Mbit to my cellphone would be... necessary ;-)
<Kamion> Keybuk: unfortunately ascii(7) also argues for # above 3
<jdub> might make irda useful
<Keybuk> Kamion: sssh
<Keybuk> Kamion: that's an entirely _separate_ issue <g>
* Kamion looks at Debian #322081 and wonders if libxaw8 is coming back in Ubuntu
<Lathiat> hrm ive got firefox installed on a machien without ubuntu-desktop and it has no fonts
<Lathiat> missing font deps or something?
<Lathiat> no text anywhere at all
<pitti> Lathiat: do you have firefox or mozilla-firefox?
<zyga> pitti: would you mind if I were to convert all latin2 .po's to utf-8?
<Lathiat> pitti: firefox im fairly sure but elt me look
<Lathiat> ah i see
<Lathiat> i have mozilla-firefox
<Lathiat> it was a hoary upgrade
<pitti> zyga: well, not just for the sake of it, that creates unnecessary work
<Lathiat> on a box with xfce
<Lathiat> that should be fixed...
<Lathiat> in cases where ubuntu-desktop isnt installed
<zyga> pitti: okay - ignore it then
<pitti> Lathiat: hm, then you didn't have the metapackage installed?
<Lathiat> pitti: no
<pitti> Lathiat: ubuntu-desktop, that it
<pitti> is
<Lathiat> pitti: i dont have room on this machien to do that...
<pitti> Lathiat: ok; I asked for the removal of mozilla-firefox several times, I will poke elmo again
<Lathiat> pitti: if its removed will firefox be installed?
<pitti> Lathiat: it creates nothing but confusion, and m-f is an old and insecure version
<Lathiat> pitti: (thsi was an upgrade from hoary, so taht woudl explain why i have mozilla-firefox)
<pitti> Lathiat: not automatically; maybe instead of dropping it, we should upload an empty transition package that depends on firefox
<Lathiat> ok so firefox works fine
<Lathiat> pitti: thats what im thinking...
<pitti> sabdfl, elmo, fabbione: new dbus uploaded, that should fix the hal failure you saw
<infinity> pitti : Note that an empty metapackage is no different from just having the package named "mozilla-firefox" in the first place, which egs the question "why did we rename it?"
<pitti> infinity: right, I thought of dropping the current m-f source package and have firefox spit out an empty m-f package
<infinity> pitti : (I've heard arguments in the past that packages names can be considered interfaces, and are hence both uncopyrightable and untrademarkable, but this is the wrong place to discuss that)
<pitti> infinity: IIRC it was renamed due to trade mark issues
<infinity> pitti : Right, but the empty package would still be mozilla-firefox, you see what I'm driving at?
<pitti> infinity: right, but at least new installs won't see it
<Mithrandir> infinity: I think mofo is ok with it, as long as we're doing it as part of a transition.
<Mithrandir> infinity: at least that's the impression I've gotten from them.
<pitti> infinity: and it would be in universe anyway
<infinity> If I had to guess, I'd bet they would have been fine with the package name not changing at all, so long as the application branding didn't use the mozilla name, but who knows.
<pitti> infinity: no idea about that, really
<infinity> pitti : Having it in universe is little or no help, since you want it there to upgrade people who had a package installed from main in hoary.
<pitti> infinity: hm, right
* infinity notes that we still haven't renamed thunderbird, which should suffer the same issues.
<pitti> infinity: so without the ubuntu-desktop metapackage, current upgrades are hosed completely...
<infinity> pitti : Pretty much, yes.  Without a transitional package, things will be very broken.
<pitti> elmo: please sync postgresql and postgresql-common from Debian incoming
<pitti> infinity: what would you prefer, one additonal deb from firefox, or an empty m-f source package?
<infinity> pitti : I don't suppose it's a question of what I prefer.
<pitti> no, just collecting opinions
<infinity> pitti : Generating it from the firefox source is the path of least resistance.
<pitti> I'd rather drop m-f source completely
<pitti> ack
<infinity> OTOH< generating it from an empty m-f source is a nice way to make sure m-f doesn't accidentally get unblacklisted and synced. :)
<pitti> infinity: won't the generated debs collide anyway then?
<pitti> it also has the advantage that I don't need to bother anybody to remove the m-f source package
<Kamion> elmo: please sync binfmt-support 1.2.5
<seb128> pitti: shouldn't the translations be fixed from rosetta now instead of patching the packages?
<Kamion> elmo: man-db 2.4.3-2 as well, please; the col fix is good for many languages
<pitti> seb128: well, yes, but (1) rosetta will import them and (2) I still don't get rosetta exports
<seb128> pitti: are you sure for (1)? I thought that rosetta changes have priority over the .po 
<seb128> ie: if you have different rosetta and po strings it uses the rosetta one
<infinity> ... Assuming they're not fuzzy?
<pitti> seb128: hm, that shouldn't be the case; I'll ask carlos
<pitti> I didn't change the actual strings, but the header
<seb128> pitti: that's what carlos said to me
<seb128> k
<pitti> the strings were unicode, the header stated latin2
<pitti> seb128: ok, I will poke him to change that :-)
<seb128> pitti: he he
<Saba_Z> fabbione: what should be the content of license.txt? :)
<frans-th> hi all
<Lathiat> pitti: question
<Lathiat> pitti: why do we have mozilla-thunderbrid
<Lathiat> pitti: instead of 'thunderbird' ?
<Mithrandir> Lathiat: because it hasn't been renamed yet.
<Lathiat> right
<pitti> Kamion: is it possible that the current install CDs don't install language-support-en accidentially?
<pitti> Lathiat: I really don't know, I didn't rename firefox in the first place
<Mithrandir> pitti: they do install them; I just did an install now.
<pitti> Mithrandir: ok, checking #14392
<Mithrandir> pitti: but it seems like apt-cdrom isn't able to pass the question to the frontend properly, so you need to pop the media into the drive after booting to make it work correctly.
<sivang> Mithrandir: where are you with Xen suport goal? I saw it was deferred, will it be open again for specing and work sometime soon?
<Mithrandir> pitti: I can do a test install without a network connection, if you'd like?
<Kamion> pitti: I think the root problem is that archive-copier doesn't follow dependencies when deciding what packages to copy where
<Mithrandir> sivang: yes, I'm hoping we'll have something for breezy+1
<Kamion> so it copies language-support-en.deb but not its dependencies, so apt prompts
<pitti> Mithrandir: well, it's not that urgent, let's just check at the next regular test install (I will do it, too)
<Mithrandir> Kamion: hmm, would it be possible to get archive-copier to rather do an apt-get --download-only run instead of copying by itself?
<Kamion> Mithrandir: that runs the risk of running into an apt CD prompt at an even more inconvenient point, doesn't it?
<Mithrandir> Kamion: not if you make sure to mount the cd already.
<Kamion> yeah, I guess
<Mithrandir> Kamion: archive-copier can mount the cdrom at /target/cdrom, chroot into /target and do apt-get --download-only (or aptitude, probably)
<Kamion> the alternative (and probably less intrusive at this point) would be to add Task: headers on the CD for stuff that's a dependency of language-support-*
<Kamion> we could have germinate work that out
<fabbione> Saba_Z: apt-get source redhat-cluster-suite and look to debian/copyright
<fabbione> Saba_Z: do something along those lines and it would be perfect
<Mithrandir> Kamion: mhm, with preview close and all that.
<Kamion> yeah ...
<Kamion> although it will involve some very hairy germinate use
<doko> mvo: do you ping me all the time, or is this some kind of irc spammer?
<mvo> doko: it was me, I wanted you to test the apt-listchnages package and see it curses the segfault
<doko> mvo: I did reply, didn't you get the answer?
<mvo> doko: no, I didn't get the answer
<doko> mvo: now?
<mvo> doko: no
<mvo> doko: do you not have a registered nick? maybe freenode is blocking you?
<doko> mvo: no, should I?
<seb128> doko: yeah, as mvo said, freenode blocks query from not registred users now
<seb128> doko: look on your server tab, you should have some msg about that
<seb128> you got one every time you try to speak to somebody by query
<jbailey> Keybuk: pong
<Keybuk> jbailey: gah, get me as I'm going to lunch, why don't you? :p
<Keybuk> around in an hour?
<jbailey> Keybuk: Yup. =)
<mvo> doko: does the package work for you?
<doko> mvo: yes
<Keybuk> (context: looks like there's still a udev+initramfs bug out there)
<mvo> doko: thanks
<doko_>  /msg nickserv link doko dedacon
<pef> does linux-kernel 2.6.13 will be include into breezy before release ?
<ivoks> i don't think so
<pitti> definitively not
<zul> no it wont
<ivoks> elmo: openvpn needs sync from debian due security problems
<pef> is it possible to use loop in a Makefile ? (debian/rules) like for dir in foo foo2 do cp $foo bin/$foo done ? I have a problem with the $dir var, don't know how to use it,$dir and $$dir won't work
<Mithrandir> for dir in foo foo2; do cp $$foo bin/$$foo ; done should work fine
<Kamion> $$foo -> $$dir there
<Mithrandir> yeah, true
* Mithrandir kicks xine
<pef> works fine, thank you !
<sivang> Mithrandir: is the spec going to be rediscussed at UBZ? (re: Xen)
<Mithrandir> sivang: I don't know.
* Mithrandir weeps at xine-ui's Makefile.am: AUTOMAKE_OPTIONS = 1.3
<Mithrandir> that's like, 1990
<Treenaks> Mithrandir: no, it'r "retro"
<sivang> Treenaks: lol
<bddebian> Morning
<pef> bddebian: morning (what time have you got ?)
<bddebian> 9:20am EDT
<Diziet> keybuk: dpkg 1.13.11's configure.c has been put through some kind of mutant tab transformation.  What should I do about it ?
<pef> 3:18 pm here :) big difference
<Diziet> Setting my Emacs's tab-width to 2 for that file makes it looks sensible, but my diff is likely to be annoying somehow.
<Keybuk> heh, wonder who did that
<Keybuk> somewhen while it was in CVS
<Keybuk> the source is such a mess coding-style-wise I wouldn't worry too much
<Keybuk> nearly all the bits of code have a different style
<Diziet> If you want to put it back, in this case sending it through expand -t2 will probably DTRT.
<pitti> re
<pitti> ogra: ping
<ogra> pitti, pong
<pitti>    * Added postgresql to server-i386, server-amd64, server-powerpc,
<pitti>      server-ia64
<pitti> ogra: you don't want that
<ogra> wrong ? 
<pitti> ogra: you want postgresql-8.0
<ogra> ok, what do i want ? 
<ogra> oki
<pitti> ogra: postgresql is the transition package for hoary->breezy upgrades
<pitti> and will pull in 7.4
<ogra> pitti, is it safe to assume that moodle will work with 8.0 ?
<pitti> ogra: yes
<pitti> ogra: it is a client-side application, and the lipq API is the same for 7.4, 8.0, 8.1
<ogra> pitti, i know, i was just carefully and thought postgresql will deal with it in the future too :)
<ogra> i'll change it right away
<pitti> ogra: no, postgresql will disappear after the breezy and etch release
<pitti> (at least if we don't want to support upgrades with skipping releases)
<tepsipakki> seb128: the gnome-screensaver locking is fixed in CVS, hopefully a new version is coming
<Mithrandir> pitti: hmm?  I thought upgrades from any supported version to any supported version was supported?
<pitti> Mithrandir: not sure, not in Debian at least; is that guaranteed somewhere?
<pitti> Mithrandir: we can't support upgrades from warty forever...
<Mithrandir> pitti: not in Debian, I was talking about Ubuntu.
<pitti> right
<Mithrandir> pitti: warty won't be supported forever. :-)
<Kamion> pitti,Mithrandir: ok, I'm making good progress with the germinate/cdimage/archive-copier hacking to fix language-support copying
<pitti> Mithrandir: ah, so warty->breezy+1 is the maximum
<pitti> Kamion: you rock :-)
<Mithrandir> pitti: breezy+1 will be more painful, with a five year release cycle, but ISTR not the same guarantee being given there.
<seb128> tepsipakki: cool
<tepsipakki> unfortunately the fix for gnome-session-save did not make it in 2.12, so the logout-button doesn't really work
<tepsipakki> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=149447 that's the fix for gnome-session-save.. too much for breezy?
<seb128> tepsipakki: it's useful to do what?
<tepsipakki> for classrooms.. to log out people
<tepsipakki> who left the session locked
<tepsipakki> xlock has had that feature, xscreensaver no
<tepsipakki> that's why I'm particularly interested in g-s ;)
<tepsipakki> seb128: I might test that first..
<seb128> tepsipakki: yep, would be nice to try it first
<Lathiat_> gnomescreensaver is slow and keeps not bringing the unlock dialgo up :\
<ogra> Lathiat_, it will be better if we ship it in breezy+1 ;)
<tepsipakki> lathiat: maybe you missed my message, but the reason is in pango
<Lathiat_> tepsipakki: oh?
<seb128> pango what?
<tepsipakki> try running it from a console and you'll see
<tepsipakki> it makes _a_lot_ of warnings
<Lathiat_> warnings dont mean its broken? ;p
<tepsipakki> invalid utf-8 string passed to pango_layout_set_text
<infinity> mvo : You are THE Man.
<tepsipakki> that's what it complains
<tepsipakki> lathiat: it doesn't do that on my laptop ;)
<Keybuk> seb128: every time metacity crashes, I'm putting aside a beating for you
<tepsipakki> but on a desktop comp yes
<Keybuk> ;)
<Lathiat_> Keybuk: haha
<seb128> Keybuk: nobody is able to get a correct backtrace, so stop complaining and get one :p
<mvo> infinity: it's a bit half-assed, but should work in the common cases (libapt is a pain sometimes)
<seb128> Keybuk: s/correct/debug/
<Keybuk> seb128: tell me how
<Keybuk> would starting it in gdb be sufficient
<seb128> rebuild the package with DEB_BUILD_OPTIONS="noopt nostrip"
<seb128> install it
<seb128> switch to an another X or VT
<seb128> attach gdb on it
<Keybuk> can't I just start it to replace the running one?
<Keybuk> inside gdb
<seb128> switch back
<infinity> mvo : Half-assed is fine, I figure just adding (but never allowing removing) packages shouldn't be TOO much hassle.
<seb128> if you do that you are screwed when it crashes
<seb128> because your window manager hangs due to gdb
<Keybuk> that's ok
<seb128> so you can't type "bt" of do anything
<infinity> mvo : (I would have just piped the output of apt-get -s dist-upgrade and parsed it, so y'know, good thing you did something more reasonable) :)
<Keybuk> I was thinking of running it on vt1
<seb128> Keybuk: anyway, just do a debug build and attach it with gdb as you want ... nobody has got a crash with a home built version
<seb128> Keybuk: I'm running it with gdb since this morning by example
<mvo> infinity: heh :) [well, only adding, no removing is unfortunately not as trivial as I had hoped but it may be just me overlooking something in libapt] 
<Keybuk> interesting
<Keybuk> have you pushed a rebuild through ?
<seb128> yeah
<infinity> mvo : Overlooking what?... That libapt is fairly useless?
<Keybuk> uh, gnome-pkg-tools wants me to install exim !?"!?$!$
<seb128> Keybuk: it has been rebuilt to get ride of glitz Depends a few days ago
<mvo> infinity: yeah, something along that lines. That it likes playing "cripple mr. onion" with me maybe
<infinity> Cripple... Mr.. Onion?
<mvo> infinity: you don't read discworld novels, do you? nevermind then :)
<infinity> That's got to be some crazy German pop culture reference.
<infinity> Oh.  Or Discworld.  Also something I'm not into. :)
<tepsipakki> seb128: the patched gnome-session-save worked fine ;)
<seb128> cool
<infinity> Keybuk : Deep enough down in it's dependencies, I find an m-t-a dep, but not exim..
<Keybuk> exim provides m-t-a
<infinity> Keybuk : Well, yes, ut that hardly constitutes a dependency on "exim".
<Keybuk> syndicate ubuntu% file =metacity
<Keybuk> /usr/bin/metacity: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped
<Keybuk> ok
<Keybuk> infinity: I don't want an m-t-a on this box <g>
<Keybuk> at least, I'm trying to hold out as long as I can without one
<infinity> Keybuk : nullmailer or ssmtp
<infinity> (depending on whether you want something that functions or not)
<Treenaks> mtacity?
<infinity> Oh, apparently they both work.  For some reason, I always assumed nullmailer mailed ot /dev/null... Never read the description until today.,  Go me.
<mvo> Kamion: I'm looking into the "media-change" message for the status-fd now. will you be able to send a "\n" to aptitudes stdin? 
<Keybuk> yeah, I'm away
<Keybuk> uh
<Keybuk> aware that they exist
<Keybuk> never looked to see which supports smtp-auth
<Treenaks> Keybuk: postfix does :)
<Kamion> mvo: I might have to create a named pipe to do it, but I think it should be possible
<Keybuk> Treenaks: I asked the maintainer how to configure it, and he said "uhhhhh"
<Keybuk> that filled me with confidence
<Keybuk> and exim excites me with its 4,000 config files
<Treenaks> Keybuk: It's 4 lines of postconf, 1 line of echo and 1 line of postmap
<Treenaks> Keybuk: (after dpkg-reconfigure -> satellite system)
<Keybuk> I don't want an MTA on here, I want mail to get sent to a smarthost and that's it
<pitti> infinity: still here?
<pitti> infinity: lamont's script for importing langpack tarballs seems to have stopped since 20050826; so I take it that I just pull the tarballs from the buildds myself?
<infinity> Keybuk : ssmtp.conf(5) leads me to believe it support both SMTP AUTH and TLS.
<Keybuk> yeah
<Keybuk> otoh, why does subversion-tools _ABSOLUTELY REQUIRE_ an mta? :
<Keybuk> that should be a Recommends at most <g>
<Lathiat_> use fakes ;p
<infinity> <shrug>... Who knows.
<infinity> pitti : Well, it probably means I was wrong about the script not needing modification.  But if you're ready tp pull from the buildds directly, that's better anyway. :)
<Keybuk> Lathiat_: well, I just stuck something on the end of status by hand
<Keybuk> cat >>/var/lib/dpkg/status <<EOF
<Keybuk> Package: mail-transport-agent
<Lathiat_> Keybuk: eeww ;p
<Keybuk> Status: install ok installed
<Keybuk> Version: 1
<Keybuk> 
<hmrocha> hello
<Keybuk> EOF
<Keybuk> :p
<hmrocha> how can i change the user that is allowed to mount the usb devices?
<hmrocha> i tried in /etc/udev/udev.rules
<hmrocha> changed from plugdev to students
<hmrocha> but it didn't work
<Mithrandir> hmrocha: just add the relevant people to the plugdev group.
<hmrocha> Mithrandir, i tried that, but all users are stored in AD, and getent passwd doesn't return all the users
<hmrocha> but that's what i did
<Keybuk> plugdev is hard-coded into pmount, isn't it?
<hmrocha> Keybuk, it shouldn't be
<Mithrandir> Keybuk: no, but it's just executable by group plugdev.
<pitti> Keybuk: no, why?
<Mithrandir> hmrocha: you could also use dpkg-statoverride and change the group pmount belongs to.
<Keybuk> ah, that's it then
<hmrocha> BUS="scsi", KERNEL="sd[a-z] *", PROGRAM="/etc/udev/scripts/removable.sh %k", RESULT="1", NAME="%k", MODE="0640", GROUP="plugdev"
<hmrocha> this is from udev.rules
<pitti> right
<pitti> but not in pmount
<hmrocha> i hope that works, this is getting me a lot of trouble
<hmrocha> some users can't mount their usb disks
<pitti> Keybuk: the device group matters for hal (hal needs to be in the group of the devices it should know about)
<pitti> but it doesn't matter at all for pmount
<jdub> (YAY PMOUNT!)
<hmrocha> i'll change the group that pmount belongs too
<Keybuk> hmrocha: make sure hal is in your students group too
<pitti> jbailey: it can't be that bad if Gentoo and even SuSE adopt it, and RedHat wants to, too :-)
<Keybuk> SuSE broke it though <g>
<tseng> suse is still using submount
<pitti> Keybuk: well, they asked me to adopt their autocrap stuff
<tseng> unfortaunately
<jdub> is jbailey dissing pmount?
<Keybuk> they took out the fstab code, didn't they?
<pitti> jdub: "dissing"?
<jdub> tseng: the ximians will get it through
<jdub> pitti: disrespecting
<pitti> Keybuk: no that I know
<tseng> jdub: i dunno dude
<tseng> jdub: its getting close to the wire with no luck yet
<CarlFK> 5 min old breezy install, logged in as user, dialog: "failed to init HAL, OK"
<pitti> CarlFK: right, already fixed
<jdub> tseng: oh, not for 10
<tseng> jdub: i beat up on snorp and abock daily
<jdub> you beat up on the wrong people!
<pitti> jdub: I don't know why jbailey should, maybe ask him directly?
<tseng> i know
<CarlFK> pitti - good.  then I wont fight with bugzilla ;)
<tseng> but i already deal with them
<jdub> pitti: you were just telling him it can't be that bad
<tseng> jdub: who do we beat up over this Crystal abortion?
<Keybuk> jdub: no, pitti just needs his <Tab> key removed until he learns to be more careful where he points it <g>
<pitti> CarlFK: tomorrow's CD will work again, and if you just dist-upgrade, it will work, too
<jdub> oh
<hmrocha> Keybuk, ok, i'll do that
<jdub> misfired tab completion
<tseng> jdub: and why isnt planet gnome flaming it silly
<CarlFK> pitti - dist-upgrade now or tomorow?
<pitti> jdub: ETABUSAGE, sorry :-/
<jdub> tseng: well, because most people on pgo don't really care about suse ;)
<pitti> CarlFK: now should work, you need dbus 0.36.1-0ubuntu2
* Keybuk wishes x-chat didn't have menu-style completion :-/
<jdub> pitti: i'm pimping it everywhere :)
<pitti> Keybuk: ok, just restored completion_amount=0 again :-)
<Keybuk> you haven't got anywhere in the world unless you've been flamed on Planet GNOME
<Keybuk> usually by someone who preaches it about a week later
<CarlFK> same breezy install, no dist..up yet: juser@dhcp179:~$ sudo vi /etc/apt/sources.list
<CarlFK> I enter the pw, and it returns me to the prompt.  
<CarlFK> vi alone brings up vi
<CarlFK> vi /etc/apt/sources.list (no sudo) brings up the file readonly (as it should)
<CarlFK> never mind
<CarlFK> user isn't in suders.
<Mithrandir> Kamion: got a second?
<Diziet> keybuk: There's a bunch of code in processarc.c which deals with statting all of the old files and comparing it to the stat of each new file to see if actually some of the `disappearing' files are the same although they have different names due to symlinks.
<ogra> CarlFK, the user doesnt need to be in sudoers
<Diziet> Do you know where it came from ?  It's rather strange.
<CarlFK> because this box was built with a preseed file, a root pw, user and userpw were set.  any idea how to have the install add the user to sudoers?
<Diziet> If it came from somewhere silly then I'll just assume that I'm right and it's wrong.  But if it came from somewhere sensible I should worry that I'm missing something.
<ogra> CarlFK, your sudoers file should have a line like: %admin  ALL=(ALL) ALL
<ogra> CarlFK, and the user should be in the admin group
<Keybuk> Diziet: which lines?
<Mithrandir> Kamion: 13920; verified, seems to be fixed by setting STATE to 8, not 9 on line 317 and 327 of passwd.config.  Seems sane to you?
<hmrocha> Keybuk, it didn't work, i'll try changing udev.rules and restarting udevd, hald and hotplug
<CarlFK> ogra - in a default install, is the user in the admin group?  I thought the insatller just put the username in sudoers
<ogra> CarlFK, that was warty ;)
<ogra> CarlFK, we have the admin group since hoary
<Keybuk> Diziet: 609-647 ?
<CarlFK> ogra - ah. thanks.  good idea ;)
<CarlFK> ogra - so shouldn't that line be in my sudoers? 
<ogra> yup
<CarlFK> or do I just get "root    ALL=(ALL) ALL" because I setup a root pw via the preseed file?
<Diziet> Yes, around there.
<ogra> CarlFK, i have both in a new install
<Diziet> For example, it does rmdir(foo).  And then later in if (ENOTDIR) it goes stat(foo) and checks S_ISDIR.
<ogra> CarlFK, i'm not sure how it gets handled on installation ...
<Diziet> If the rmdir fails ENOTDIR and the stat succeeds then it must not be a dir ...
<Diziet> And it goes on trying to delete the file after failing to stat it, which seems rather enthusiastic.
<CarlFK> maybe I should get my preseed file a bit more in line with a default install.
<Keybuk> +  * Merge patches from Ben Collins <bcollins@debian.org>:
<Keybuk> +    + fix windowresizing in dselect
<Keybuk> +    + when upgrading check if a file is not also in the new package before removing
<Keybuk> +	  it, so we don't remove new files due to symlinks confusing us
<Keybuk>  Tue Oct 12 17:15:08 CEST 1999 Wichert Akkerman <wakkerma@debian.org>
<Diziet> Right, I'll assume I'm right, then :-).  Thanks.
<Diziet> I also rather dislike:
<Diziet>       if (donotrm) continue;
<Diziet>       {
<Diziet> Recipe for confusion.
<mvo> Kamion: would a message like "media-change:$medium:$drive" (e.g. "media-change: Ubuntu 5.10 _Breezy_ : /cdrom") be ok for you? Or should I also send someting human-readable
<pitti> elmo: please sync openvpn
<Keybuk> waaaaaah
<Keybuk> that is horrible
<Keybuk> dpkg has lots of things like that
<Keybuk> people just inserting code randomly into functions
<hmrocha> i'll try rebooting, if this doesn't work, i don't know how i can let users use ubuntu :(
<Keybuk> hmrocha: put them into the plugdev grop?
<Keybuk> uh, group
<hmrocha> Keybuk, i'll try to explain my set up
<hmrocha> Keybuk, all users are stored in AD
<Keybuk> "AD" ?
<hmrocha> i did a very ugly hack that used "getent passwd", with awk to get the username, and add all users to the plugdev group
<hmrocha> Microsoft Active Directory
<hmrocha> all computers boot from PXE
<Keybuk> so you're using nsswitch 
<Keybuk> with something like passwd: active-directory ?
<hmrocha> yes, nsswitch and kerberos, exactly
<Keybuk> right
<Keybuk> can't you just do group: active-directory too
<Keybuk> and add them to the plugdev group that way?
<hmrocha> i don't know :(
<hmrocha> everytime a computer is turned on, it prompts the user for winxp or ubuntu
<Diziet> Also, if you have a set-id special file it fails to chmod it 0, chmodding it to remove the set-id instead.
<hmrocha> they choose ubuntu, it gets downloaded from the server and installed locally (not really like this, but it's something like this)
<Keybuk> otherwise change the plugdev in both places in /etc/udev/permissions.rules, use dpkg-statoverride to change the group of /usr/bin/pmount and /usr/bin/pumount, and make sure hal is in the new group too
<Keybuk> ...
<Keybuk> though I don't understand how you can have this magic "students" group, yet can't have a "plugdev" one
<hmrocha> Keybuk, i didn't use dpkg-statoverride, i used chgroup students plugdev
<hmrocha> i have a plugdev group, but i want all users that belong to students, to also belong to plugdev
<hmrocha> but uid and gid are stored in AD
<Keybuk> you can't do that in UNIX
<Keybuk> groups can't be nested
<hmrocha> can i do that with ACL ?
<Mithrandir> not with any regular NSS module, at least. :-P
<Keybuk> it sounds like you need to add all your students to plugdev in AD
<hmrocha> Keybuk, that's what i don't know how to do
<Mithrandir> hmrocha: just make a plugdev group in the domain manager and then add everybody to it?
<Diziet> Is this an NT support channel, suddenly ?
<hmrocha> Diziet, not, i'm just trying to swith my faculty from mandrake to ubuntu
<Diziet> Ahh.  OK, sorry.
<hmrocha> *switch
<Diziet> I should go back to my (well, Ben Collin's, it seems) code.
<Diziet> Collins's.
<hmrocha> Mithrandir, i'll try that
<xhaker> hello all
<xhaker> is the Services thingy working?
<xhaker> it didn't disabled the ntpdate service :S
<ivoks> xhaker: #ubuntu is the right channel
<xhaker> it is not
<ivoks> :) ok
<xhaker> Services in breezy man
<xhaker> there is a new app/let
<ogra> xhaker, support questions for any release go to #ubuntu
<ogra> that has nothing to do with breezy/non breezy....
<xhaker> since here is where the developers are i thought i would share that it doesn't work here.. and learn if the behavior is known
<xhaker> looks to me that you're all a little pissed of with somebody today
<ogra> did you look in bugzilla for bugs about it ? 
<xhaker> :)
<hmrocha> Mithrandir, i added my student user to the plugdev group in AD, i'll check if it worked
<xhaker> i don't know the name of the thing.. i'm checking the ps aux now
<ogra> xhaker, i dont know why you think that, i only said that breezy support questions go to #ubuntu too, to correct your assumption that #ubuntu is not for breezy support
<xhaker> services-admin
<elmo> Kamion: ?
<xhaker> ogra, and you assumed i was asking for support, i know how to disable ntpdate. i was just leeting you all know and possibly the dev behind it
<xhaker> wow
<xhaker> leeting = letting
<xhaker> lol
<ogra> <ivoks> xhaker: #ubuntu is the right channel
<ogra> <xhaker> it is not
<ogra> <ivoks> :) ok
<ogra> <xhaker> Services in breezy man
<xhaker> ohh, now i realize how you could think that :P sorry
<ogra> :)
<xhaker> i was a bit strict there
<ogra> if you look for a bug, look for gnome-system-tools, its a part of it
<nomed^> hi all
<nomed^> where can i find the breezy usplash?
<mjg59> nomed^: In Breezy
<bddebian> Hello nomed^
<ogra> apt-get install usplash ;)
<ogra> nomed^, mjg59 wrote a fine guide to the ubuntu-devel ML
<nomed^> ok thanks
<xhaker> seb already filled the bug :P
<hmrocha> Mithrandir, i found a better way, i changed the group to "students" but added a suid bit
<hmrocha> it's working perfectly
<hmrocha> ubuntu for everyone now! :)
<hmrocha> i'm very happy
<Keybuk> hmm
<Keybuk> there's some annoying new interaction between zsh and sudo in breezy
<Keybuk> it bitches about "insecure directories and files" and then my ~/.zcompdump gets overwritten
<zyga> hello
<zyga> I'm looking for the source of a popup dialog that appears on hoary after inserting breezy install cd
<zyga> It does not appear to be anywhere on the cd
<ogra> zyga, update-manager
<Mitario> zyga, can you provide a screenshot? maybe I can recognize it
<zyga> sure
<Kamion> Mithrandir: yes, looks like I forgot to renumber those at some point
<zyga> one moment
<Kamion> mvo: that's OK, although if you want to provide a pre-l10ned message so that I don't have to deal with the translation that's fine with me too :)
<Kamion> mvo: although you'd have to make sure that the message never contained newlines, probably
<zyga> http://www.suxx.pl/breezy-popup-dialog
<Kamion> elmo: ?
<zyga> ogra: are you sure?
<zyga> ogra: I'm translating u-m regulary and I've never seen that message
<Saba_Z> fabbione: hi!
<ogra> zyga, pretty sure... either update-manager or -notifier
<daniels> dear seb, i would really like it if my panel stopped crashing all the time, even when i'm not using the computer.  please make it so.  love, daniels
<fabbione> Saba_Z: hey..
<zyga> ogra: thanks I'll double-check
<fabbione> Saba_Z: i just got your package.. is there any reason for moving postinst to preinst?
<Saba_Z> for the upgrade problem
<zyga> mvo: ping
<Saba_Z> fabbione: the argument "upgrade" and "install" are passed to preinst
<Kamion> zyga: update-notifier/src/hal.c
<WaterSevenUb> zyga, ok ... I will check both now...
<fabbione> Saba_Z: ohh eheheh hold on a sec :)
<Mitario> ogra, probably notifier
<mvo> zyga: pong
<fabbione> Saba_Z: # postinst configure most-recently-configured-version 
<ogra> Mitario, see Kamion ;)
<Mitario> ogra, the quick bastard ;-)
<fabbione> Saba_Z: if the package is installing most-recently-configured-version is empty
<ogra> hehe
<fabbione> Saba_Z: so you get something like if [ "$1" ]  && [ -z "$2" ] ; then
<zyga> mvo: what is the status of u-m in cvs? is it frozen?
<Saba_Z> :( :)
<fabbione> Saba_Z: doing that stuff at preinst is more object of troubles than anything else because in a clean install of the system you might not have any of the other config files installed yet
<Mitario> zyga, no
<fabbione> Saba_Z: nothing to be sad :) i was a bit evil on this one ;)
<fabbione> Saba_Z: but you did good :)
<WaterSevenUb> zyga, in update-notifier template in Rosetta it isn't... did you find it?
<fabbione> Saba_Z: it's not an easy catch at all
<Saba_Z> thanks :)
<fabbione> Saba_Z: a lot developer mess them in a much worst way thatn you did :)
<zyga> WaterSevenUb: no, I'm still checking
<zyga> mvo: was update-notifier split from update-manager?
<zyga> (in cvs)
<Mitario> it was never in one package
<Saba_Z> fabbione:  Can I send the new version tommorow :) I 'm so sleepy!
<zyga> Mitario: ah
<mvo> zyga: it was always like this
<zyga> what's the module name then, notifier?
<fabbione> Saba_Z: sure. it's perfectly fine for me. it's the last bit that's missing :)
<fabbione> Saba_Z: have a good night sleep and nice work :)
<mvo> zyga: it's in a svn repository at oops.kerneljanitors.org
* Kamion eyes cdimage's Task override code malignantly
<Kamion> I think it's always been broken
<mvo> Kamion: I can do l10n too in the status-fd message if you want, that shouldn't be a problem
<Saba_Z> fabbione: thanks, :) goodnight!
<fabbione> night :)
<WaterSevenUb> kamion,  you were refering with this -  update-notifier/src/hal.c to the string we were looking for?
<zyga> mvo: is the cvs.gnome.org update-manager module still the current one?
<CarlFK> installing breezy on a 40g drive that is all ntfs.  picked the first option "resize and use free space."  when I picked, the screen went blue with white bar at bottem.  that was about 5 min ago.  shouldn't there be some sort of "wokring..." message?
<Kamion> mvo: if you've already got a translated message in apt, that would certainly be best
<Kamion> WaterSevenUb: yes
<Kamion> CarlFK: probably, yes
<mvo> zyga: yes, but the code is much ahead of the version in breezy (but not ready for breezy unfortunately)
<Kamion> CarlFK: there are already open bugs about partman's ntfsresize support being inadequate in places
<mvo> zyga: if you want to translate it, rosetta is probably the best choice right now
<WaterSevenUb> zyga, it apparently is in update-notifier as kamion is saying.... but it isn't in the templates...  the question now is why?
<Mitario> WaterSevenUb, maybe forgotton to l10nize?
<zyga> mvo: one last question, do you plan to apply the i18n patches I've sent?
<Mitario> eh i18nize whatever :)
<zyga> WaterSevenUb: I'll try to check out the source for u-n in a moment, I've never used svn
<Kamion> WaterSevenUb: because po/POTFILES.in doesn't contain src/hal.c
<Kamion> mvo: ^--
<mvo> zyga: for update-manager? I haven't managed to look at them yet, but yes, very probably 
<CarlFK> also, I don't see any disk io - does it crunch data for a while trying to fiugre out how to re-arange things?  or is it really hung?
<mvo> Kamion: *ick* thanks
<zyga> mvo: great, thanks!
<Diziet> failed= "chmod";   ....     _(failed)    evil ?
<WaterSevenUb> kamion, so what should be done, file a bug. Affirmative case, where?
<Kamion> CarlFK: I don't know how the internals of ntfsresize work. Look at ps to see what's going on
<Kamion> WaterSevenUb: I just told mvo about it above and he acknowledged it, so I imagine there's no need to file a bug anywhere
<Kamion> Diziet: yes, evil; I doubt xgettext is going to manage to extract the translated string in that case
<WaterSevenUb> kamion, mvo, thanks :)
<mvo> WaterSevenUb: thanks for noticing
<WaterSevenUb> mvo, will you reuse the translations already in Rosetta when you include that in the POT file?
<zyga> mvo: err, is there any howto about that svn repo? the site seems slow or dead?
<Diziet> xgettext greps the source for _("...") constructs, then ?  Should I     failed= _("chmod")  ?
<CarlFK> Kamion - ps shows /bin/sh /lib/partman/automaticly_partition/resize
<mvo> zyga: install subversion, than "svn co https://oops.kerneljanitors.org/repos/upgrade-notifier/"
<zyga> mvo, thanks again
<mvo> zyga: your welcome
<Diziet> The xgettext manpage and info page don't say what it does, unfortunately.
<Kamion> Diziet: Yes, roughly. I'd question whether anyone will actually want to translate the string "chmod", though ...
* zyga really needs to finish his sbs script wrapping things like cvs, svn and tla under one simple interface
<Diziet> In this case it's sometimes "delete".
<Kamion> Diziet: Is that string inserted into the middle of a sentence?
<CarlFK> how do I find these partman bugs?  so far bugzilla says "no bugs" for everyting I search for
<Diziet> Yes.  There are two sentences it appears in and they're very similar.
<CarlFK> nm, found 32 bugs
<Kamion> Diziet: then you should mark a format string representing the whole sentence as translatable, rather than trying to put the sentence together out of translatable pieces
<Diziet> That's not possible because there's nowhere that knows the whole string.
<Kamion> somebody might want to translate "chmod" to "change the mode of", and in (e.g.) German that might well involve putting "the mode of" before the filename and "change" after it.
<Kamion> Correct internationalisation does often involve rejigging code, yes.
<Diziet> Well, I could construct the English sentence out of pieces and then let the translators translate each version separately.  But there are about 6 or 8 cases.
<Diziet> And you couldn't grep for them.
<zyga> mvo: as usual I've found i18n stuff to fix, I'll send you a patch along with pl.po ASAP
<Kamion> unfortunately that's usually the only approach that actually produces sanely translatable messages
<Kamion> CarlFK: if .../automatically_partition/resize is showing in a ps listing and not ntfsresize, then it might be the resize script itself hanging
<Kamion> CarlFK: I'd start by (a) looking through /var/log/partman and (b) putting 'set -x' near the top of the resize script, sort of in parallel
<mvo> zyga: that's great, thanks
<Kamion> I got larted recently by a Finnish translator for assembling a sentence out of pieces (although it was code I'd inherited, not written)
<Diziet> Like this, then ?
<Diziet>     char mbuf[250] ;
<Diziet>     snprintf(mbuf, sizeof(mbuf), "failed to %s `%%.255s'", failed);
<Diziet>     ohshite(_(mbuf),pathname);
<mvo> Kamion: the default apt media-change string contains some \n :/. I need to build my own then
<Kamion> Diziet: that won't work, would have to be _("failed to %s `%%.255s'")
<mvo> Kamion: it will be a long message, is debconf able to wrap it?
<Kamion> (and should that really be %% not %?)
<Kamion> mvo: yes, debconf does its own wrapping
<mvo> Kamion: ok, great
<Kamion> Diziet: the thing inside _(...) ends up as the msgid in each .po file
<Diziet> k: No, you don't understand.  So failed is something like "delete" or "chmod".
<Diziet> mbuf ends up with  "failed to delete `%.255s'"  which is translatable.
<Kamion> But the piece that extracts translatable strings does not run the code!
<Diziet> You're saying that "failed to %s `%.255s'" isn't translateable.
<Diziet> Indeed, as I said earlier `And you couldn't grep for them' to which you replied `unfortunately that's usually the only approach that actually produces sanely translatable messages'.
<Kamion> since the first %s has a verb substituted into it, I'd say not.
<Diziet> There's another place in the code where it says  "failed to %s old file `%.250s'"
<Kamion> I would rewrite that as if (condition_for_delete) snprintf(mbuf, sizeof(mbuf), _("failed to delete `%.255s'")); else snprintf(mbuf, sizeof(mbuf), _("failed to chmod `%.255s'"));
<Diziet> Cripes.
<Diziet> That's insane.
<Diziet> I have to replicate that code everywhere I use the thing that sets failed ?
<Diziet> I could use a macro but then xgettext ....
<CarlFK> Kamion -  "tail /var/log/partman" gives "parted_server: Line 
<CarlFK> 1081. CRITICAL ERROR!!!  EXITING." as the last line. - which is http://bugzilla.ubuntu.com/show_bug.cgi?id=13570
<Kamion> well, you can do the snprintf yourself I suppose
<Diziet> Do the snprintf myself ?  Eh ?
<CarlFK> is that enough for me to change UNCONFIRMED to NEW?
<Kamion> sorry, I have a small child crying at me, excuse incoherency
<Diziet> *sympathy*
<Kamion> that should've been "you can assign _(...) to a variable in each case and do the snprintf in one place later"
<Kamion> but the bit inside _(...) generally cannot be split up or composed from natural-language pieces at run-time (obviously, substituting non-translatable things like filenames is OK)
<Diziet> This is because of the limitations of xgettext ?
<Diziet> And not for any other reason ?
<Kamion> Diziet: no, it's because different languages might want to put the pieces you're trying to compose in a different order
<Diziet> You're missing what I'm doing.
<Kamion> "chmod" might well not be a single piece substitutable by one %s.
<Kamion> the translation of "chmod", rather.
<Diziet> If I compose /the piece inside/ _(...) out of English so that it makes an English sentence then the msgid will be always an English sentence with all the pieces substituted.
<Diziet> So in my code with mbuf above, _(...) gets called like this _("failed to chmod `%.255s'") although the string inside ( ) is actually in mbuf.
<Kamion> OK, I suppose that's down to the limitations of xgettext in that there does not currently exist a msgid extractor that analyses the code to determine all possible constructed msgids.
<Diziet> I'd be happy to annotate my code suitably.  Provided it doesn't require me to replicate chunks of it !
<Kamion> That extraction has to happen at build-time or else how do the translators know what to translate?
<Diziet> Yes, but if the extractor were cleverer then I could annotate my code in a way that would allow the extractor to compute the set of possible messages.
<Kamion> ah, I see what you're getting at
<Diziet> What does xgettext currently do if you say  _(some expression it can't figure out)
<Diziet> ?
<Kamion> I think what I might do in your case is put the strings in #defines somewhere and assemble them inside a redundant gettext_noop() call somewhere; xgettext will be able to find the thing inside gettext_noop()
<Kamion> currently do> ignore it, AFAIK
<Kamion> the 'Preparing Program Sources' node of info gettext has various bits of useful advice
<mvo> zyga: plesae do a svn up in the update-notifier dir, I added hal.c to POTFILES.in (and reworded a message)
<zyga> mvo: k
<zyga> mvo: I've noticed a very subtle issue
<mdz> morning
<zyga> mvo: i'm not sure you'd agree but here it goes:
<jdthood> mornin'
<zyga> when there are post update informations the tooltip says something like "click here to display post update info"
<Mitario> mako, elmo ping
<zyga> now the trick is: to correctly translate I need to know if there is one information or many 'informations' 
<zyga> this becomes as subtle as 'informacj' (singular) vs 'informacje' (plural)
<mdz> jdthood: the which->type change was a performance/simplicity thing
<jdthood> mdz: Ah, OK
<mvo> zyga: so it need to be a plural_gettext string? fine with me
<zyga> mvo: do you know any way to run ./autogen.sh on  hoary and produce usable makefiles (for update-po and such)?
<mdz> jdthood: some people were also having trouble with PATH; maybe they had older util-linux versions
<zyga> mvo: yes, I'll pach this too
<zyga> patch
<Diziet> k: I'll do the thing with gettext_noop.  That'll at least twig the translators that there's something odd going on.
<mdz> that could probably have been addressed with a dependency, but this method had other benefits
<mvo> zyga: ./autogen.sh does not work on hoary for you?
<zyga> mvo: no libnotify 
<zyga> mvo: it's only in breezy
<zyga> (i've resorted to cp random.po pl.po)
<mvo> zyga: you need it only for i18n, right? just remove libnotify from configure.in (pkg_modules line)
<Kamion> Diziet: right - sorry for the misunderstanding above
<Diziet> Is N_( ) an alias for gettext_noop ?
<Diziet> k: Thanks, NP.
<zyga> mvo: smart, thanks
<mvo> Diziet: yes
<Kamion> well, typically you #define gettext_noop() and N_() yourself, but that's what xgettext expects, yes
<Kamion> (info gettext, 'Comparing the Two Interfaces')
* lamont -> office
<zyga> mvo:what do you mean by: "Click on the update item or the link to see the available Updates"
<zyga> mvo: update item??
<mvo> zyga: the little red icon that the arrow points at
<zyga> mvo: I think I know where it appears but I'm puzzled about 'update item' what's that?
<zyga> ah
<zyga> sorry :)
<zyga> now I understand
<zyga> maybe that should be called 'update icon'?
<Diziet> k: Something has already done N_ in dpkg.
<mvo> zyga: right, that looks like a typo 
<zyga> I'll fix it, thanks
<mvo> good morning mdz, do you have a moment and if so, can I /msg you?
<zyga> mvo: since this is not getting into breezy it's okay to break translations, right?
<mvo> zyga: update-notifier is getting into breezy and we need to fix the strings today because tomorrow is string-freeze
<mvo> s/getting/going/
<zyga> mvo: argh... 
<mvo> zyga: yeah :/
<mdz> mvo: if it is about debian apt, I'm sorry but I haven't had time to think about it recently
<zyga> I've improved some wording too, you may simply ignore that if you don't want to break too many translations
<zyga> s/translations/existing translations/
<mvo> mdz: yes, it's about that, sorry that I bug you about it. enrico was asking for a upload that fixes #321799 (it block his debtags work)
<mvo> zyga: thanks, that should be ok (I'll look over it again)
<mvo> Kamion: install-daily is hanging here, it looks like it's doing a "configure initial-passwd-udeb" ? a bad burn?
<wasabi> Hmm. We don't have the jabberd2 aim/irc stuff packaged.
<mdz> mvo: feel free to prepare an upload from your branch
<mvo> mdz: thanks, I will do that. there are various fixes that piled up. can I do the upload or would you rather like to do the upload yourself (after you merged the branch into apt--main)?
<mvo> anyone else tried daily install today?
<fabbione> mvo: i am finishing the install right now
<pitti> mvo: well, just upgrading from hoary to it
<mvo> and you haven't noticed a hang? then I'll retry with a new cd
<fabbione> mvo: no.. it's going pretty smooth
<fabbione> mdz: for the livecd there was a dbus/hal problem that i believe pitti did fix with an upload...
<pitti> yes, I did that today
<fabbione> it probably affects install cd too
<pitti> yep, it does
<fabbione> didn't get there yet
<mdz> pitti: which version(s) do we need?
<pitti> mdz: dbus 0.36.2-0ubuntu2 had the fix, -0ubuntu1 broke it
<pitti> s/had/has/
<pitti> mdz: 0ubuntu1 missed the DEBHELPER token, so it simply didn't start
<mdz> pitti: building new livefs images and install CDs
<mdz> Kamion: what do you think about having installerstage2progress use usplash?
<zyga> mvo: POTFILES.in does not contain most of the .glade files, is this intentional?
<mvo> zyga: probably not
<zyga> mvo: fixed
<mvo> zyga: thanks
<zyga> mvo: "Please enter the root password to start the package manager", doesn't ubuntu use sudo and root is paswordless?
<hughsie> anyone with an ibm, asus or panasonic laptop?
* Robot101 has an X40
<bddebian> I have a StinkPad
<hughsie> if you have ibm, can you do a "cat /proc/acpi/ibm/brightness" pls
<pef> can someone explains me why DMA is not enabled by default on drives ? (hdd and optical drives)
<hughsie> i'm writing the lcd support for hal
<mvo> zyga: yes, that should be "your password"
<hughsie> Robot101: what make is a X40?
<Robot101> hughsie: IBM
<bddebian> hughsie: I don't have an ibm dir under acpi
<hughsie> modprobe acpi_ibm?
<hughsie> modprobe ibm_acpi, sorry
<hughsie> Robot101: what about you?
<bddebian> Nope, neither
<Robot101> hughsie: sorry, had to unsleep and hook it up to charge
<Robot101> robot101@theta:~$ ls /proc/acpi/ibm
<Robot101> bay  bluetooth  dock  driver  hotkey  light  video
<hughsie> Robot101: cat /proc/acpi/ibm/* pls
<Robot101> http://pastebin.com/351122
<doko> third time that firefox crashes today on amd64 ...
<hughsie> Robot101: obv. ubuntu doesn't switch on the experimenatal stuff
<Robot101> hughsie: actually this is a sarge box, but I've got ubuntu's kernel and acpi-support
<hughsie> can you put experimental=1 in your modprobe command and reload ibm_acpi
<Robot101> (which means my hald crashes at bootup for no apparent reason, but I can't upgrade it because of dbus)
<Diziet> keybuk: this status-fd conffile prompt doesn't carry all of the information that the dpkg-issued prompt does.
<Keybuk> that's true
<Keybuk> it carries enough for what mvo wanted it for though, I guess
<Diziet> Do you know what that was ?
<Robot101> hughsie: http://pastebin.com/351126
<Keybuk> it's used to hide dpkg output during the installer and synaptic
<Diziet> It's not good enough to ask the user the question.
<zyga> mvo: patch away
<Diziet> Oh, just for answering automatically ?
<Keybuk> I think they use it to switch back to the dpkg console
<Keybuk> more as a "dpkg needs to ask something" than anything else
<Diziet> Ah, right.
<Diziet> I see it doesn't suppress the dpkg-generated messages.
<Keybuk> yeah
<mvo> Keybuk, Diziet: it should carry enough information. I hide the dpkg prompt and display a gtk dialog
<Keybuk> it's just so you can hide the usual scroll
<Keybuk> oh, there you go, he does something else
<hughsie> Robot101: thanks, it would apear your laptop doesn;t support brightness!
<hughsie> Robot101: what kernel you running?
<mvo> it does not supress because a terminal (vte) is still runing (because postinst script do nasty things sometimes that require a terminal)
<mvo> Diziet: what information is missing?
<Robot101> hughsie: it's definitely in the ibm_acpi 0.8 module?
<Robot101> hughsie: 2.6.12-6-686
<hughsie> Robot101: definatly. I'll ask davidz as I *know* he got this to work.
<hughsie> thanks for your help tho
<mvo> (it's very likely that I overlooked something, I haven't dived deep into dpkg
<Kamion> mvo: I've never seen that myself, although I haven't tried today's
<Diziet> Well, if you wanted to be able to automatically answer the question, it should contain the `what' information, ie cfof_... flags.
<Kamion> mdz: I doubt that would be sufficient for anything more than the default case
<Kamion> mdz: i.e. as soon as, say, xserver-xorg needed to ask a question, I'd have to drop back to debconf anyway, and I don't really want to deal with *any* extra complexity there
<mvo> Kamion: looks like a bad burn, the second run I'm workig fine so far
<Kamion> mvo: ah good, thanks
<Diziet> I've just had a horrid thought.  How can dpkg tell the difference between `this conffile is removed from the package and its conffiles and so the user should be asked whether to remove it' and `this conffile is now going to be handled by the maintainer scripts and dpkg should leave the existing one in place'.
<Robot101> hughsie: np, feel free to ping if you want anything else tested... or happen to know why http://pastebin.com/351131 happens :D
<Robot101> hughsie: (when hald starts, it makes it crash... 0.4.7-3sarge1 though, but dbus foo makes it hard to upgrade)
<hughsie> Robot101: okay, will do. and your trace... are you running a tainted kernel?
<Robot101> nope
<hughsie> hmm. hald shouldn;t do that...
<Robot101> it is hella old and my kernel is 0-day breezy crack, but I'd like to know the path of least resistance to having sarge but have all my hardware work too :)
<zyga> mvo: will you apply the patch before midnight?
<hughsie> Robot101: you can't use the ubuntu dbus?
<mvo> zyga: yes
<mdz> Kamion: good point
<Robot101> hughsie: 0.3x is incompatible with 0.2x, it would mean pulling essentially the whole of breezy
<Robot101> hughsie: and I have a seperate partition for that, and it's utterly broken :P
<hughsie> Robot101: I thought that would be the case.
<mvo> Diziet: I don't understand why I would want to automatically answer it? isn't that the job of dpkg? The status is only send if dpkg prompts at the terminal and then the submitted information is enough, no?
<Diziet> I naively assumed that the status-fd stuff was supposed to let you completely bury dpkg :-).
<mvo> Kamion: daily install fine so far except the cdrom prompting because "mozilla-firefox-locale-en-gb" is not copied by archive-copier
<mvo> Diziet: oh, right :) unfortunatly *cough* not
<Robot101> mjg59: I realised that having sarge and breezy share the same swap partition doesn't break swsusp provided I have the same kernel on both. the initrd of whichever boots first will just clobber the running system with the suspended one... theoretically
<Robot101> mjg59: so I'll resume sarge and be in breezy, or vice versa :D
<Kamion> mvo: right, I'm working on that right now
<mvo> Kamion: sure, it was just FYI
<jbailey> Robot101: Resumng wit hthe wrong partition is bad fu, in general.
<jbailey> Nothing good can come of it.
<Robot101> oh I know :)
<pef> bye !
<Diziet> keybuk: see my latest mail.
<fabbione> dpkg-source: error: unrecognised file suffix `.diff'
<fabbione> hmm
<pitti> fabbione: where did the .gz go?
<fabbione> pitti: that's what i am trying to undestand
<fabbione> it's the build log of kio-locate on sparc
<Keybuk> fabbione: update dpkg to 11
<fabbione> that seems to be ok on other arches..
<Keybuk> or ubuntu2
<Keybuk> depending on whether it's a Debian or Ubuntu buildd
<fabbione> Keybuk: ah ok.. thanks
<fabbione> it's a mix..
<Keybuk> and send a small tac-nuke to bod
<fabbione> i will just install one :)
<Keybuk> pitti: it can be either diff.gz or diff.bz2
<fabbione> mehhhhh
<fabbione> this update would cost me a lot...
<fabbione> given that apt-ftparchive goes in bus error with new glibc
* fabbione ponders...
<Kamion> fabbione: changelog suggests that new apt-listchanges works around that?
<fabbione> Kamion: oh.. i didn't check in a long while.. 
<fabbione> thanks for noticing :)
<mvo> fabbione: apt-listchanges segfaults for you?
<fabbione> mvo: apt-ftparchive
<fabbione> well we will see in not too long from now :)
<fabbione> i an upgrading the box
<fabbione> am even
<mdz> Kamion: another cron.daily?
<mdz> Kamion: I had just finished building a set
<mdz> Kamion: we need a live build when you're finished
<mjg59> Robot101: True
<mvo> fabbione: if it still segfaults, could you please send me a backtrace?
<Kamion> mdz: testing fixes for install CD breakage
<Robot101> mjg59: unless I boot a new kernel by mistake, when it will ignore the swsusp image, and swapon and nuke it just after it craps up the journalling filesystem... so either way it /should/ work
<mdz> Kamion: how do you feel about a colony tomorrow?
<Kamion> mdz: not enough data yet
<Kamion> may be able to answer you later tonight
<fabbione> mvo: sure..
<fabbione> if still segafault the roof of your house will be bombed with lightnings
<fabbione> mvo: because that will kill my local cache :)
<mvo> *cough*
* mvo hides from fabbione 
<mdz> Kamion: I was feeling pretty good about it mondayish
<mdz> let me know
<Kamion> mdz: I'm out of your way now; go ahead and cron.daily-live
<mdz> Kamion: launched, thanks
<Kamion> mdz: the language-support-* copying mess is release-critical, I think; lots of bugs about that
<hunger> Hey, X came up without me having to run udevstart to generate /dev/input/mice! Thanks for working on that!
<hunger> Damn... you are busy! I updated less than 4h ago and already there are abaut 40MiB new packages!
<pitti> hunger: nice that the new udev works :-)
<xhaker> today is the last day of summer of code isn't it?
<mdz> Kamion: will you still be around a bit later?  we should review blockers for preview
<Kamion> mdz: I'll be out for the next hour or so returning hired glasses from the wedding reception, and then making dinner for the child; but I'll be back after that
<hunger> Is xdm broken or did I break my config again? It fails in postinst with status 1.
<mdz> Kamion: ok, ping me if you're available, otherwise, we'll talk in your morning
<fabbione> mvo: still bus error :/
<Kamion> hunger: bug #14412
<fabbione> mvo: what can i do to help debugging?
<mvo> fabbione: a backtrace would be good 
<hunger> Could someone please add an if [ -d /dev/hda ] ; then ... fi around the hdparm stuff in /etc/init.d/acpi-support?
<hunger> My laptop has no hda and the script keeps nagging about that.
<ivoks> hi
<mjg59> hunger: There's only one reference to hda in acpi-support, and it won't be triggered unless you've altered your configuration
<mjg59> Try upgrading
<hunger> mjg59: acpi-support runs hdparm twice.
<mjg59> hunger: Where?
<hunger> mjg59: In fact two in start and one in stop...
* mvo is away for a bit
<mjg59> hunger: No it doesn't
<hunger> mjg59: It does here... let me check where that file comes from...
<mjg59> hunger: Which file?
<hunger> mjg59: /etc/init.d/acpi-support lines 22,23 and 34.
<hunger> mjg59: Just purged and reinstalled... it is there.
<mjg59> hunger: My apologies, you're entirely right
<mjg59> hunger: Please file a bug, I'll fix that
<hunger> mjg59: Thanks!
<hunger> mjg59: #14431
<mjg59> hunger: Thanks!
<Robot101> mjg59: did you fix the RTC thing? :P
<mjg59> Robot101: Not yet
<Robot101> mjg59: can you set the RTC to wake you from sleep after a fixed period of time?
<mjg59> Robot101: Yes
<mjg59> See /proc/acpi/alarm
<Robot101> mjg59: or when the battery gets down to a particular level? :)
<mjg59> No
<Robot101> aww
<mjg59> That's hardware dependent
<mjg59> Most modern machines seem to resume shortly before the abttery runs out
<elmo> eh, am I being particulary stupid or something; a web browser should respect /etc/hosts right?
<hunger> elmo: depends on your resolver config IIRC.
<Robot101> elmo: modulo proxy settings...?
<fabbione> elmo: nsswitch.conf? or whatever is called?
<mjg59> elmo: Mozilla certainly used to have its own resolver
<fabbione> night everybody
<fabbione> cya tomorrow
<sabdfl> night fabbione
<ivoks> fabbione: bye
<pitti> cu fabbione 
<slomo> hi... can someone with main upload rights upload this for me? fixes FTBFS and is a really small change... http://yggdrasil.sytes.net/files/debdiff/mono_1.1.8.2-1ubuntu4.debdiff
<Diablo-D3> hey all
<pitti> tseng: here to help slomo?
<Diablo-D3> No one seen daniels lately?
<Diablo-D3> he asked me to "output of DEBUG_XORG_PACKAGE=yes sudo dpkg-reconfigure -phigh xserver-xorg, please."
<pitti> nope, he is certainly deep asleep
<tseng> pitti: sure
<tseng> pitti: whats up?
<Diablo-D3> how would one do that and still be able to control debconf?
<pitti> tseng: see slomo above
<slomo> pitti: tseng is busy atm ;) otherwise he would've uploaded it already
<pitti> tseng: ah, ok
<tseng> ah i told him i was just leaving
<Diziet> I should stop and log off, really.
<Diziet> Then I can have dinner.
<pitti> slomo: ok, I can do that
<slomo> pitti: thanks :)
<Diablo-D3> anyone?
<tseng> thanks pitti, later all
<Diziet> Goodnight everyone.
<pitti> night Di
<pitti> night Diziet 
<Diablo-D3> beuler?
<pitti> slomo: uploaded
<slomo> pitti: thanks
<sivang> does anybody esle try to msg nicksrv without success?
<sivang> pitti: do you have any specific g-c-m stuff you'd like me to have a look at, or should I just browse the ones assigned to you?
<sladen> Robot101: grep . /proc/acpi/ibm/*   is good
<sladen> hughsie: on ThinkPad's the brightness is hardware controlled and pass though 3 bits in the /dev/nvram
<hughsie> sladen: davidz has a /proc/acpi/ibm/brightness file
<Diablo-D3> you know
<Diablo-D3> openbox rocks
<hughsie> sladen: perhaps a newer ibm_acpi?
<CarlFK> breezy: "cannot touch `x': Read-only file system" but mount shows /dev/sda1 on /media/sda1 type ntfs (rw)
<CarlFK> shouldn't mount show (ro) ?
<sladen> CarlFK: good point
<CarlFK> but i did mount it with the mount command, so I am not sure what could be done about it
<Robot101> jdub: ping
<Robot101> jdub: what's the deal with mdnsresponder in sid?
<elmo> christ, bugzilla searching is teh useless
<sivang> elmo: you have hard time finding stuff by package? I also get annoyed by that
<sivang> elmo: it seems to ignomre my serach phrase
<slomo> mdz: will we get something done with ffmpeg for breezy? seems like our version is also the cause for mplayer crashing on ac3 audio... but i'm not entirely sure yet
<mdz> slomo: if kino is changed not to use it, it will fall out of main naturally
<mdz> assuming nothing else depends on it
<mdz> I'm happy to move it if kino is changed, but I don't know what the effect on kino would be
<pitti> mdz: are you opposed to adding postgresql-pl{perl,python} to the seeds? These packages were split out of the main server package in breezy
<slomo> mdz: the only effect on kino would be possible slower dv decoding on non-x86 architectures (i don't know if this is still valid... that was 2003 iirc). it would loose no features
<mdz> pitti: no
<mdz> slomo: ok
<pitti> mdz: ok, thanks
<mdz> pitti: could you review slomo's patch and upload it if you agree?
<pitti> mdz: sure
<pitti> slomo: which patch?
<mdz> pitti: thanks
<mdz> pitti: forwarding it to you now
<slomo> pitti: http://yggdrasil.sytes.net/files/debdiff/kino_0.75-7ubuntu1.debdiff
<slomo> mdz: will i get preview freeze exception for changing ffmpeg and recompile everything against the new one?
<mdz> slomo: since nothing in main is affected, the preview freeze doesn't apply
<sivang> pitti: I can handle #11282 unless we want it handled upstream, pretty trivial i guess
<slomo> mdz: oh, i thought preview freeze applies also to universe... thanks for clarifying this :)
<mdz> slomo: MOTU are free to set their own schedule for universe; if there is a policy in place then it comes from MOTU and not from me
<pitti> sivang: sure, that's easy; just send the patch upstream as well :-)
<slomo> mdz: ok, i'll talk to ogra about that
<sivang> pitti: funny, there is a lot of space down the dialog , I wonder how no one thought aobut using it before L:)
<elmo> did these ttf fonts always take so long to run their postinsts?
<Mithrandir> elmo: we have a fair amount more of them now, I think.
<pitti> slomo: ok, so kino works as before without libavcodec?
<slomo> pitti: i didn't test it (i have no dv encoded stuff lying around) :( but this is from kino's configure: "--with-avcodec       Use FFMPEG libavcodec for DV video decoding instead of libdv."
<pitti> slomo: ok, I just read the mail you sent to Matt; the reasons sound sane
<pitti> slomo: and thanks for eliminating static libraries! :)
<slomo> pitti: np :) so you will upload this?
<pitti> slomo: yes, doing now
<slomo> pitti: thanks :)
<pitti> slomo: *removing* packages from main is something I always like to do :-) It happens seldom enough
<elmo> mjg59: ?
<slomo> mdz: and please care that ffmpeg gets into multiverse, not universe ;) otherwise we won't be able to use marillat's package and can't support aac through faad2 for example
<pitti> slomo: if ffmpeg is not actually used any more anyway, why should we care?
<pitti> slomo: or can it be used dynamically?
<mdz> slomo: I will
<slomo> pitti: it is used by some multiverse stuff (transcode, mplayer, smilutils, ....)
<hunger> Is NM updated again? j^ did lots of work on it from what I heared.
<slomo> hunger: afaik it only waits for someone to upload it ;)
<pitti> slomo: Accepted kino 0.75-7ubuntu1 (source)
<slomo> pitti: :)
<slomo> elmo: can you remove the old mplayer binaries from the archive for breezy? mplayer-custom, mplayer-amd64, mplayer-686, mencoder-k7, mencoder-custom, mencoder-amd64
<mdz> pitti: new install and live CDs are now up with dbus 0.36.2-0ubuntu2
<sivang> night all
<dieman> yay, came back to one of my old bugs and fixed it. :)
#ubuntu-devel 2005-09-06
<Kamion> mdz: yo
<mdz> Kamion: hi
<ajmitch> morning
<Kamion> mdz: do you have a preliminary list of preview blockers? I'm way, way behind on the bug list
<mdz> Kamion: get usplash enabled by default, fix the virtual console switching problems on the live cd, and fix the language-support-* problem
<mdz> Kamion: I'm behind on installer bugs, too, but the basics were working fine as of Colony 3
<mdz> Kamion: any clear blockers on your end?
<Kamion> I've just uploaded archive-copier 0.3.0, which should fix the language-support-* in conjunction with germinate and cdimage changes I made earlier today; but the .0 reflects a lack of testing in the context of the installer
<Kamion> mdz: there are various bugs about magic-resize causing parted_server to crash or otherwise falling over, which concern me quite a bit
<mdz> Kamion: I think a Colony this week would be a good idea as preparation for preview
<Kamion> agreed
<Kamion> I'll see what I can do tomorrow
<mdz> current i386 live CD is working on my laptop, modulo the console switching bugs
<mdz> which is encouraging in the face of allthe apparent X autodetection regressions
<mdz> mjg59: around?
<mjg59> mdz: Hi
<mdz> mjg59: so I dug a bit into this VT switching problem
<mdz> and it's clearly impossible that this is happening
<Kamion> well, the right way to install usplash by default on first boot, if you don't want it as part of minimal, is probably to create a usplash-udeb that installs it in a base-installer hook
<Kamion> and make that priority standard
<mdz> X only does VT_WAITACTIVE _immediately_ (next statement) after VT_ACTIVATE
<Kamion> I don't know if that's packaging overkill though
<mdz> the race should be incredibly small
<mjg59> mdz: Nngh
<mjg59> mdz: But it doesn't seem to happen off hard drive
<mdz> mjg59: right
<mdz> and it doesn't happen if we QUIT usplash
<mjg59> Yeah
<mdz> of course, on the hard drive, X starts first
<mdz> while on the live CD, usplash seems to timeout first
<mjg59> Mm.
* mvo goes to bed now
<mjg59> Can you hack usplash, extend the timeout and see how it behaves?
<mdz> I wonder if I could get it to happen on the hadr rdive
<mdz> hard drive
<mdz> maybe decrease the usplash timeout to <= X startup time
<mdz> or that
<mdz> easier to mess around on the hard drive than on the live cd
<mjg59> Do you want me to add support for changing the timeout?
<mjg59> It'd probably make it easier to test
<mdz> a command line parameter would be quite handy
<mjg59> I can give you either a command line parameter or a usplash_write command
<mdz> you haven't seen this happen yet, have you?
<mjg59> Nope
<mdz> if you could download a live CD and try it, I'd be interested to know a) that it's not just me, and b) if seeing it gives you any ideas
<mjg59> Hm. No blank CDs, I'm afraid.
<mjg59> (Need to rectify that at some point)
<mdz> tricky
<Nafallo> mjg59: that's what CD-RWs are for indeed :-)
<CarlFK> hows the pxe boot live CD coming?
<CarlFK> i vaugly remember a few months ago someone having some interest in it, and sayind "shouldn't be to hard"
<mdz> CarlFK: it's still perfectly workable in concept but nobody has written the code
<mdz> and it's certainly not a priority for me
<CarlFK> heh - like many thiungs. 
<CarlFK> understood
<mdz> would be handy to have xserver-xorg-dbg on the live CD so I could trace this out
<CarlFK> doesn't apt-get work?
<mdz> it's too late by that point
<CarlFK> ah.
<mdz> I need it when usplash is still running
<mdz> though maybe I could simulate it by starting usplash again later
<mdz> in fact I should try that in the non-livecd environment right now
<Kamion> you could write a post.d script to apt-get install it, I'd've thought
<mdz> Kamion: that's true too
<mdz>         Identifier      "ATI Technologies, Inc. Radeon Mobility 9000 (M7 LW)"
<mdz>         Driver          "cirrus_laguna"
* mdz howls at the moon
<tseng> a clever pairing, at least
<Nafallo> :-)
<mdz> I can't get this to happen outside of the live CD at all
<mjg59> Hrm.
<mdz> mjg59: QUIT should have the same effect as the timeout, right?
<mjg59> mdz: I think so. Let me check.
<tseng> mjg59: hibernate is still broken across the board, correct?
<mdz> looks like it
<mjg59> tseng: Depends. Hang on.
<mjg59> tseng: The fix I sent to Ben isn't in the changelog, so I guess so
<tseng> win
<tseng> ill test it again for good luck
<mjg59> I'll chase up Ben
<mdz> yay gdb
<mdz>  /build/buildd/gdb-6.3/gdb/linux-nat.c:495: internal-error: wait returned unexpected status 0x4057f
<mdz> gdb can't debug Xorg-debug
<mdz> can someone try the current daily live CD for me?
<mdz> I need to know if this is just some incredibly lucky race on my hardware
<mdz> i386 or amd64 is fine
<elmo> well, I can in 50 minutes...
<Kamion> elmo: re your powerpc lvm bug, installation on lvm isn't supported yet on powerpc so I'll probably just disable that option
<Kamion> elmo: have you tried it on i386/amd64 recently?
<elmo> Kamion: not yet
<elmo> we're planning on starting breezy server testing tomorrow and/or whenever next colony is
<slomo> hm, is someone with an ibook g4 here who runs an (fairly) up to date breezy with initramfs and the like?
<crimsun> tritium has an ibook or an imac, I don't remember which
<tritium> hmm?  I have a new 20" iMac...
<tritium> What's up?
<mdz> Kamion: it was suggested that perhaps the lvm option should be less obvious; I'm inclined to agree if that's easy to do
<crimsun> tritium: slomo was asking for someone with an ibook g4
<tritium> Oh, okay.  hoary and breezy kernel panic on the new iMac, so I can't put ubuntu on it yet anyway
<Kamion> mdz: I do think it gets in the way too much as it is given that we decided not to make it the default, but I'm unsure as to where else to put it
<slomo> tritium: for breezy what panic do you get? something about unable to mount root fs?
<tritium> slomo, sounds right.  It has been a while since I tried it.  I'll try again if you like.
<slomo> tritium: would be perfect :) i talked to the kernel guys already but they couldn't reproduce my problem and had no idea what was wrong
<tritium> Okay, I'll download a daily image and give it a try.  It'll be a few hours before I'm back, and can give you an update, slomo 
<slomo> tritium: ok, fine :) i also tried the daily a few hours ago and it didn't work for me... colony 3 don't work too... only colony 2 ;)
<tritium> slomo, okay, will do.
<slomo> tritium: thanks :)
<tritium> slomo, No problem :)  Both install and live?
<slomo> tritium: i only tried install... but as rescue mode and installer are working i see no reason why the live cd shouldn't work ;)
<tritium> okay, grabbing install CD now
<slomo> and i install again from colony 2 ;) i need the ibook tomorrow :/
<tritium> slomo, you might also ask nalioth what he's tried with all his powerpc machines.  He's a good resource
<mdz> Kamion: I think I'd prefer that usplash just deal with being installed after the kernel
<mdz> Kamion: my only reservation is that regenerating the initramfs can be risky
<Kamion> mdz: I didn't realise that there was a problem there; I was simply referring to the task of getting it installed on first boot
<slomo> tritium: thanks :) i'll do tomorrow
<mdz> Kamion: it's certainly the simplest solution: have usplash re-mkinitramfs in its postinst
<StrikeForce> hey all
<mdz> mjg59: what do you think?
<StrikeForce> I uploaded a package that was in main to revu can someone revu it please?
<mjg59> mdz: Hrm. Which kernel would it change?
<mdz> mjg59: the one the default symlink points to
<mjg59> Ah, ok
<mdz> we do default symlinks on powerpc too, right?
<mjg59> Yeah, I'm good with that
<slomo> mdz: yes
<Kamion> mdz: yes; just note that on some arches they're in / and on others they're in /boot
<Kamion> for historical reasons
<mjg59> mdz: There's a bzr repository at people.debian.org/~mjg59/usplash
<mjg59> I'm too tired to write code that might break someone's boot right now :)
<mdz> mjg59: ok, this is interesting
<mdz> mjg59: it's only ~4 seconds after gdm startup that I see the console switch
<mdz> not 15
<mdz> and it's going back to vt2, which is where it was when usplash was started
<mjg59> mdz: Hrm. Then I suspect something nasty in the usplash vt switch signal logic
<mdz> mjg59: I have an strace from the X server if that interests you
<mdz> I'm not even entirely surely that usplash is exiting; it's difficult to check at that stage
<mdz> I don't know why else I would go to vt2 though
<mdz> OH
<mdz> what does usplash od if it gets an invalid progress value?
<mdz> well, bother, it just ignores it as it should
<mjg59> Uhm. Unsure.
<mjg59> Yeah
<mjg59> mdz: The thing I'd recommend looking at is the bogl code that handles VT switches
<mdz> mjg59: but I don't know what would be triggering a vt switch
<mdz> does usplash catch any signals?
<mjg59> Yes
<mjg59> It registers USR2 for VT switches
<mdz> hmm, I don't know what would be sending it USR2
<mjg59> The kernel
<mdz> oh?
<mjg59> Yeah
<mjg59> Check the code in bogl.c
<mjg59> There's an ioctl to request a signal on VT switches
<mdz> oh, VT_SETMODE
<sladen> mjg59: you don't need to use the ioctl;  you can echo an escape string to the console
<sladen> mjg59: == saves being root
<mdz> that explains it
<mdz> mjg59: I thought you were just hanging around and timing out, and at that time checking if there had been a vt switch
<mjg59> Ah, nope
<mdz> so it's entirely reasonable that this could be racy
<mdz> since X's VT_ACTIVATE should trigger the signal
<mjg59> mdz: Yeah - sorry, I thought you realised that that was what it was doing
<mjg59> The idea is that someone can press ctrl+alt+f1 and get back to the normal console
<mdz> mjg59: shouldn't that Just Work?
<mdz> oh, I suppose not, if it'd continue drawing
<mjg59> Yeah
<mdz> what does VT_RELDISP do?
<mdz> ah, tells the kernel it's OK to switch
* Kamion -> bed
<mdz> mjg59: so the SIGUSR2 triggers bogl's handler, which cleans itself up and tells the kernel it's OK to switch, and also interrupts the select loop and causes usplash to exit?
<sladen> mdz: it's an ack/disallow from userspace to the kernel before a switch is actually made
<mjg59> mdz: I think it just exits itself, doesn't it?
<mjg59> I'll admit to not having checked over that code path very well
<mdz> mjg59: vt_switch() seems to just enable/disable bogl stuff
<mdz> mjg59: presumably select(2) returns -EINTR or so, and you break out of the loop on any error from select
<mjg59> Yeah
<mjg59> I'd guess
<mdz> aha
<mdz> yep
<mdz> -> ERESTARTNOHAND
<mdz> mjg59: this is so a usplash bug :-P
<mjg59> Haha
<mdz> it shouldn't try to switch consoles if the reason that we're exiting is because the user switched consoles
<mjg59> I've never claimed that my software is bugfree
<mjg59> Nngh. Right.
<mdz> mjg59: a quick test confirms that if I start usplash and hit ctrl+alt+f3, I still end up back at vt2
<mdz> I'll see what I can do with it
<sladen> mjg59: if you don't request the VT_POSSESION (in bogl) then switching will just happen on its own
<mjg59> sladen: bogl needs to know to stop drawing to the framebuffer
<Lathiat_> hrm, my firefox freezes up whenever i click on a download link of some kind
<Lathiat_> hrm itneresting, and you cant run official builds now because libXp.so.6 doesnt exist
<sladen> mjg59: yeah, urm.  I just had the parent loop and poll the current VT
<mjg59> sladen: Sounds racey
<sladen> mjg59: indeed
<elmo> wow, live cd is painfully slow on this laptop
<elmo> is breezy's slower or is it the cdrom and/or lack of memory (256) in this machine?
<TerminX> I could see GNOME on 256 megs being pretty slow..
<mdz> elmo: it's lack of DMA on the CD
<elmo> this is nowhere near gnome
<elmo> mdz: ok, well, it booted, but X failed to start
<TerminX> oh.
<elmo> mdz: "sh: getconfig: command not found"
<mdz> getconfig?
<TerminX> I made the assumption that you were talking about slow to use, not that it was sitting there trying to boot and failing to start X and stuff :)
<mdz> no clue what that is
<elmo> shall I file a bug?
<mdz> sure, why not
<mdz> where did you see that error?
<mdz> mjg59: usplash 0.7-1 uploaded, diff en route to your mailbox
<elmo> mdz: I got a "X failed to start, do you want to see the log" dialog, and I'm in that
<elmo> so I assume /var/log/Xorg.0.log
<mdz> elmo: oh
<mdz> that's X's way of telling you that xorg.conf doesn't exist, I think
<mdz> so check /var/log/casper/post.log
<mdz> which contains the debug output from trying to configure X
<elmo> cirrus_laguna?
<mdz> http://bugzilla.ubuntu.com/show_bug.cgi?id=14450
<elmo> ok, so it probably all falls apart from therE?
<mdz> well, for me, it still generated a valid (but incorrect) xorg.conf
<mdz> do you have /etc/X11/xorg.conf or no?
<elmo> no
<elmo> http://people.ubuntu.com/~james/tmp/post.log
<elmo> (hey, networking works ;)
<mdz> ++ expr ' @ 60Hz' / 20
<mdz> expr: non-numeric argument
<mdz> sounds like you have another bug on top of that one
<elmo> what's that the sh -x output of?
<mdz> xserver-xorg.config
<jdub> GOOD MORNING FREEDOM LOVERS!
<mdz> now that I've had to learn about Linux VT switching anyway, maybe I can find out why gdm's shutdown vt switching is broken on the live CD
<elmo> hmm, i can't reproduce it on the command line, how annoying
<mjg59> elmo: If you're on the laptop you borrowed, can you try gnome-power-manager?
<elmo> mjg59: yeah, once I've finished retrying the live CD
<elmo> mjg59: the hot key to suspend worked tonight tho when I left the office
<elmo> but lid close still didn't
<mjg59> elmo: Yeah, it won't do
<mjg59> g-p-m ought to let you configure that
<mdz> elmo: new jackass is LOVE
<elmo> yeah, it rocks.  I love DL385's
<elmo> hmm, this sucks
<mdz> except for that /dev/cciss madness
<elmo> I retried live CD, and now I can't get off of the "Failed to start the X server" dialog VT
<mdz> yeah, that happens
<elmo> yeah, that's annoying, I can't get snmpd to like it
<mjg59> elmo: Yes, I've had that happen
<mdz> there's a bug in bugzilla somewhere
<mdz> elmo: alt+sysrq+r
<elmo> ok, I'm going to throw this bug at daniel, he may be able to recognise it from post.log; i can always retry later if he can't
<mdz> the keyboard gets left in raw mode sometimes
<elmo> WTF is sysrq on a laptop?
<mdz> mine is labeled "sysrq" :-P
<mdz> but then, I buy IBM
<elmo> oh, yes, so it is
<elmo> it's a dark room :P
<mdz> Fn+PgUp
<mdz> a clever choice, given that it's easy to find in the dark
<elmo> hmm, it's Fn+Delete here, but it's not doing anything
<mdz> Fn+PgUp on thinkpads turns on the light
<mdz> the hunt-and-peck light
<mjg59> elmo: You tend to need to do vn+alt+sysreq+(release fn)+key
<mjg59> Otherwise fn modifies the other key as well
<elmo> christ
<elmo> nope, no love
<elmo> I got it to eject the CD while  bashing stuff tho
<jdub> elmo: you running vmware at the DC?
<Lathiat_> is anyoen else experiencing serious gamin problems?
<Lathiat_> most of the time its not working, and when ti gets really bad, attempts to connect to the socket hang which breaks half thea pplication on the desktop at startup
<Lathiat_> and this has only been the last week or so its been this bad
<jdub> mdz: http://www.m17n.org/mcpp/index_eng.html
<elmo> jdub: not yet; we are at the office
<jdub> elmo: oh, for desktops?
<jdub> dude
<jdub> journalists are posting their articles to sounder now
<mdz> 456456456
<mdz> oop
<jdub> that's the NSA's phone number!
<jdub> quick, tackle mdz!
<mdz> thas'[
<mdz> that's me trying to learn a kinesis keyboard
<elmo> mjg59: hum
<jdub> what's a kinesis keyboard?
* jdub thought it was a nuclear launch code
<elmo> mjg59: "Battery Charge Monitor" has quit unexpectedly, when I installed g-p-m
<jdub> elmo: did dbus/hal restart?
<Lathiat_> elmo: might be due to dbus restarting
<Lathiat_> lag
<elmo> eww, do we really need bubble pop up spam for the language pack stuff?
<elmo> jdub: yes
<jdub> language pack spam? what does that one say?
<elmo> "we split into gnome, kde, everything else, kthxbye"
<jdub> oh no
<mdz> jdub: www.kinesis.com
<jdub> is it pictured on the front page?
* jdub has an mspro bendy keyboard
<jdub> this keyboard gives me license to say things like "dude" and "tubular"
<lifeless> tubular dudes ?
<jdub> like totally
<mdz> jdub: this one is an old one
<mdz> but similar
<mdz> it makes me slow
<elmo> mjg59: eek, is g-p-m the "power preferences" thing?
<jdub> and the 'new' battery applet
<Lathiat_> heh cute, someone attempting to brute force an ssh password to my box tried the username "dbus"
<jdub> not that i think anyone wants to use it
<jdub> and the power prefs is crazy
* jdub thinks it's an ok testing ui ;)
<desrt> Lathiat; they hope you are beyond stupid
* Lathiat_ thought g-p-m looked pretty nifty
<jdub> Lathiat_: that's like, critical mass or something
<Lathiat_> desrt: obviously
<desrt> gpm is interesting
<elmo> that keyboard looks beyond weird
<desrt> the one thing i don't understand about gpm is why it is a session daemon
<mdz> elmo: pitti uses one now
<jdub> itanium solutions alliance!
<ajmitch> afternoon
<mdz> obsolescence alliance!
<jdub> yesterday's news consortium!
<elmo> got ipw chipsets are so freakin lame
<elmo> they're still broken in breezy :(
<Lathiat_> as in intel?
<jdub> dude, centrino is teh mighty!
<jdub> mine is working ok
<elmo> jdub: every ipw in the office breaks, like daily
<Lathiat_> my ipw2200 ahs always worked
<Lathiat_> it had some problems back in the early ipw2200 driver days
<Lathiat_> where it randomly stopped working
<Lathiat_> but seems fine these days
<jdub> hrm
* jdub needs to tell NM to switch interfaces from the command line
<jdub> d'oh ;)
* Lathiat_ reboots to a lovely "you must reboot" notification
<Lathiat_> that didnt show up before i rebooted presumably because gamin is the suck
<elmo> ah, hmm, I take it back, that was in fact my netgear WAP breaking.  yay.
<zul> my ipw2200 works
<Lathiat_> elmo: ah, heh
<mdz> elmo: it does still spew firmware errors
<jdub> mjg59: around?
<jbailey> jdub: yoyosup!
<jdub> morning jbailey 
<jbailey> So I'm curious about your SCSI woes. 
<jbailey> They ought not to happen anymore...
<jbailey> So I'm surprised that they do.
<jdub> how soon is anymore?
<jbailey> A few weeks ago.
<jbailey> So I'm clearly wrong. =)
<jdub> aha
<jdub> ;-)
<jdub> just upgrading that machine now, with -8 abi kernsl
<jdub> kernels
<jbailey> Cool.  I'm curious about your SCSI card.
<jdub> it's a sata_sil
<jdub> elcheapo
<jdub> 0000:00:0d.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3112 [SATALink/SATARaid]  Serial ATA Controller (rev 02)
<Lathiat_> mmm fakeraid
<jdub> yeah, i don't use that poo
<Lathiat_> you can get cardbus cards witht hat chipset
<Lathiat_> for $44!
<Lathiat_> with two ports
<jbailey> jdub: Raid.  But the question is why isn't the pci scan  picking up the scsi card?
<Lathiat_> and yuo can get external sata caddies for $50
<Lathiat_> im gonna get a coulpe + a controller, beats firewire or usb :)
<jbailey> jdub: Can you look in /sys/bus/pci/devices/0000:00:0d.0 for me?
<jbailey> jdub: In there, there should be a 'modalias' file.
<jbailey> I'd like to know what's in it.
<jbailey> (This is from the running system)
<mjg59> jdub: Yeah
<mjg59> elmo: Gah. It probably restarts dbus
<jdub> $ cat /sys/bus/pci/devices/0000:00:0d.0/modalias
<jdub> pci:v00001095d00003112sv00001095sd00006112bc01sc04i00
<jbailey> And this is i386, right?
<jdub> yeah
<jdub> it's like *so* run of the mill machine
<jdub> p2 bx chipset
<jbailey> The top entry in modules.alias ought to match that.
<jbailey> So iz not a kernel bug.
<jbailey> jdub: Do you have multiple machines?
<jdub> jbailey: not similar
<jdub> oh
<jdub> well
<jdub> actually i do have another mobo and cpu around
<jdub> but probably no box and psu
<jdub> :-)
<jdub> oh, and i don't have another machine with sata atm
<jbailey> No, I more mean, are you able to be interactive with me during the boot process?
<jdub> oh
<jdub> yes
<jdub> it just provides dns ;)
<jdub> it is not the fw
<mjg59> jdub: Pong?
<jdub> mjg59: sorry, doing four conversations at once
<jdub> mjg59: i have new image to send you in a little while if you want to play
<jbailey> jdub: sata_sil is included in the initramfs, so it should be safe to take out of the modules.  We'll be able to load it by hand.
<jbailey> jdub: As always, make a backup
<jbailey> mkinitramfs -o /boot/FOO isn't a bad idea for playing. =)
<jdub> ;-)
<mjg59> jdub: Ok, rock
<jdub> jbailey: ok, verified it's in my current initrd
<jbailey> Even without it in /etc/mkinitramfs/modules ?
<jdub> oh
<jdub> boh
<jbailey> ;)
<jdub> cp initrd.img-2.6.12-8-686 SAFEWORD
<jdub> ;-)
<Lathiat_> heh
* windub prepares
<squinn> and i'm now legal on the interweb!
<squinn> yay
<squinn> or at least in utc time i am
<lifeless> erm, I so don't want to know what that means.
<squinn> i'm 13.
<squinn> as of 9/1
<jdub> root@katia:/tmp/cock # find | grep sata_sil
<jdub> ./lib/modules/2.6.12-7-686/kernel/drivers/scsi/sata_sil.ko
<jdub> root@katia:/tmp/cock # find | grep sd_mod
<jdub> ./lib/modules/2.6.12-7-686/kernel/drivers/scsi/sd_mod.ko
<jdub> 
<jdub> jbailey: looks ok
<jbailey> Lovely.
<jdub> now you're going to make me reboot
<jbailey> So if you could reboot and add 'break' to the kernel command line...
<jbailey> Well, you needed to anyway for the -8 upgrade.
<jbailey> So no sympathy. ;)
* jdub makes a pissy little growling sound, gets on with doctor's orders ;)
* Lathiat_ smirks
<jbailey> See.  I seem to remember him saying that he had a *different* box to test on...
<windub> naw, i had a mobo and chip
<jbailey> Yup, that's pretty much what my backscroll said.
<jbailey> So why did he log off again? =)
<jbailey> Sheesh, some people's coworkers.
<windub> because i run irssi on my server
<jbailey> Unhuh, sure.
* lifeless waves generally
<jbailey> You're just making me feel guilty for you running windows.
<jbailey> BUT IT WONT WORK.
<windub> haha
* jbailey looks at the clock.
<windub> no, i've been running windows here and there on my desktop every now and then
<jbailey> The correct hemisphere awakes, I see.
<jbailey> Yeah, I've got MS Exchange disks on the way so that I can actually troubleshoot evo-exchange. 
<jbailey> *sigh*
<lifeless> ewww
<lifeless> don't do it. you'll feel dirty
<ajmitch> jbailey: some of us have been awake for hours :)
<jbailey> ajmitch: You never sleep, so you're removed from the set to avoid skewing the sample.
<mjg59> daniels: Do we have a fake X server that supports DAMAGE in the archive?
* lifeless has been working for a half day already
* windub wants a machine powerful enough to run windows server 2003 / exchange 2003 on top of linux
<jbailey> windub: I have one.  It just runs a ppc processor. =)
<jbailey> So sad. =)
<windub> :-)
* ajmitch wishes that he wasn't fetching packages at ~2K/sec :(
<lifeless> windub: you need to prove the existence of a real machine powerful enough to do that first.
<windub> ok, different errors this time
<jbailey> windub: Ooo oo ooo..  
<jbailey> Wiat, you got errors/
<jbailey> did you remember to add 'break' to the kernel command line?
<windub> buttloads of could not load /lib/modules/.../modules.dep
<windub> yes
<jbailey> Umm.
<jbailey> So did the depmod -a not fire for you?
<jbailey> are you at a shll prompt?
<windub> yeah
<windub> i can't scroll back very far :|
<jbailey> Can you try depmod -a and tell me what happens?
<windub> oh
<windub> dude
<jbailey> Not worried about that, but I might hack in some more debugging bits in initramfs for you.
<windub> my fault
<jbailey> It is?
<jbailey> =)
<windub> i mkinitramfs without specifying version while i was running the old kernel
<windub> hold on
<jbailey> Ahah.  Yeah that would suck. =)
<jbailey> Sorry, I should've thought about that. =)
<windub> <- i'm with stupid
<jbailey> windub: I wouldn't like to be near your belle when you said that.
<jbailey> I suspect that he violence travels in ever expanding waves...
<jbailey> +r
<elmo> THE ITCHY AND SCRATCHY SHOW
<daniels> mjg59: no
<daniels> mjg59: hassle ross to get xfake into the archive STAT
<daniels> mjg59: also xephyr
<windub> pia's in the loungeroom atm, actually
<mjg59> We seem to have everything we need in order to build xfake
<mjg59> elmo: Yeah, it's the power-preferences thing
<mjg59> When that's running, you can tell it to suspend on lid close
* windub growls at feenode
<windub> jbailey: ok, booting again with break
<windub> no errors at all, dumped to shell :-)
<jbailey> windub: Lovely, cat /proc/modules please, let's see if your sata bit is in there?
<windub> yeah
<windub> sd_mod and sata_sil
* windub wonders if he should just try a naked boot with -8
<jbailey> Sounds like. =)
<windub> perhaps you fixed it by looking at it
<jbailey> It's the great part about sharing a name.  Perhaps we are more powerful because we can channel one another's fixit-fu.
<windub> ha ha ha ha
<windub> ok
<windub> i get two mdadm started messages
<windub> md0 2 drives -> wrong!
<windub> md1 1 drive out of 2
<windub> mounting /root/dev on /dev/.static/dev failed: no such file or directory
<windub> mounting /dev on /root/dev failed: no such file
<windub> kernel panic
<windub> 
<windub> so
<windub> my md0 doesn't have two drives
<windub> md0 = 1 disk sata
<windub> md1 = 2 disk pata (mobo)
<windub> so it's detecting them the wrong way around :|
<jbailey> Oh, they're changing order on you?
<jbailey> Hmm
<jbailey> Bugger.
<jbailey> I had tried really hard to avoid that problem.
<jbailey> If I hadn't, I could've greatly simplified the script.
* windub is glad to have a silly setup to test this :-)
<windub> i'm not even using the pata md1 atm :-)
<jbailey> Well, there's probably bugger all I can do about it. =(
<jbailey> I don't knwo of anyway of detecting which raid device should be associated with which thing if mdrun isn't doing it.
<windub> why did it work with the initrd?
<windub> probably for the same reason it works when i load the modules explicitly
<jbailey> Right.  It'll be a module load order.
* windub tries to rmember the script
<jbailey> Oh, I bet...
<windub> didn't it run mdrun on particular devices in order?
<jbailey> I detect the IDE drives before I detect the SCSI ones.
<jbailey> You mean the old initrd?
<jbailey> It let the kernel assemble it for us.
<windub> the md script in your initramfs
<jbailey> With initramfs, that's now all in userspace.
<windub> oh yeah
<jbailey> /sbin/mdrun /dev
<jbailey> That's all I do.
<windub> i thought you were looping around /dev/hd* /dev/sda* stuff as well in there
<jbailey> All the walking over the devices is to determine the raid levels so that we modprobe raid1, etc.
<lifeless> userspace good. mmmm
<windub> ok, the detect raid level loop does that
<jbailey> And then after that I just run mdrun.
<jbailey> But I called the script in particular so that the raid devices would get detected the same as before. =(
<windub> reckon mdadm --examine starts raid devices?
<jbailey> It ought not to - it should just tell me what's in the raid superblock.
<windub> hrm, mdrun -> was it ever used before initramfs?
<jbailey> Only to start up raid for devices who's modules weren't built into the system.
<jbailey> So hmm.
<jbailey> Maybe it wasn't doing this magic for us.
<windub> need magic!
<jbailey> Part of what appears to suck is that the preferred minor is wrong on my local setup anyway.
<windub> so this is almost certainly mdrun
<jbailey> Can you do an mdadm -E /dev/sd${fOO} and look at the preferred minor for me?
<jbailey> Is it right?
<windub> sec, i'll have to reboot with break
<jbailey> No, you can do it from a running syste.
<windub> hard from a kernel panic shell ;-)
<jbailey> Eh?
<jbailey> Oh, it wouldn't have dropped to a shell because the root exists.
<jbailey> Hmm
<jbailey> I should have a panic in there for that, too.
<jbailey> I guess that gets as far as mounting the drive, and then realises that there's no /sbin/init
<windub> preferred minor = 0
<jbailey> So it would be right for you?
<daniels> mjg59: yes, all the pre-reqs are in the archive.  ross was coming up with xserver packages a while back, so yeah, harass him about getting 'em into universe.  (NOT MAIN)
<windub> um
<windub> jbailey: yes, that's right
<windub> jbailey: but the preferred minor on my other disks is 0 too
<jbailey> Oh really?
<jbailey> Joy.
<jbailey> But...
<jbailey> Why would module load order make a difference?
<windub> ... kernel detection?
<jbailey> Your SATA stuff shows up as /dev/sd* and your PATA stuff as /dev/hd* right?
<windub> yeah
<jbailey> The assembly is done in userspace by a shellscript.
<windub> and the kernel *doesn't* do autodetection anymore?
<jbailey> Right.  That whole step is skipped as soon as you use an initramfs.
<windub> ok
<windub> hmm
* daniels dives back into evil shell scripts, and searches for lunch.
<windub> md0 == /dev/sda1, failed
<windub> md1 == /dev/hda, /dev/hdc
<ajmitch> jbailey: it's part of your secret plan to make things more hurd-like?
<jbailey> ajmitch: Secret?  Who's keeping it a secret?
<jbailey> ajmitch: Linux sucks in so many ways, and is great in one amazing way:  It works.
<jbailey> Unfortunately, it's the way that counts.
<windub> religion is off-topic on #u-d ;-)
<ajmitch> it's the things that can't be said about the hurd, sadly
<jbailey> windub: It's not religion, I'm authoritative. =)
<windub> ok, anything else i can do now?
<windub> or should i reboot and commit to my uptime? ;)
<jbailey> No, probably nothign at the moment.
<Burgundavia> windub, are the p.g.o rss feeds broken?
<jbailey> Any tests I do, I'll do here on my md setup first.
<windub> Burgundavia: yes
<windub> jbailey: ok, ta
<Burgundavia> windub, ah, ok. np
<windub> but there is a problem :)
<fabbione> morning
<windub> jbailey: uh oh
<windub> jbailey: i just modprobed sd_mod and sata_sil
<windub> jbailey: and then ran mdrun, and it came up with the same :)
* windub tries again for good measure
<jbailey> *cry*
* windub boots with SAFEWORD
<windub> ok, it did the right thing
<windub> if modules has sata_sil and sd_mod, it does the right thing
* windub must've done something weird in his initramfs shell session
<jbailey> Well, by the earlier point when you can drop to a shell, it's already done modules detection.
<jbailey> So somehow the orderng is dependant on the order the modules are loaded.
<jbailey> Suck, but at least we know that it's not a sata problem.
<jdub> right
<jdub> mjg59: mailed
<jbailey> mjg59: I had an evil thought the other day for initramfs / usplash replacement / regeneration.
<jbailey> I don't know how ugly this is, I suspect very.
<jbailey> But if the usplash initramfs were concatinated as a second cpio tarball, it could be added on after, and possibly swapped out.
<jdub> :-)
<jdub> that'd be rad
<mjg59> jbailey: Ok. Does that /work/ ?
<jdub> much easier to work with for the livecd too
<jdub> how do you specify multiple cpios?
<jbailey> mjg59: concatinating cpio.gz files?  Yeah, I tested it.
<jbailey> jdub: Literally just cat them together.
<jdub> oh, can't you not concatenate?
<mjg59> jbailey: Well, if you can write up what needs doing, I can take a look at it
<jdub> i thought you could use a list of cpios too
<jbailey> initramfs-tools is theoretically already setup for working with overlays like that.  *that* is totally untested, though. =)
<Lathiat_> same as gzip
<jbailey> Cool my "jdub mounts the wrong filesystem" hack drops me to a shell now.
<Lathiat_> you can just concat thema nd they unzip as one
<jbailey> jdub: You'd need the bootloader to assemble them for you.
<jbailey> jdub: I'd love to do that, but it still needs a fallback case then for incapable bootloaders.
<jbailey> jdub: Until we have grub2 running everywhere... =)
<jbailey> Lathiat_: Ah?  I didn't know that.
<Lathiat_> jbailey: yeh
<Lathiat_> so if what you say works
<Lathiat_> apparently cpio archives can be concatted too
<Lathiat_> since thats basically what you end up with
<Lathiat_> i think it works with tar too 
<jbailey> Oh, but it gunzips them as one file.
<Lathiat_> yeh
<jbailey> Hmm
<Lathiat_> crap sticks
<Lathiat_> i ran out of disk space
* desrt tosses you a few gig
<jbailey> I need to rip them apart and replace one of them, possibly in the middle for this idea.
* Lathiat_ decides /home doesn't need 2.2G reserved for root
<jbailey> Hmm.  Apparetnly fsck is longer than usplash's patience on my box.
<desrt> Lathiat_; be careful
<Lathiat_> desrt: of what?
<Lathiat_> root doesnt have any files on /home :)
<desrt> Lathiat_; -m 8 reduces filesystem fragmentation
<Lathiat_> probably
<Lathiat_> but i want more disk space damnit ;p
<desrt> if you have no reserved blocks then you get more fragmentation :P
<Lathiat_> guess i should clean up a bit ;p
<desrt> see also: drives are cheap :)
<Lathiat_> see also: im broke
<desrt> :(
<Lathiat_> and its a laptop, new disk for a laptop isnt so cheap
<desrt> ow
<Lathiat_> i want to get a sata cardbus card ($44!) and a sata external caddy ($50!) and then a sta drive
<desrt> sata cardbus... wow
<jdub> oh man, ETA for my new LCD is 14th :-|
<Lathiat_> yeh and its cheap as
<Lathiat_> i want so bad
<Lathiat_> two ports
<desrt> jdub; apple or dell?
<Lathiat_> sata sil
<jdub> dell
<desrt> 20 or 24?
<jdub> with another 20% off too
<jdub> 24
<desrt> sweet :)
<Lathiat_> jdub: nice
<jdub> buy before sept 2 for a $1440 24" *very* HQ LCD :)
<desrt> is that AU$?
<jdub> yeah
<desrt> hmm
<jbailey> desrt: .au$ same as ours.
<desrt> jbailey; a bit less
<jbailey> For UDU it was a literal 1.0 exchange.
<desrt> it's like 93 or something
<jdub> only our colours are better
<desrt> pfah
<desrt> your money is plastic
<jdub> jbailey: you guys are plastic now too, right?
<desrt> jdub; heck no
<jbailey> Nope.
<jbailey> Still cotton and hemp, iirc.
<jdub> savages
<jbailey> jdub: We're *hippies*
<jbailey> get it right.
<jbailey> and pass me the bong.
<fabbione> jbailey: initramfs'ed sparc rebooting now...
<desrt> "paper plastic or rubber" falls apart when you don't have paper anymore
<Lathiat_> whoever wrote ethereal is a god
<Burgundavia> jdub, this art.gnome.org stuff reminds me of the docteam stuff we went through earlier
<Burgundavia> jdub, make that art.ubuntu
<Lathiat_> curious... if i dont have a route out an interface for an ip range and i get a multicast packet it isnt given to me
<Lathiat_> err, for that ip range the packet came from.
* fabbione fetches a console cable and looks at jeff
<fabbione> jbailey: would you accept an initramfs bug on sparc?
<jbailey> fabbione: Yes.  Depending on what it is, it might get fixed in the upload planned shortly.
<jbailey> shortly, like I'm testing some more evms bits, and then I'm uploading. =)
<fabbione> jbailey: see /msg
<fabbione> the output on console is not 100% clear
<jbailey> It's clear to me. =)
<fabbione> jbailey: note that the harddisks are recognized..
<fabbione> and one fs is mounted..
<fabbione> they are scsi disks..
<fabbione> so probably it doesn't load sd_mod ?
<jbailey> Hmm.
<jbailey> It might be that your SCSI disks are spinning up too slowly.
<fabbione> that's very possible
* mjg59 fixes irda to work over suspend/resume
<fabbione> jbailey: let me boot with the old kernel and add a sleep..
<jbailey> fabbione: Yup.
<jbailey> Add it to /usr/share/initramfs-tools/scripts/functions
<jbailey> Just add it to the top of "scsi_boot_events"
<jbailey> If there's any way taht I can detect that the bus scan isn't finished, I'm all ears.
<fabbione> jbailey: yups..
<jbailey> I have an arbitrary sleep 2 in there right now, which is probably totally not good enough.
<fabbione> MEEEEEHHHH
<fabbione> go silo!
<fabbione> it doesn't let me switch to the old kernel
<jbailey> Add break to the kernel command line.
<jbailey> All the modules are there, you should be able to do this all by hand.
<jbailey> FWIW, grub2 on sparc will load the kernel, it just won't run it. =)
<jbailey> No elf64 support yet, coming soon. =)
<fabbione> eheh
<jbailey> In fact, doing it through the initramfs would be a nice proof.
<jbailey> Although, hmm.  If it mounted the filesystem, I wonder what the problem really is.
<jbailey> Are you raid or anything crazy like that?>
<fabbione> nope
<fabbione> plain disks
<jbailey> fabbione: Cool, can you hop in, in "break" mode, and figure out why /root doesn't contain that new filesystem, even though it says you mounted one?
* fabbione powercycles
<fabbione> jbailey: as it is now, silo/OBP is not allowing me to select anything at boot
<fabbione> and i am trying to figure out why
<jdub> mjg59: did you see that 100mbs irda stuff?
<mjg59> jdub: Yeah
<mjg59> No idea what needs doing to support it
<jdub> probably driver foo
<fabbione> jbailey: i have a bed feeling about all of this... and not only initramfs fault..
<phlaegel> ok, so how do I enable usplash? dpkg-reconfigure on the kernel image doesn't work.
<whiprush> n/win 11
<whiprush> oops
<jbailey> fabbione: Sure, but if you can get to a shell in the initramfs, life becomes happier... =)
<fabbione> jbailey: dude... i have problems even to use the OBP
<fabbione> the issue is a few layers before that
<jbailey> Oh.
<jbailey> suck
<fabbione> it looks like something did fry badly
<jdub> oh man
<jdub> daniels: duuuude
<jdub> daniels: "Not all X developers are entirely supportive of Jon's position. The administrator of freedesktop.org, where Jon's document is hosted, posted a dismissive response and promptly shut down Jon's account, making the document unavailable. It has since been restored, but that action (ostensibly taken for other reasons) added an unpleasant note to the debate."
<jdub> ...!
<mjg59> It's all a conspiracy
* fabbione manages to boot from net
<phlaegel> does usplash work with lilo?
<mjg59> Yes
<phlaegel> what do I have to do to enable it?
<mjg59> Pass the splash argument on the kernel command line
<phlaegel> I should be able to do that at the lilo prompt, right? I tried that and got nothing
<mjg59> There's nothing in the code that cares in the slightest what bootloader you use
<mjg59> As long as there's the splash argument, and as long as it's in the initrd, it ought to work
<mjg59> Oh, and as long as you're not using vga=foo
<phlaegel> I didn't thing bootloader would matter. but I've rebuilt the initrd, I'm not using vga=x, and passed splash, and nothing has worked...
<phlaegel> *think
<mjg59> phlaegel: No idea whatsoever, then
<phlaegel> ok, adding it to append= works, but it's a bit messy :-)
<mjg59> phlaegel: lilo is, in general
<phlaegel> true
<daniels> jdub: yes, jon has a flair for flat-out lying
<daniels> jdub: (smirl, not corbet -- i have no issues with jon corbet, who was just presenting it as it was told him.)
<mae> Breezy is starting to look _very_ nice
<pef> morning
<zyga> hello
<jdub> mjg59: that splash i sent looks mighty fine
<jdub> mjg59: what do you think about shifting the progress bar down the the bottom of the screen, say, 5px high
<jdub> ?
<jsgotangco> the black one?
<jdub> sent a new revision to mjg for integration
<jsgotangco> ahh
<sabdfl> mdz: morning
<jdub> morning sabdfl 
<fabbione> hey sabdfl 
<jsgotangco> hey sabdfl 
<sabdfl> moin moin guys
<tritium> slomo, ping
<tritium> jdub, per the community council meeting on the 30th, can you give thoreauputic, nalioth, and apokryphos access level 10 on #ubuntu when you get a chance?
<bob2> apokryphos?
<bob2> he/she doesn't seem *that* active
<tritium> sabdfl gave him +1
<bob2> why?
<tritium> Not sure.  I wasn't there.  I was just talking to nalioth, and he mentioned it.
<bob2> hrm
<bob2> I should go to meetings
<tritium> I'm viewing the irc logs now
<tritium> bob2, right about 11:50 on the 30th is what I'm referring to
<jdub> tritium: url/
<jdub> ?
<tritium> jdub, http://people.ubuntu.com/~fabbione/irclogs/ubuntu-meeting-2005-08-30.html
<jdub> thanks
<bob2> erk
<tritium> thank you too
<tritium> bob2, do you have reservations?
<bob2> just don't see them around giving accurate advice that much
<bob2> but meh
<bob2> both seem quite nice, tho
<tritium> yes
<sabdfl> bob2: you're welcome to have ops too if you want
<bob2> sabdfl: I do
<bob2> (already)
<bob2> and many days are the most active person there
<sabdfl> both of you?
<sabdfl> bob1 and bob2?
<jdub> hrm, seveas is not around
<Treenaks> jdub: he will be in a few minutes :)
<bob2> bob1 still does svn stuff with perl
<tritium> thanks, jdub
<jdub> ok
<jdub> i gave seveas level 29 access
<jdub> but can't give him 30
<jdub> which he needs to add opers
<jdub> gar :|
<Treenaks> jdub: I had that problem on -nl as well
<jdub> freenode really is annoying these days
<siretart> morning
<siretart> bob2: around? any news about lyx?
<tritium> bob2, sorry that I've been less active ever since my thesis defense.  I'm strictly forbidden from using IRC at work.
<Keybuk> Diziet: interesting
<Treenaks> seveas will be back around 13:00 UTC
<sivang> Morning everybody!
<Treenaks> hey sivang
<sivang> hey Treenaks 
* sivang is puzzled by language selector. Shouldn't it also make the neccessary changes in GNOME kbd selector so I will have the both languages switchable already ?
<Treenaks> sivang: new language doesn't mean "new keyboard"
<sivang> Treenaks: right :)
<Treenaks> sivang: usually not
<jdub> sivang: that'd be useful
<sivang> jdub: maybe we could improve that for breezy+1 ;-) I'd all those people annoyed by not having the hebrew input support by default..
<Treenaks> sivang: there's a keyboard chooser in the installer which should detect that
<jdub> sivang: definitely worth a bug report :)
<sivang> jdub: sure, I was trying to get confirmation for that, and I just did =)
<tritium> slomo, no more kernel panics on iMac G5 with 20050831.1 install-powerpc64.  Any luck with the ibook?
<sivang> jdub: did you test the CHRP imagens yest?
<jdub> sivang: no, won't have access to hardware for a little while
<jdub> visiting ibm on monday though, so may take a cd along
<tritium> good night
<seb128> Keybuk: so this wm crasher?
<Keybuk> seb128: I see your point
<Keybuk> it's been running under gdb for 24 hours now, and hasn't crashed yet
<seb128> Keybuk: weird bug, isn't it :)
<Lathiat_> yeh
<Lathiat_> Keybuk: oh, tip:
<Lathiat_> Keybuk: dont run that gdb session in your xsession ;p
<Keybuk> Lathiat_: I know that :p  it's on vt1
<Lathiat_> hell that even backfired on me once
<Keybuk> seb128: other strange bug for you
<Lathiat_> for some reason i couldnt switch vts
<Keybuk> I don't seem to have an ssh-agent
<Keybuk> it's _running_ but nothing has the environment for it
<Keybuk> no, wait
<Keybuk> I know
<Keybuk> because I ran metacity in a vt, when it starts a terminal (by shortcut key), there's no ssh info in its environment
<thesaltydog> New baobab version 1.1.0 is up on debian pool main since today. Will the new version be automatically synced in Breezy, or does it need some "human" interaction?
<seb128> Keybuk: right
<Lathiat_> thesaltydog: We are in upstream version freeze, unless theres a good reason it wont go in.
<jdub> thesaltydog: automagic syncs stopped at UpstreamVersionFreeze
<jdub> thesaltydog: you'll have to request a sync (after testing)
<jdub> thesaltydog: since it's in universe, it'll probably go in
<thesaltydog> jdub, with whom I have to speak?
<jdub> thesaltydog: elmo
<Treenaks> and mdz?
<jdub> not for universe
<Treenaks> oh right
<thesaltydog> jdub, ok, I'll look for elmo. Thanks.
<siretart> thesaltydog: is this universe?
<thesaltydog> siretart, yes.
<siretart> thesaltydog: why do you need the new version? which important bugs does the new release fix?
<thesaltydog> siretart, no bugs. Just a big program enhancement. New features.
<thesaltydog> siretart, I have added a full file-search capability, auto-monitoring of volumes and directory changes, etc..
<siretart> thesaltydog: sorry. UVF is about stabilizing, and not letting new crack with potential bugs in. we need the time to fix existing bugs
<Mithrandir> mvo: hmm, daily install didn't work; hung on untrusted packages question (about language-pack-no).  Just killing aptitude and letting it be restarted fixed the problem.
<siretart> thesaltydog: I would therefore not approve the new version
<thesaltydog> siretart, ok. Users will download the package from debian.
<siretart> thesaltydog: hey, we are relasing in a few weeks, we can backport the package from breezy+1 to breezy after that
* infinity looks at the calendar.
<infinity> "few weeks"?
<thesaltydog> siretart, ok.
<Lathiat_> 6 or so now isnt it?
<siretart> infinity: < 8 weeks is a "few" for me ;)
<Mithrandir> mvo: and the update-notifier should probably have a busy mouse cursor while it's launching, as it is confusing the way it is now.
<infinity> siretart : So, did you get assigned as the gateway for UVF exceptions in universe, then?
<Burgundavia> Mithrandir, is that not a gksu issue?
<thesaltydog> siretart, but after release, the version update will be automatic or should I ask for?
<siretart> infinity: actually, ogra is, but he has delegates, and yes, he appointed me as one of the delegates
<Mithrandir> Burgundavia: possibly.
<infinity> siretart : Neat.  How do you feel about me updating php4 to the (now well-tested, given its age) 4.4.0 version in Debian?
<Burgundavia> Mithrandir, because in breezy gksudo is very slow
<Lathiat_> its ok, only mum said no, you can  still go ask dad before mum tells dad she said no
<infinity> siretart : It will require me rebuilding any out-of-tree extensions, but you know I have no issues with rebuilding stuff. :)
<siretart> thesaltydog: not fully automatic, because we have diffs to the debian version. we have to merge new debian upstreams manually, but we will
<Mithrandir> Burgundavia: well, it should still show a progress thingy, since it takes a few seconds on a freshly installed XP2400+ system here.
<thesaltydog> siretart, ok, thanks. Have a good day.
<mvo> Mithrandir: the untrusted prompt in aptitude usually means that something went wrong before, e.g. a failed aptitude update
<Burgundavia> Mithrandir, yes it does
<Burgundavia> Mithrandir, there is a bug open for a the stupidly long wait time, just a sec
<siretart> infinity: well, you are maintainer of php4, and know really more about the consequences of this upgrade. I should ask therefore you ;)
<Mithrandir> Burgundavia: not when launched from the update-notifier tray applet, it doesn't.
<Mithrandir> mvo: hmm, I can do a new test install and see.
<zyga> where is the language-selector template in rosetta?
<infinity> siretart : Yes, but I don't want to just shove it in without approval from someone else.  If it was for main, I'd be asking mdz. :)
<Burgundavia> Mithrandir, https://bugzilla.ubuntu.com/show_bug.cgi?id=12183
<mvo> Burgundavia: the stupid long wait comes from gksudo 
<Burgundavia> mvo, yes
<mvo> Mithrandir: that would be nice, also my daily-image should be heere soon too
<fabbione> hey mvo
<mvo> hey fabbione 
<siretart> infinity: I don't know and don't use php4 that much, and would need to do some research about changes from 4.3 to 4.4. if you think we should have it in breezy because it fixes bugs and does not harm existing application, I'd trust you that you do the right thing.
<fabbione> mvo: as i wrote to you.. gdb hangs..
<fabbione> there is no backtrace
<mvo> fabbione: yes, I got that message. what arch is that hang happening on?
<fabbione> mvo: still sparc...
<infinity> siretart : Alright.  I'll exercise my own judgement then.  First, I need to figure out why we still have a few bits from php4 hanging around in main instead of universe, though. :/
<siretart> infinity: but rather talk to ogra about this, since as far as I know, he uses php4 for edubuntu
* infinity goes to speak with germinate.
<infinity> siretart : No, php5 is used for edubuntu.
<infinity> siretart : And php5 is in main.
<siretart> ah. I see.
<infinity> Oh, feh.
* infinity goes to clean up some straggling reverse {build-,}deps.
<zyga> mvo: where is the language selector package?
<mvo> zyga: it's in my baz archive: michael.vogt@ubuntu.com--2005/language-selector--main--0
<zyga> mvo: thanks, I was looking for it in rosetta but this will do fine :)
<zyga> mvo: is your baz repo tla compatible?
<mvo> zyga: I'm not sure, I just used the defaults
<infinity> doko : Dude.  Is the gij-4.0 postinst supposed to segv, or am I just lucky?
<Mithrandir> infinity: it's a feature. :-P
* infinity updates the chroot to see if it was a transient library breakage of some sort.
<Mithrandir> doko: hmm, about ooo-mozilla-amd64 / 14434 ; could you please respond on that one?
<infinity> Maybe if I'm lucky, it's the same GTK breakage I was seeing on my base system, and an upgrade will make it magically go away...
<zyga> mvo: here? http://people.ubuntu.com/~mvo/arch/ubuntu/ 
<doko> infinity: which architecture?
<doko> Mithrandir: yes, thinko. should be closed.
<infinity> i386
<doko> infinity: does it? never seen ...
<doko> infinity: it crashes on m68k, but you should be used to it ...
<mvo> zyga: yes
<pitti> Good morning
<seb128> hey hey pitti
<pitti> seb128: today I start later than you :) well, I got lost on my morning biking tour
<seb128> pitti: bah, I've started around 8am but I'm away for ~1h now, go to swimm, that's good with this weather :)
<mvo> doko: avm-isdn work fine with fritz-pci and pcmcia, well done
<pitti> seb128: enjoy
<zyga> mvo: expect pl.po as usual later during the day, thanks :)
<infinity> doko : Hrm, a dist-upgrade didn't fix it.  Yay.
<seb128> pitti: thanks :)
<mvo> zyga: thank you
<infinity> doko : Nevermind.  libgcj6 got corrupted somehow.  Feh.
* infinity blames goblins.
<doko> mvo: thanks for checking the pcmcia stuff!
<Mithrandir> mvo: now it's hanging on language-support-en. :-/
<Mithrandir> mvo: why on earth is really apt-cdrom used when it's all precopied?
<jsgotangco> mine hangs as well
<mvo> Mithrandir: the problem is that it's not precopied
<jsgotangco> (today's build even)
<Mithrandir> mvo: my file system seems to disagree with you.
<zyga> mvo: viet nam it two words?
<mvo> Mithrandir: I had that yesterday and /var/cache/apt/archives missed e.g. mozilla-locale-en
<Mithrandir> at least, I have a /var/cache/apt/archives/language-support-en_20050818_all.deb
<mvo> zyga: probably not
<mvo> Mithrandir: yes, but you probably miss some dependencies of it
<Mithrandir> mvo: hmm, 'k.
<mvo> Mithrandir: could you please check that?
<zyga> mvo: I'll fix it
<mvo> Mithrandir: it's pretty anoying, I added support for kamion to detect media-change on the apt status-fd, but that's only a workaround, not a real fix
<mvo> zyga: thanks
<mvo> Mithrandir: do you think we could make archive-copier a bit smarter?
<Mithrandir> mvo: that would be good, yes.  I think Kamion did some work on it last night, but it's either not on the CD or not smart enough.
<zyga> mvo: hmm it actually might be two words... 
<sivang> jdub: are you going to get the test suits, or going to sign the certification?
<mvo> zyga: have you looked it up in dict?
<doko> elmo, Kamion, mdz: please demote neon0.23 to universe, OOo1, which was the only user, is in universe now.
<zyga> mvo: google
<Mithrandir> mvo: all its dependencies are missing
<zyga> and gnome-dict applet
<mvo> Mithrandir: 'k
<mvo> zyga: thanks
<zyga> it's corect 
<Mithrandir> Kamion: is archive-copier still dumb or not yet on the daily cd?
<mvo> Mithrandir: the changelog indicates that it's clever now
<Mithrandir> apparently not very. :-P
<doko> pitti, seb128: are rosetta translations for gnome already imported into the language packs?
<pitti> doko: nope, that still doesn't work
<sivang> Treenaks: what's the package name for the lanuguage configurator?
<pitti> sivang: language-selector
<sivang> pitti: thanks, is it ubuntu specific?
<pitti> sivang: yes, by now
<pitti> sivang: since we are the only distro which has langpacks
<sivang> pitti: :)
<doko> infinity: please build maxdb-buildtools on amd64 and ia64
<sivang> pitti: I saw it triggers installation of gnome lanugage packs as well, are those also ubuntu made?
<pitti> ywp
<pitti> yes, even
<infinity> doko : It's only registered in wanna-build on i386.  I assume it's in Packages-arch-specific?
<infinity> lucifer:~/build/dak/srcdep/> grep maxdb Packages-arch-specific
<infinity> %libdbd-maxdb-perl: i386                                              # [ANAIS] 
<infinity> %maxdb-7.5.00: i386 amd64 ia64                                        # [ANAIS] 
<infinity> %maxdb-buildtools: i386                                               # [ANAIS] 
<infinity> doko : Should libdbd-maxdb-perl and maxdb-buildtools both be updated to i386 amd64 ia64, then?
<doko> Package: maxdb-buildtools
<doko> Architecture: i386 amd64 ia64
<doko> probably, ia64 and amd64 support was added some months before
<doko> yes, and maxdb-7.5.00
<infinity> doko : maxdb-7.5.00 is already okay, according to the above grep.
<doko> fine
* infinity updates the other two.
<melodie> hello :)
<infinity> doko : They'll build automagically after elmo sync P-a-s with Debian.
<doko> infinity: they are built in Debian ...
<melodie> I wanted to bring a news about Xorg, plus one question about next release version
<infinity> doko : Must have been built by hand, then.
<melodie> the new about xorg concerns the next release that will be about the same time as official Breezy
<melodie> #
<melodie> XX Oct 2005: X11R6.9/X11R7 Release
<melodie> http://wiki.x.org/wiki/X11R6970ReleasePlan
<infinity> elmo : Please sync the maxdb-related changes I just made to Debian's Packages-arch-specific
<melodie> I thought it is intersting as I saw on the archieve ml the version discussed about is a 6.8
<infinity> elmo : Also, yellow appears to be down. :/
<sivang> pitti: so you had to make a distinction between console apps .po's and gnome apps ?
<pitti> sivang: we split out gnome and KDE to properly support Kubuntu
<melodie> someone could inform me about the very next after Colony 3 ? read about one that could come out on Sept 8 th (?)
<melodie> I'd need the info for a doc I'm helping to, and do not find the info on the net again...
<melodie> :)
<pitti> melodie: https://wiki.ubuntu.com/BreezyReleaseSchedule
<melodie> oh thks!
<pitti> melodie: Sept 8 is the preview release, but there will certainly be a colony 4 before
<pitti> Hi sabdfl 
<melodie> thank you pitti :)
<zyga> hmm
<zyga> I've just noticed that the keyboard driver in hoary is broken
<Mithrandir> mjg59: did you see the post about "swap space manager" on debian-devel three weeks ago?  Would it be possible to get resume from swapfiles working?
<zyga> I'm not sure which part but I cannot enter polish capital letters correctly
<zyga> shift + alt + l = 
<zyga> but in only works when I do
<zyga> caps lock
<zyga> alt + l 
<zyga> shift + alt + l = L (no / across)
<Mithrandir>  works for me.
<zyga> I'd like to file a bug but I'm not sure to which pachage
<zyga> hmm
<Mithrandir> as in shift-alt or alt-shift
<Mithrandir> this is in a norwegian layout, though.
<zyga> maybe it's locale dependent?
<zyga> hmm no wait !
<zyga> it's even stranger
<zyga> it works in x-chat but fails to work in gnome-terminal
<zyga> my locale is pl_PL.UTF-8
<jdub> jsgotangco: i think your style guide announcement would be more appropriate on ubuntu-news
<jsgotangco> hmm
<jsgotangco> jdub, sorry about that, will push it there next time
<sivang> hey jsgotangco 
<siretart> infinity: in -motu we just talked about php 4.4: < ogra_> siretart, see php updates as generally granted ;)
<siretart> infinity: I think this is what you wanted to hear ;)
<HiddenWolf> seb128, could you read 14323, I think gtk is not playing nice.
<jsgotangco> sivang, hi!!!
<melodie> a nice day to all, till next time :)
<melodie> bye-bye
<mvo> seb128: has your SoC student compelted the work on the "can-this-user-do-sudo" program/script?
<sivang> jsgotangco: whassup? :)
<HiddenWolf> fabbione, I'm getting [failed]  messages for 'configuring network' en 'syncronising to ntp' during init, but my network works just fine, regular dhcp.
<fabbione> HiddenWolf: and why do you ask me?
<ogra> Kamion, did you get my mail about the edubuntu seeds ? 
<infinity> siretart, ogra : Thanks.  I'll wait until I get all of php4 completely shoved out of main (a few packages still accidentally depended on it) before I go syncing with Debian.
<Lathiat_> Does anyone know the story with libxp?
<fabbione> anyway i must go offline
<fabbione> i don't feel good at all
<mvo> get well fabbione 
<fabbione> cya
* sivang --> lunch
<HiddenWolf> fabbione, you just oploaded dhcp did you? :)
<Diziet> dpkg's build system is on crack.
<Diziet> ../../src/archives.c:320: error: 'nifd' undeclared (first use in this function)
<Diziet> ...
<Diziet> touch build-tree/build-stamp
<Diziet> -anarres:dpkg-1.13.11> echo $?
<Diziet> 0
<daniels> Diziet: *SHOCK*
<pitti> Hi jdthood 
<jdthood> hi ho
<sabdfl> hey pitti
<Keybuk> Diziet: so your idea is to never remove conffiles from status & list even after the package has removed them -- and just record them as obsolete.
<Diziet> Yes.
<Diziet> They'd disappear from status and list if some other package took them over.  Otherwise they'd stay on the disk and in dpkg's records.
<Keybuk> this means that if the conffile turns up again, either in the package or another one, we have the md5sum it used to be
<Keybuk> right?
<Diziet> Right.
<Diziet> The only downside is that if (for example) the obsolete file is part of an package which ends up in state config-files, the user might purge it.
<Diziet> If the file really is obsolete then it gets deleted, which is right.
<Diziet> But the file might not be obsolete; it might be script-handled by the new package.
<Diziet> But who goes around purging old obsolete packages, anyway ?
<Mithrandir> *hand*
<Mithrandir> :-P
<Keybuk> _o/
<jsgotangco> bye
<Keybuk> that kind of thing happens a lot, usually when someone takes a perfectly sane "postgresql" package and turns it into "postgresql-7.4"
<Keybuk> (or bind -> bind8 + bind9 )
<Diziet> Indeed so.
<Keybuk> people purge the old one, and they'd lose the config files for the new one
<Keybuk> I guess it'd be safer to just not remove obsolete files on purge
<Mithrandir> which makes them angry.
<daniels> the semantics I would expect would be that dpkg keeps a conffile record around while the package still exists
<daniels> s/package/file/
<daniels> so, if /etc/X11/rgb.txt is owned and xorg-common gets removed (non-purge), the record stays
<Keybuk> which is the current behaviour, it's still sucky, but it least it breaks in known ways
<daniels> if xrgb gets installed and starts providing /etc/X11/rgb.txt, I would expect that the conffile record get removed from xorg-common and move to xrgb
<daniels> if xrgb gets purged, I would expect that the conffile record disappears
<Keybuk> daniels: right.
<Mithrandir> Keybuk: how hard would it be to add dynamic registration and unregistration of files?
<Diziet> keybuk: The file only gets wrongly removed on purge if the file went from conffile to script-maintained in the same upgrade as it changed packages.
<Keybuk> why the same upgrade?
<pitti> Keybuk: the postgresql 7.5 upgrade package will clean up, btw
<Diziet> Err, no, I'm wrong: also if it went to script-maintained before it changed packages.
<Keybuk> wouldn't it happen at any point before?
<pitti> Keybuk: s/upgrade/transition/
<Keybuk> xorg-common ships /etc/X11/rgb.txt as a conffile
<Keybuk> then in an update, turns it into script-managed
<Keybuk> and then xrgb ships it as a script-managed file
<Keybuk> xorg-common gets purged (maybe we're using something else) ... it'd take /etc/X11/rgb.txt with it
<Keybuk> pitti: you know I just love to pick on you <g>
<Diziet> keybuk: Exactly the problem case, yes.
<daniels> how about you don't purge it if the md5sum is different
<daniels> or, at least, prompt on purge if the md5sum is different
<pitti> Keybuk: sure :-) I'm glad to be useful as bad example :-)
<Diziet> That doesn't help.  The maintainer scripts might have carefully avoided touching the file.
<Keybuk> daniels: still doesn't help ... it might just be not different
<daniels> Keybuk: *shrug*, 'you get what you deserve'
<Diziet> One option would be just not to delete the file on purge - just forget about it.
<Keybuk> that option certainly doesn't change anything
<daniels> Diziet: so then what does purge have over remove?
<Keybuk> we don't delete obsolete conffiles now
<pitti> daniels: prompting would be so evil - when I say "purge", I usually mean it...
<Keybuk> daniels: this is only about obsolete conffiles -- things that were conffiles once, but aren't anymore
<Diziet> In the future there should be a way for a package to say `this used to be a conffile and now it's known to be obsolete'.
<daniels> pitti: beats prompts on upgrades
<daniels> Keybuk: so how do you know they've changed hands?
<Keybuk> we don't
<pitti> daniels: right, but it's still evil...
<daniels> Keybuk: i.e. if, as you say, xrgb ships rgb.txt from postinst, rather than as a conffile
<daniels> Keybuk: so you have no way to separate the cases of orphaned, and 'obsolete'
<infinity> script-generated files aren't currently owned by anyone, so nothng really changes there if you just mark it obsolete.
<Mithrandir> daniels: it'd work fine if you could register and unregister conffiles in a postinst.
<infinity> Unless we grow some way to take ownership of generated files.
<Mithrandir> we kinda want that anyway, don't we?
<Keybuk> additional file registration is planned, but it's a while off
<infinity> It shouldn't be terribly difficult, why "a while off"?
<Keybuk> because I have a day job? :p
<infinity> So make a case for this dpkg functionality being a killer required feature for breez+1. :)
<Mithrandir> Keybuk: so it's more "patches accepted"?
<Diziet> inf: `shouldn't be terribly difficult'> dpkg has to cope with an awful lot of shit.  It's about 60% error handling and half of the remainder is edge cases.
<Keybuk> infinity: I'm vaguely trying to avoid getting dpkg development driven by Ubuntu because Mark wants different things than Debian
<infinity> Good point.
<Keybuk> which isn't a bad thing, but I like to keep the boxes separate
<lifeless> big box little box, big box little box
<daniels> is it bigger than a bread box?
<Keybuk> it's bigger than a baby's arm
<Mithrandir> we should have a "bug closed due to submitter vanishing off the face of the earth" resolution type in bugzilla
<Lathiat_> WONTFIX, SUBMITTERVANISHED
<infinity> close -> HITBYBUS
<infinity> (That string really should allow free-form entry)
<jdthood> In the meantime, should one use "INVALID"?
<infinity> mdz : Permission to unseed pike7.6-doc from supported?... It's the only thing holding pike7.6 in main, from my reading of germinate output.
<infinity> Well, being hit by a bus could make the submitter and invalid, so that would work.
<infinity> s/and in/an in/
<daniels> ba-doom-CSSH
<jdthood> infinity: good 'un
<daniels> get ready for lots of X hilarity this evening.  would be nice to get as much testing as possible before preview release, so get your breezy boxes all up to date and ready to be brok^W^Wtest.
<Kamion> Mithrandir: it's *supposed* to be cleverer now, but the .0 on the version number indicates general untestedness
<Lathiat_> daniels: whatcha doing?
<daniels> Lathiat_: modular server.
<Kamion> Mithrandir: I'll poke at it once the ISOs sync down, or if you want to have a look, edit archive-copier.postinst to remove the rm -rf of the working directory
<Lathiat_> daniels: btw, any idea fi that synaptics update had the fix for "double tapping" on alps touchpads? (e.g. being able to dobule tap and drag to do a selection)
<daniels> Lathiat_: from looking at the changelog, it appears to have, yes
* daniels vanishes for half an hour.
<Lathiat_> thanks
<Mithrandir> Kamion: wamerican seems to be missing still
<Mithrandir> (for instance)
<Mithrandir> from the to-copy file
<Kamion> Mithrandir: check whether it's got Task: .*language-support-en?
* mvo goes to get some lunch
<infinity> Kamion : Oh hey, now that you're back, are you playing RM again?
<Mithrandir> Kamion: looks like it.
<Kamion> infinity: er, depends how hard the question is
<infinity> Kamion : If so, see my question to mdz above about pike7.6-doc. :)
<Kamion> ogra: yeah, got it, just haven't had time to sit down and parse it yet
<ogra> Kamion, edubuntu.seed seems not to be the default....
<Kamion> infinity: yes, go ahead and unseed it
<ogra> i dont see any options set in there (i.e. the hostname)
<Kamion> ogra: I'll deal with your mail later today, I promise
<ogra> Kamion, thanks....
<infinity> Kamion : Also, with recent archive changes, it looks like the remainder of php4 crap can finally leave main for universe.  Do you feel like doing the ftp-masterish things required to make that happen?
<infinity> Kamion : (that includes the php4 source, yay)
<pitti> \o/
<Kamion> cjwatson@jackass:~$ sudo -u katie katie/anastacia | grep php4
<Kamion> cjwatson@jackass:~$
<infinity> Is that cron driven?
<Kamion> unless the changes postdate the most recent cron.sync (nine hours ago or so)?
<infinity> Yeah, I just re-germinated locally a few minutes ago. :)
<infinity> The changes are maybe an hour old.
<Kamion> ah, ok, I'll rerun cron.sync after this cron.daily
<infinity> This sync should allow you to demote both php4 and pike7.6
<siretart> Lathiat_: what is it with libxp?
<Lathiat_> siretart: just that various things (say, firefox (external builds)) are linked to it so nto having a copy is a bit of a pain
<siretart> Lathiat_: external builds are not supported, are they? ;)
<Lathiat_> no, just wonderign why it went really
<siretart> Lathiat_: nevertheless, the blackdown java jre's are also linked to it, which is imo more pain
<Lathiat_> indeed
<infinity> Because xprint is evil, and we're ridding the world of it.
<Lathiat_> and im sure many other things are too
<siretart> Lathiat_: I therefore packaged and uploaded it. so you find it in universe
<Lathiat_> siretart: ah, ok
<pitti> elmo: drupal sync, please
<siretart> pitti: have you any other questions about firefox security irw tabextensions?
<infinity> Kamion : Erm, pike seed change just went in now, I had GPG prompting for a passphrase in the background... La la...
<pitti> siretart: no, your explanation was good, I just didn't check it yet again
<siretart> okay
<siretart> pitti: do you happen to know what is it with the printing issue?
<siretart> is it just some weird lib causing the segfaults or is the bug in firefox?
<pitti> no idea
* pitti is not the firefox maintainer :-)
<pitti> in breezy?
<siretart> in hoary/security
<siretart> there is a bugzilla report about this
<siretart> #12965
<Lathiat_> mjg59: setting up general console font seems to fail with usplash active
<pitti> elmo: osh sync, pleas
<Lathiat_> e
<pitti> yes, thanks :-)
<Lathiat_> ;p
<Kamion> infinity: php4-cgi php4-cli php4-common php4-dev pike7.6 pike7.6-core pike7.6-dev pike7.6-gdbm pike7.6-image binaries plus php4 source demoted
<pitti> chmj: can you please check that http://cvs.sourceforge.net/viewcvs.py/bluez/utils/hcid/security.c?r1=1.36&r2=1.34&diff_format=u is applied in bluez-utils as  well?
<Mithrandir> hm
<Mithrandir> update-notifier in upper left corner
<Lathiat_> daniels: oh yeh
<ogra> Mithrandir, the notification or the whole icon ? 
<Lathiat_> daniels: new synaptics totally screwed my alps
<Mithrandir> ogra: the notification.
<Lathiat_> daniels: its now *very* unsensitive moving wise, and if i double tap and move, the cursor moves in the wrong direction
<ogra> Mithrandir, i have the notification left as well sometimes
<Mithrandir> ogra: sounds like a bug
<ogra> Mithrandir, i guess it needs a little delay until the notification icon is there
<infinity> Kamion : pike7.6 source as well, or did something keep it in?
<ogra> Mithrandir, yup
<Mithrandir> ogra: care to file the bug, or should I?
<chmj> pitti: ok, still waiting for mdz to approve UVFE
<pitti> chmj: why? why not just apply the patch?
<ogra> i can... i'm looking at boring compiler runs anyway
<Mithrandir> ogra: great, thanks
<chmj> pitti: the new version has more fixes including d-bus and memory allocation bug 
<ogra> #14479 for mvo :)
<Kamion> infinity: apparently something's keeping it in
<infinity> Kamion : Hrm.  germinate seems to say it can go.
<infinity> Kamion : I guess I'll need elmo for this, then?
<infinity> Kamion : (No big deal, since elmo was the one adamant about removing pike in the first place)
<Kamion> infinity: oh, I might have run cron.sync before your seed change
* Kamion reruns
<daniels> Lathiat_: sigh
<Lathiat_> daniels: sorry to spoil your day
<daniels> Lathiat_: ha ha ha ha ha
<Kamion> infinity: you'll need to merge that change to kubuntu and edubuntu as well
<Lathiat_> daniels: ;p
<Kamion> infinity: want me to do that? I have all the trees handy
<Mithrandir> Kamion: the problem with your language-support code in archive-copier seems to be that since one of the langpacks isn't available, it won't try any of the other ones.
<sabdfl> Kamion: quick question on cd building, related to the xubuntu community request
<sabdfl>  - can we build cd's that depend on universe packages
<Riddell> we really should have a desktop-common seed so these things don't need to be syned so much
<infinity> Kamion : Yeah, please.  Not sure why they aren't all subdirectories of the one seeds archive. :/
<sabdfl>  - would it take a lot of your time to build those as well?
<Kamion> sabdfl: I've just been talking to jdub about that
<sabdfl> they would be unofficial, published but not supported
<Kamion> sabdfl: a number of changes are required; firstly fairly trivial though slightly time-consuming stuff with hardcoded component names in various places; secondly I really don't want regular CD builds to have access to universe because not having universe packages on disk is a really useful guarantee that they can't be used for Ubuntu CD builds
<Kamion> sabdfl: however the latter can probably be worked around by having a second archive mirror, assuming the disk space issues there aren't prohibitive
<Kamion> sabdfl: apart from that it's probably about a day of work to set up
<Lathiat_> pitti: iirc you had a list of security notices applying to universe stuff that werent looked at?
<Kamion> sabdfl: I'm slightly concerned about resource usage on little, because it's beginning to get to the point where all the regular cron jobs are impeding our ability to do manual builds when we're in a hurry
<Kamion> sabdfl: if it's a one-off before CD building moves to launchpad, I'm fine with it
<mvo> ogra: do you have a screenshot? 
<pitti> Lathiat_: yes: http://people.ubuntu.com/~pitti/ubuntu-cve/unfixed.html has all unfixed issues sorted by release and suite
<Lathiat_> pitti: is anyone working on universe security?
<Kamion> sabdfl: definitely *post*-preview would be nice though ;)
<pitti> Lathiat_: in the past, yes, but not right now
<pitti> Lathiat_: therefore a huge pile has accumulated
<ogra> mvo, nope, and thats hard..... because the desktop is starting up at this moment...
<ogra> mvo, it doesnt occur every time
<ogra> and it doesnt occur in xnest...
<ogra> mvo, basicall the popup is shwn directly below the main menu (on the left) while the panel isnt populated with anything
<mvo> ogra: hm, ok. there is already a small delay, I can increase it a bit. what HW is that? your amd64 notebook?
<ogra> and my ltsp testserver (i686 900Mhz, 256MB)
<ogra> mvo, how small is the delay ?
<mvo> ogra: ~0,5s-1s
<ogra> heh, make it 5 or 10 sec...
<Kamion> ogra: I don't understand the point of edubuntu-devel@lists.ubuntu.com/seeds--breezy--0--patch-25; it seems actively counterproductive
<Kamion> using metapackages in seeds in order to pull in other seeds makes the relationship between seeds and metapackages unpleasantly circular
<Kamion> and unstable
<slomo> mdz: hm... the ffmpeg source package is still in main... for binary packages: ffmpeg in universe, libpostproc-dev in multiverse, libavcodec-dev in universe...
<Kamion> slomo: it's on the schedule for demotion
<ogra> Kamion, ah, that is adding edubuntu-server to ship ? 
<slomo> Kamion: ok, but nothing is holding it back?
<ogra> Kamion, how do i get edubuntu-server on the CD ? mdz said he doesnt know and that seemed the only method that worked
<jdub> Kamion, sabdfl: i think i can keep post-preview implementation of install/livecd builds sounding exciting, shouldn't be a problem
<Kamion> ogra: the metapackages are generated from seeds, so using the metapackages *in* seeds gets pretty nasty. I'll have a look
<Kamion> slomo: nope
<sabdfl> Kamion: +1 on a second archive mirror for building non-official cd images
<Kamion> slomo: I've demoted it now
<ogra> Kamion, i think i should have a little germinate/seeds and CD buildscripts class given by you if the schedule permits it... there was nobody who could help me the last month... we need to spread the knowledge a bit :)
<ogra> Kamion, i.e. after release....
<Kamion> yeah, I think I'll do something at UBZ
<Mithrandir> Kamion: uhm, archive-copier doesn't seem to actually copy the .debs?
<ogra> yeah
<sabdfl> Kamion: +1 on post-preview
<Kamion> Mithrandir: just looking now ... I could easily have broken it
<Kamion> ogra: I think it should just be a matter of educating cdimage about edubuntu seeds
<ogra> Kamion, yes, and i dont know how to do that :)
<sabdfl> jdub: they should keep banging on the packages as fast as possible
<sabdfl> not wait for the cd builds
<slomo> Kamion: thanks :)
<Mithrandir> Kamion: sorry, I'm blind.
<Kamion> ogra: right; fortunately I do :)
<ogra> :)
<Kamion> cdimage/bin/list-seeds is a bit unpleasant
<ogra> where would i find that dir ? 
<Kamion> colin.watson@canonical.com--2005/cdimage--mainline--0
* ogra curses xscreensaver for respecting LTSP_CLIENT only on the first lock attempt 
<Kamion> I've just modified it to add server to edubuntu install CDs
<ogra> ah, ok
<ogra> ok, i'll change the ship seed back then
<Kamion> ok, and the STRUCTURE file
<Kamion> thanks
<ogra> no, thanks to you.... :)
<ogra> Kamion, i felt quite lost the last weeks, feels good to have you around again
<jdub> sabdfl: the packages are all good :)
<Kamion> Mithrandir: it's copying wamerican to /var/cache/archive-copier/ship/ here
<Mithrandir> *sigh*; the cd I have is with an old archive-copier. :-(
<Mithrandir> argle.
<Kamion> ah
<Mithrandir> I suck
<Kamion> you must've rsynced before the CD build happened
<Mithrandir> isn't that supposed to happen at like 0600 UTC or so?
<Kamion> <cjwatson@cairhien ~/src/ubuntu/cdimage>$ grep ' ubuntu cron.daily$' etc/crontab
<Kamion> 21 8 * * *      for-project ubuntu cron.daily
<Kamion> usually finishes at 0920 or so
<Mithrandir> what TZ is that?  UTC?
<Kamion> London
<Kamion> datacentre time, IOW
<Mithrandir> hm, I thought I synced a little later than that, but I can't have.
<Mithrandir> oh well.
<sivang> mpt: morning
<mpt> hi sivang
<sivang> mpt: how are you? are you in for a UI usability question? ;)
<mpt> sure, usability questions 'r us
<sivang> mpt: lol
<sivang> mpt: right click the panle context menu, do you the lpi items there?
<mpt> sivang: No, I'd expect them to go in the same menu the "Help" item is in currently
<mpt> i.e. in Breezy, "System"
<mpt> to be consistent with other apps
<slomo> Kamion: can you also demote the following packages to multiverse (they are the ones holding ffmpeg/libavcodec-dev in universe) and have no other packages depending on them: gem, gnusound, lynkeos.app, motion, opencv, smilutils
<Kamion> slomo: this stuff all shows up automatically; see http://people.ubuntu.com/~mdz/anastacia.txt
<Kamion> there is generally no need to explicitly tell me/others about them
<Kamion> oh, sorry, you said multiverse. are the licences non-free?
<Kamion> I prefer not to touch the universe/multiverse distinction; talk to elmo about that
<slomo> Kamion: no but ffmpeg has support for some "funny" formats with ugly patents
<slomo> Kamion: ok, i'll do
<Mithrandir> hm, is usplash supposed to have a white border?
<slomo> elmo: do you have some minutes for me? ;) i want to move some stuff from universe to multiverse
<mpt> sivang: is that ok?
<jbailey> Mithrandir: mjg59 said that was being fixed.
<jbailey> Mithrandir: Colour #1 in the pallette is currently white, so things just need reorganising.
<Mithrandir> jbailey: ok
<tepsipakki> does /etc/init.d/pppd-dns and dns-clean do the same thing?
<Mithrandir> jbailey: uhm, aren't you supposed to write american english, not british english?
<infinity> Mithrandir : Well, no, he's not American.
<Mithrandir> infinity: canadian, close enough.
<jbailey> Mithrandir: Shouldn't you be off celebrating Oktoberfest or something?
<sladen> Mithrandir: he comes from Canadia, they seem to speak a strange combination of 19th century French and Victorian English
<Mithrandir> jbailey: is that already?  We usually don't have that here until it actually _is_ october.. :-P
<jbailey> (I figure the distance between Canada and the US is about the same as .no and .de... *g*)
<daniels> sladen comes from Cambridge, they seem to speak a strange combination of 19th century French and German
<jbailey> Mithrandir: In seriousness, Webster's destruction of the English language wasn't even intended for non-American audiences.
<jbailey> s/even/ever/ afaik.
<sladen> feh, I come from Nottingham and Robin Hood wouldn't be seen dead speaking the Queen's English
<jbailey> It's turned into a standard language, but at the time, it happened largely because he was writing the dictionary, AFAIK.
<Mithrandir> It has been observed that most people don't speak English while dead.
<jbailey> Mithrandir: Get a better seer. =)
<Mithrandir> jbailey: ook
<sladen> :)
<jdub> sladen: see r-t or d-d-l lists
<sladen> jdub: can you remember which month?
<jdub> last
<jdub> look for baton
<slomo> jbailey: hi ;) i'm back to 2.6.12-3-powerpc on my ibook :P do you think we get this fixed somehow for breezy?
<jbailey> slomo: One can hope.  But given that your initramfs appears to be correct, I can only ask the kernel folks what's going on.
<jbailey> I need an error message.
<slomo> jbailey: do we have someone i can talk to who knows everything about the ppc kernel? ;)
<slomo> jbailey: sure... wait a moment
<sladen> jdub: "baton" was the word, ta!
<jbailey> Is the bug in bugzilla?  If yes, what number, I should add myself to the cc: list.
<Kamion> Mithrandir: there does still seem to be something wrong, though
<slomo> jbailey: no, i haven't done a bugreport yet... most of my problems are solved faster in irc ;)
<jbailey> Right.  But with this one in bugzilla, it'll get better attention.
<slomo> jbailey: ok, i'll create one :) i have nothing todo anyway until elmo responds ;)
<Mithrandir> Kamion: so you'd like me to do a test install and poke at it?  I can do that, but if not, I'll see if x86emu wants to play ball with me today.
<Kamion> Mithrandir: we can race, if you like - I'm poking at it at the moment
<Lathiat_> whos the person who looks after hoary-backports?
<ogra> Lathiat_, MEZ
<Lathiat_> got an email?
<Lathiat_> want to look at getting some security stuff looked at
<slomo> jbailey: what package? linux-meta?
<pitti> Lathiat_: parse error
<Lathiat_> pitti: heh, security, backports? ;p
<ogra> Lathiat_, <martin@sourceguru.net> or <ubuntu-backports@lists.ubuntu.com>
<pitti> Lathiat_: ah, this was for Mez, I see
<Lathiat_> ogra: thanks
<jbailey> slomo: Even against initramfs-tools for now.
<jbailey> slomo: I can take care of getting it assigned and such correctly.
<Mitario> mako, ping
<hub> hi
<hub> is it me or my breezy upgrade is sort of broken
<hub> I don't have any icon displayed
<pitti> hub: occurred to me, too; I changed to the default theme to fix it
<ogra> hub, we sell them sparately now... as add ons ;)
<hub> ah
<hub> that does the job
<hub> pitti: thanks for the tipe
<ogra> hub, which icon theme did you use before ? 
<Lathiat_> f**k i just got a metacity crash and i didnt have gdb running on it
<hub> clearlooks
<hub> and now clearlooks
<ogra> hub, icon theme ? 
<hub> ogra: I just selected the gnome theme clearlooks
<ogra> ah...
<hub> and all that was with it
<pitti> Lathiat_: http://people.ubuntu.com/~pitti/packages/crashrep/  :-)
<hub> ogra: so it messed the icons I'd say, but now it works
<seb128> hub, pitti: they dropped the clearlooks icon theme when they moved it to gnome-themes
<Lathiat_> pitti: wassat do?
<pitti> seb128: will that be an issue for hoary upgrades or just break intra-breezy ones?
<hub> seb128: ah, make sense
<slomo> jbailey: https://bugzilla.ubuntu.com/show_bug.cgi?id=14485
<pitti> Lathiat_: that's my alpha-demo-snapshot crash reporting agent
<pitti> Lathiat_: install the two debs, and on every segfault you will get a report in /tmp/crashrep.application.*
<pitti> Lathiat_: it also tries to get a stacktrace
<ogra> pitti, we'll just have to set a default icon theme for clearlooks then... seb128 shouldnt that automatically fall back to gnome if its missing ?
<seb128> pitti: likely to be an issue for people using clearlooks
<Lathiat_> pitti: ooh
<hub> ah well
<pitti> Lathiat_: prototype for https://wiki.ubuntu.com/AutomatedProblemReports
<hub> so it is sort of a bug
<ogra> seb128, i thought the theme selector cares for such occurences
<pitti> Lathiat_: I just did not get very far (GUI stuff and so on)
<Lathiat_> ahah it just crashed again
<seb128> /usr/share/themes/Clearlooks/index.theme is to change probably
<pitti> seb128: many people will do that 
<Lathiat_> but, it seems it didnt build with debug symbols
<Lathiat_> doh
<seb128> pitti: I know, you are welcome to fix it, I've too many bugs to tackle everything alone
<ogra> seb128, i'll do... i have to do some accumulated artwork stuff anyway over the weekend
* pitti hugs ogra
<seb128> thanks
<ogra> :)
<seb128> pitti: clearlooks is the not the default theme though, human doesn't have this issue
<seb128> "IconTheme=gnome"
<seb128> hum, the index.theme has it
<hub> I don't like "human" colors
<hub> but that is just me
<ogra> btw, shouldnt we set our Human defaults in /usr/share/gconf/cdd.defaults ?
<ogra> i think its not done currently
<seb128> we don't use cdd atm afaik
<ogra> seb128, edubuntu does :)
<seb128> right, but that probably makes sense to use the libgnome patch as Ubuntu
<seb128> rather than unpatching libgnome to change the cdd then
<ogra> yup
<Lathiat_> is building DEB_BUILD_OPTIONS=nostrip the right thign to do to get a package with debuggign symbols?
<Lathiat_> and woudl work with cdbs stuff?
<seb128> usually it work yeah
<Lathiat_> hrm, didnt seem to work on metacity
<seb128> works fine for GNOME packages
<seb128> you can use noopt too
<seb128> it does
<seb128> I've used it yesterday
* Lathiat_ tries again
<Lathiat_> does it not work with debuild vs dpkg-byuildpackage or something?
<Mithrandir> debuild might be stripping DEB_BUILD_OPTIONS
<seb128> I use debuild and it works fine
<Lathiat_> hrm, well i'll rebuild adn see what happens
<jdub> mjg59: oh. dude.
<jdub> http://www.popies.net/ams/
<jdub> http://www.kernelthread.com/software/ams2hid/
<jdub> :-)
<jdub> http://wingolog.org/pub/gdbinit <- rad!
<Lathiat_> haha
<Treenaks> jdub: is that like rml's IBM motion sensor crack?
<Kamion> debuild isn't supposed to strip DEB_*
<ogra> YIPPIE
* ogra dances around xscreensaver
<Treenaks> ogra: !?
<pitti> ogra: deuglified again?
<Lathiat_> http://www.atoker.com/tmp/protection.png 
<ogra> pitti, long ago
<Treenaks> Lathiat_: ! :)
<Robot101> Lathiat_: lol
<Lathiat_> hehe, alp posted that into #gnome-hackers the other day, had much class :)
<ogra> but a requirement for the upload was that i get it to respect LTSP_CLIENT which only worked until the first unlock attempt
<ogra> i just found the function that respawns the hack...
<ogra> and it works :)
<Lathiat_> yay
<Mithrandir> Kamion: what's the failure you're seeing?  It looks good to me?
<jdub> jbailey: http://bugzilla.ubuntu.com/show_bug.cgi?id=14477
<jdub> jbailey: is that very kernel or very initramfs?
<zul> i think very initramfs
<Kamion> Mithrandir: w{american,british}.deb at least seem to be getting removed from /var/cache/apt/archives/ after base-config moves them in there
<Kamion> I don't understand why
<Kamion> oh, plus I get a dictionaries-common question
<jdub> Lathiat_: that's offensively non-HIG-compliant
<jdub> Lathiat_: i'm going to yell at alp
<Kamion> hey, now it installs cleanly apart from the question; I don't understand this
<Lathiat_> jdub: haha
<slomo> jbailey: i have some news for you ;) i finally tested latest initramfs with 2.6.12-3-powerpc and i get exactly the same error... so it should be initramfs' fault
<Lathiat_> /usr/bin/metacity: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped
<Lathiat_> yay
<Kamion> Mithrandir: /var/cache/apt/archives/ only goes up to pppdcapiplugin
<Mithrandir> Kamion: full disk?
<jbailey> slomo: No, it could still be the kernel's fault.  that was when we switched to initramfs.
<Kamion> Mithrandir: no
<Kamion> 6GB free
<jbailey> If the kernel was broken after that point for loading an initramfs, it's certainly going to be broken before.
<slomo> jbailey: ok
<jbailey> jdub: Hard to say.  Looks like he needs the driver blacklisted for him on certain hardware.
<Kamion> and in fact language-support-en failed to install correctly, although base-config *cough* ignores that
<jbailey> jdub: It still might be kernelish, but I've grabbed the bug for now.
* Mithrandir kicks apt in the head.
<Mithrandir> apt should have better timeout detection
<Mithrandir> allow me to correct myself: apt should _have_ timeout detection.
<Lathiat_> oh it gets there
<Lathiat_> give it 5 minutes or so
<mjg59> jdub: ?
<Mithrandir> Kamion: wbritish and friends are in /var/cache/apt/archives here, as files, not symlinks (which is what archive-copier seems to have put there)
<Kamion> *symlinks*?
<Mithrandir> yup
<Kamion> Mithrandir: what stage of the install are you at?
<Mithrandir> I'm done with the install now.
<Kamion> Mithrandir: oh no, actually, that's correct
<Mithrandir> archive-copier makes symlinks from /var/cache/archive-copier/ship (and so on) to /var/cache/apt/archives
<Kamion> no, archive-copier does not
<Kamion> base-config/lib/menu/archive-copier does
<Kamion> # Make cached packages that aren't installed by default visible to
<Kamion> # apt, but only symlink them so that 'apt-get clean' doesn't remove
<Kamion> # them.
<Kamion> I guess that could be the problem
<Kamion> but it seems a bit of a stretch
<Mithrandir> well, it seems to work here (using Norwegian as the installation language)
<Kamion> ah, try English
<Kamion> the Norwegian language-support-* isn't on the CD so it's not as good a test
<Mithrandir> well, it installs the language-support-en as well as language-support-no
<Kamion> archive-copier doesn't copy them though - I think that's a bug
<Kamion> so it's probably downloading language-support-en from the network
<Mithrandir> no, it's not
<Mithrandir> not for me, at least.
<jdub> elmo: ping
<Mithrandir> Kamion: are you sure your CD is up-to-date?
<Kamion> Mithrandir: yes
<Kamion> oh, localechooser/supported-locales might list en
<Mithrandir> Kamion: I can try an English install and see if I can get it to break.
<Kamion> yeah, it does, that would explain it
<Kamion> Mithrandir: please
<Kamion> this breakage is weird - I'm going to try running pkgsel under strace
<tepsipakki> how the heck do I disable gdmflexiserver?
<tepsipakki> without uninstalling Xnest
<seb128> you probably don't
<infinity> Kamion : Oh, can you NEW the php5-syck binaries?
<thesaltydog>  just installed breezy and getting a lot of "Gdk-WARNING **: locale not supported by Xlib at /usr/lib/perl5/Gtk2.pm line 59" messages...
<Treenaks> what's your locale? :)
<thesaltydog> it_IT
<sivang> mpt: It's ok, it is just that I'd need to drop all of my patches and my work was redundent. I wish I had asked you that before..
<thesaltydog> Treenaks, obviously in Hoary was working fine.
<tepsipakki> seb128: actually, setting FlexibleXServers=0 in gdm.conf helped. oh well
<lamont-away> seb128: got a minute:
<lamont-away> ?
<sivang> seb128: how can we make someone click way through to gnome-panel's lp page from teh System menu?
<thesaltydog> Treenaks, I have seen this: Bug #13724 and it looks like mine..
<lamont-away> seb128: nm
<Treenaks> thesaltydog: isn't that a feature?
<thesaltydog> Treenaks, pardon?
<bddebian> Hello
<Treenaks> thesaltydog: well, I mean, hoary is supposed to be UTF-8, and breezy even more
<thesaltydog> Treenaks, yes infact my default is it_IT.UTF-8
<Kamion> infinity: done, I think. the straight-to-universe NEW procedure hurts my brane
<Treenaks> thesaltydog: is that defined in locale.gen?
<bddebian> brain :-)
<Kamion> bddebian: deliberate misslepping
<bddebian> Ahh :-)
<thesaltydog> Treenaks, of course
<Kamion> I think it's a reference but I can't remember to where
<lamont-away> fabbione: #14130 - what was the debconf question, do you remember?
<sivang> mpt: the thing is, going the way so it seems to me excludes the appelts and the panel from even considered from being opened in launchapd, presentationally there's nothing that pops it to the user other then the context menu...
<seb128> lamont-away: pong
<seb128> sivang: you don't?
<sivang> seb128: sorry, I lost context, can say again?
<seb128> tepsipakki: k
<lamont-away> seb128: was there a {gnome,$mumble} library that was missing a Depends: libglitz recently?  or am I just special?
* lamont-away figures the rebuild of gnome that is currently finally happening on hppa (new binutils, woot) will fix that issue
<lamont-away> hence the nm right after the ping... :)
<tepsipakki> seb128: actually Xnest is not even installed
<jdub> lamont-away: i got more memory for my D370
<jdub> lamont-away: i think some of it is bung, but i'll figure out which
<seb128> lamont-away: no, cairo used to build with it, and a bunch of .la got a mention to glitz.la
<seb128> lamont-away: so when cairo stopped depending on it ...
<Diziet> Dammit, I wish apt would let you dpkg -i while it was downloading stuff.
<seb128> lamont-away: is there any issue remaining due to that?
<pitti> Diziet: BAL - big apt lock :-)
<seb128> sivang: sivang seb128: how can we make someone click way through to gnome-panel's lp page from teh System menu?
<Diziet> I wouldn't mind if it just took out its _own_ lock.  But it stole dpkg's too.
<Mithrandir> Kamion: apart from the dictionaries-common question, I can't reproduce any problems.
<Mithrandir> Kamion: and wbritish is not downloaded; it's the copied version which is installed.
<sivang> seb128: I see, so we should leave gnome-panel and applets out of lpi ?
<Kamion> Mithrandir: ok, this is truly weird then
<infinity> seb128, lamont-away : That's all cleared up on the primary arches, but I assume hppa and sparc may still see some fallout for a bit, if they're backlogged.
<lamont-away> seb128: that answers my question - I can deal with it from here.
<lamont-away> infinity: yeah - this is on hpap
<lamont-away> hppa
<jdub> seb128: is the gksu full screen dimming scary stuff going to stay?
<Mithrandir> Kamion: it's a bit hard to diagnose a problem you're the only one seeing. :-P
<bddebian> heh
<seb128> jdub: ask mvo, he puts it and kind of maintain gksu :)
<sivang> jdub: scares me as well ;)
<mvo> jdub: it's in from upstream, I don't really care wheter to have it in or not
<seb128> sivang: what do you want to let away from lpi and why?
<Kamion> Mithrandir: I'll keep hammering at it
<Kamion> Mithrandir: thanks for the data points, though
<sivang> seb128: 15:39 < seb128> sivang: sivang seb128: how can we make someone click way through to gnome-panel's lp page from teh System menu?
<mpt> sivang: sorry about that ... it has been illustrated in the spec for a couple of months now (albeit that the menu has the wrong title)
* Kamion -> late lunch
<robertj> the nightly live cds are supposed to have usplash now right?
<sivang> seb128: 15:33 < seb128> sivang: you don't?
<mpt> jdub: So it's not just me who thinks that's really weird? phew, I thought I was alone in the world :-)
<mpt> sivang: oh, the page for gnome-panel itself?
<sivang> mpt: it's cool, basically drop 2 patches that's all - but I return to my question, how would then people be pushed into opening gnome-panle's and the applet's page in launchpad?
<mpt> sivang: yeah, I suppose that belongs in the context menu
<sivang> mpt: yeah ;)
<sivang> mpt: THANK you!
<infinity> I like the full screen dimming, but I'm not too keen on the fact that it seems to take a few seconds before it does anything at all.
<sivang> :)
<mpt> sivang: Sorry, I thought you meant the page for Ubuntu-in-general
<seb128> sivang: copying the sam sentence will not change my question, I don't parse them correctly
<jdub> mvo: perhaps we should change it to set an urgent hint, and not do the dimming
<mvo> jdub: do you want it fixed before preview?
<jdub> mvo: if you have time, that would be great :)
<seb128> jdub: it has the first plan and the lock anyway, effect or not, no need to set any hint imho
<jdub> seb128: it might help if the window pops up somewhere weirdly
<seb128> hum
<jdub> seb128: given that it has a keyboard grab
<mpt> It's always in the middle of the screen, though, right?
<seb128> it pop first plan centered
<jdub> mpt: well, at the moment it is
<mvo> and it should set keep_above() already too
<mpt> so what would "weirdly" be?
<seb128> the question is effect or not
<seb128> no need of any hint
<jdub> mpt: when we turn off the dimming and fully controlled borderless window positioning
<seb128> it'll still be centered and on first plan
<jdub> it may appear in places the user doesn't look at immediately
<jdub> seb128: ok
<seb128> it was this way for hoary, no?
* jdub will look again after the doom-gloom-dimmer is gone ;)
<jdub> yeah
<bddebian> Sorry for asking in here vs. motu but how do I go about resolving some of my issues with unmet deps or debian merges where deps or build-deps are missing from the archive??
<seb128> bddebian: example?
<bddebian> yaprimaxgui needs pxscan (multiverse)
<bddebian> libdebtags1 is another
<sivang> mpt: ;)
<sivang> seb128: k, np, mpt has answered what I asked, sorry for bugging you
<Lathiat_> man, having your touchpad movement at a 1:1 ratio in physical size sucks
<Treenaks> Lathiat_: touch screen 8)
<Lathiat_> heh
<Lathiat_> well th synaptics driver broke bad
<Lathiat_> in the latest upload
<Lathiat_> the mouse even decides to move in the opposite direction sometimes
<Treenaks> Lathiat_: well, the old one broke clicking on my HP
<Treenaks> s/clicking/tapping
<Lathiat_> heh
<Lathiat_> thats not so bad trust me ;p
<Treenaks> Lathiat_: tel mjg59 ;)
<Lathiat_> well i whinged to daniels im sure he'll look at it :)
<doko> seb128: gnome-panel has the three "top" menu items translated (at least I can find them in the de.po file), but doesn't show these items, they are shown in plain en.
<mvo> Kamion: has preview-freeze already started? or will it start at 00:00UTC (or some other time) today?
<tepsipakki> daniels: why does xorg-driver-synaptics depend on xserver-xorg?
<tepsipakki> i need that driver, but can't uninstall all the unneeded servers etc
<daniels> tepsipakki: should be -core, but if you're concerned about like 2.5MB ...
<tepsipakki> well, -core seems to depend on xserver-xorg as well ;)
<tim1> hello
<tim1> does anybody know why xorg-driver-fgrlx depends on ALL other xorg drivers?
<Diziet> Joy.  My new dpkg creates a status file that makes old dpkg coredump.
<tim1> I would have to install 50+ drivers for hardware i don't have to use fglrx
<daniels> look, seriously, I'm only going to say this once
<daniels> the point of creating xserver-xorg-core and splitting it wasn't so you could uninstall stuff
<daniels> if you're worried about like 15MB, you can find it much easier in other places
<sabdfl> the point is to accelerate the development
<chmj> shackan: ping 
<tepsipakki> well, why does xserver-xorg say that it is a dummy package, that you can remove if not needed ?-)
<sabdfl> because each of these packages can have a separate team, or additoinal contributors
<rtcm> daniels: btw, any idea why the sis driver has almost 3 MB while I have one from the original authos with about 600 kb?
<sabdfl> smaller uploads, smaller teams, modular will be a big win from a community development point of view
<sabdfl> it will be easier to find contributors for a driver, or a library, than the whole hog
<tepsipakki> I know the benefits, just wondered those silly dependencies
<tim1> ok, got it, I didn't ask this because i was worried about some dis space, I actually thought it would be a bug
<bddebian> seb128: No thoughts on what I should do?
<daniels> the point is two-fold: a) accelerate development, b) make updates easier to do as only one package changes ratehr than all of them (think: security)
<daniels> rtcm: i suspect we're stripping it sub-optimally
<sladen> tepsipakki: is
<sladen> tepsipakki: it's a virtual package that does nothing more than depend on all the separate parts---means you can type 'apt-get install xserver-xorg' rather than having to type 'apt-get install {50 different packages}'
<tepsipakki> i know... the description just should be changed, if it in fact cannot be removed
<bddebian> Man and here I thought it was just daniels that hated me :-(
<bddebian> :-)
<slomo> daniels: at least on ppc the /etc/X11/X link points to something non-existant (/usr/bin/X11/Xorg iirc)... has to be /usr/bin/Xorg imho
<daniels> slomo: /usr/bin/X11 should be a symlink to /us/rbin
<slomo> daniels: it isn't for me... it's an empty directory. (this installation was an update from colony 2 to current breezy)
<daniels> slomo: #13379, hoping to fix it this weekend
<daniels> we're hitting weird semantics of dpkg
<slomo> daniels: ok... thanks :)
<pablof> hi, how can i suggest one package for multiverse repository ?
<lamont-away> in debian/config, is it trivial to distinguish upgrade from fresh install?
<ogra> pablof, put it on the UniverseCandidates wikipage...
<pablof> ogra: ok, thanks
<carlos> mvo, hi
* lamont-away hates grandma's computer.
<bddebian> lamont-away: So buy her a new one :-)
<lamont-away> I meant the generic grandma
<mvo> hey carlos, is there a problem with import language-selector into rosetta?
<bddebian> lamont-away: Ohh, hehe
<carlos> mvo, seems like there is a problem, yes
<carlos> I think I got the source code last month and I didn't see any .pot file
<carlos> mvo, am I wrong?
<mvo> carlos: apt-get source language-selector gives me po/language-selector.pot 
<carlos> mvo, since when?
<carlos> I mean is it new?
<mvo> carlos: ~14 Jun (according to the changelog)
<carlos> wow
<mvo> :)
<carlos> ok, then I checked another package....
<mvo> carlos: could you please have a look if it can be imported now? 
<zyga> ah here you are :-)
<zyga> I didn't notice
<mvo> carlos: the initial version did not contain a pot file, that might have been the problem
<carlos> mvo, sure. Anyway, for the future, you don't need to create a product on launchpad to get an Ubuntu package translated
<carlos> zyga, ;-)
<mvo> carlos: yeah, I know that now, thanks
<carlos> ok, the problem is that we don't have any language-selector inside launchpad's database
<mvo> carlos: please ping me if there still is a problem
<zyga> mvo, carlos: thank you both for your help :)
<carlos> mvo, sure
<mvo> zyga: thanks for telling us about the problem
<Kamion> mvo: later today AFAIK
<Diziet> keybuk: ping
<Keybuk> Diziet: yup
<Diziet> Hi.  So I have a patch (or will do shortly).
<Diziet> Should I upload a new 1.13.10ubuntu into breezy ?  Should I do anything with the Debian version ?
<Diziet> Are you planning to put 1.13.11 into breezy ?  Maybe we should.
<Keybuk> I suspect we'll need to test the batch a bit more before putting it into breezy
<Keybuk> check with mdz what he feels
<Keybuk> 1.13.11 isn't going into breezy
<Diziet> 1.13.11> shame, but there you go :-).
<Keybuk> submit the patch to the Debian BTS, I'll check it out and upload it with the next version of dpkg into Debian -- probably in a week or so
<Diziet> OK.  Willdo.  I'll install it on a few of my installs here too.
<Keybuk> *nods* I've promised bubulle a week of freeze to get the translations up to date ya see <g>
<Diziet> I would like to get this patch into the preview release because it fixes a spurious conffile prompt in hoary->breezy.
<Keybuk> *nods*
<Kamion> preview freeze is today, so it'll require manual review / exception etc.
<Keybuk> but if I mentioned that having such a massive number of people upgrading to test it was a good thing, mdz would do his nut and have a heart-attack
<Keybuk> so I won't mention that :)
<bddebian> hehe
<daniels> heh
<daniels> preview freeze
<Diziet> I don't know if this patch will apply cleanly to .10ubuntu.
<Keybuk> should do ... there wasn't that much of a change
<Diziet> The changelog .10 to .11 looks big.
<jlj> http://nanocrew.net/?p=129
<Diziet> k: it does.  The BTS will have the patch soon.
<zyga> carlos: < > are displayed as &lt; &gt; is that intentional?
<Kamion> Mithrandir: ok, I've got conclusive evidence of weirdness here
<Kamion> Mithrandir: 'grep wamerican_ pkgsel.trace' goes:
<Kamion> 26584 execve("/usr/bin/apt-extracttemplates", ["apt-extracttemplates", "/var/cache/apt/archives/wamerican_5-4_all.deb"] , [/* 32 vars */] ) = 0
<Kamion> 26584 open("/var/cache/apt/archives/wamerican_5-4_all.deb", O_RDONLY) = 3
<Kamion> 26728 execve("/usr/bin/dpkg", ["/usr/bin/dpkg", "--status-fd", "19", "--unpack", "/var/cache/apt/archives/aspell-en_6.0-0-5_all.deb", "/var/cache/apt/archives/mozilla-firefox-locale-en-gb_1.0.4lang20050515-1ubuntu3_all.deb", "/var/cache/apt/archives/myspell-en-gb_20050823-1ubuntu1_all.deb", "/var/cache/apt/archives/myspell-en-us_20050823-1ubuntu1_all.deb", "/var/cache/apt/archives/openoffice.org2-l10n-en-gb_1.9.125+2.0b
<Kamion> 26728 stat64("/var/cache/apt/archives/wamerican_5-4_all.deb", 0xbfb77488) = -1 ENOENT (No such file or directory)
<Kamion> and nothing else should be running at that point
<carlos> zyga, It depends on the package that you translate. Sometimes it is and others it's not. I think we have a bug report about that already
<zyga> carlos: msgid is displayed as  &lt;foo&gt; but the mgstr textarea contains <foo>
<carlos> zyga, URL?
<zyga> carlos: one moment please, I'm translating several things in paralell
<zyga> https://launchpad.net/distros/ubuntu/breezy/+sources/gaim/+pots/review-breezy-gaim-1/pl/+translate
<zyga> message number: 1105
<zyga> carlos: check the source of that fragment - i think that's clear now :)
<carlos> zyga, in general, please avoid to translate the review-* potemplates
<zyga> carlos: & is not escaped in msgstr
<zyga> msgid has: &amp; but msgstr has plain &
<carlos> zyga, which message number?
<zyga> :)
<zyga> 1105
<zyga> carlos: I'll file a bug if you say so
<carlos> I think there is already one
<carlos> look for it first, please
* carlos downloads the original .pot file to know where is the problem...
<zyga> checking
<Diziet> k: This is a weird `file goes missing between apt and dpkg' bug you've got ?
<zyga> carlos: no such bug reported
<Diziet> It did that to me too but I couldn't reproduce it.
<zyga> carlos: I was only checking open bugs
<carlos> hmm
<carlos> ok file a new one
<carlos> I will set it as duplicated
<carlos> with next bug triadge
<zyga> k
<zyga> carlos: did you managed do look the original msgstr up? I'd like to be sure
<carlos> zyga, yes, it's a bug 
<Kamion> Diziet: it's during installation, so I'm more inclined to blame something weird in base-config to start with
<carlos> zyga, the msgid is correct, the msgstr is not
<zyga> k, filing now
<Diziet> kamion: It happend to me in my hoary->breezy test upgrade.
<Kamion> it's very reproducible but unfortunately the test cycle is ~30mins
<Diziet> But only once.
<Kamion> it's the same set of files every time here
<jdub> http://wiki.xensource.com/xenwiki/CoolConfigurations
<jdub> lots of ubuntu ;)
<Kamion> almost as if something else is running apt in parallel
<Diziet> I ran apt-get dist-upgrade in an ssh session and it did that, first off, for linux-kernel-headers.
<tseng_> Kamion: can we sync monodoc 1.0.6-3 (new revison) from debian to fix file conflicts?
<tseng_> slomo: er, explain this to me again
<tseng_> slomo: its making new packages, and they conflict with the others with the same files?
<slomo> tseng_: our monodoc contains the gtk#, gecko, nunit docs in monodoc-manual...
<tseng_> yes.
<slomo> tseng_: the one in debian puts them into different packages which conflict on the 2.0 packages for these docs
<slomo> tseng_: otherwise you "can" install the 1.0 and 2.0 doc package and get an error because some files already exist
<tseng_> does 2.0 docs cover both?
<slomo> tseng_: no
<Kamion> tseng_: if the package split in -3 is OK and if you don't mind throwing away the Ubuntu changes, sure
<seb__> daniels: around?
<slomo> tseng_: but that can't be done better... bug in monodoc design
<tseng_> yep
<daniels> seb128: mmm?
<slomo> tseng_: sorry for beeing this short... i'm currently learning maths ;)
<tseng_> slomo: did you check the ubuntu diff?
<slomo> tseng_: no... will you or shall i?
<tseng_> can you please
<tseng_> im quite busy
<slomo> tseng_: me too ;) but i'll try
<tseng_> if it looks like we can drop it we can tell elmo that Kamion and I agree
<tseng_> slomo: i think my changes were just pulling stuff out of SVN and shipping it vs syncing an already-in-debian package
<seb128> daniels: I've reassigned this bug to you
<seb128> daniels: there is no dvorak mention from GNOME, and that's not the bug
<seb128> daniels: an another guy hijacked the bug with his borked xorg.conf part, but the applet is an user stuff and doesn't change xorg.conf
<Diziet> Aaargh!  Bloody awful patch buildsystems!  dpatch has buggered this source tree.
<slomo> tseng_: i don't know... you shipped a missing-files.tar ;)
<tseng_> it looks ok to drop to me
<slomo> dito
<tseng_> ill mail elmo
<tseng_> and then leave
<slomo> ok, fine :)
<tseng_> thanks.
<jdub> elmo: what are the chances of a valgrind sync?
<elmo> jdub: mdz's call?  it has one reverse build-depend, kdesomthing or other
<elmo> I suspect if someone confirmed kdesomethingorother still build with new valgrind, mdz would be more willing to consider it
<Mithrandir> Kamion: and it's not being caught by the "clean up archive-copier" stuff?
* Diziet throws it away and makes a new one.
<jdub> Riddell: ping
<Diziet> And why oh why does the default /etc/profile have umask 022 ?
<jdub> elmo: ta
<elmo> jdub: somethingorother == network, FWIW
<Kamion> Mithrandir: the trace comes after that
<Riddell> jdub: pong
<Mithrandir> Diziet: why shouldn't it?
<Kamion> last thing mentioning pptp-linux_ is the mv cleaning up /var/cache/archive-copier/ship/, yet that's gone missing too
<jdub> Riddell: reckon kdesomethingorother will work with new valgrind?
<daniels> seb128: dude, it's the gnome keyboard thingy that's setting his layout to dvorak
<Riddell> kcachegrind
<daniels> seb128: now, tbh, I don't know whether this is a list in gnome-applets or whether xk-c needs a kick up the arse, but it's certainly not xorg proper
<jdub> jbailey: do you want to own grub bugs?
<Riddell> jdub: I'll take a look now while I wait for qt to compile
<Riddell> don't see any reason why not
<jdub> Riddell: thanks
<Mithrandir> if we got newer valgrind, much happiness will ensue in the amd64 camp.
<jdub> Mithrandir: will you all be like \o/ ?
<Kamion> Mithrandir: oh my god, I think I just guessed what it is and it's horrible
<Kamion> Mithrandir: have a look at /etc/cron.daily/apt
<Mithrandir> jdub: it's "valgrind exists" vs "valgrind doesn't exist", so yes. :-)
<Mithrandir> Kamion: you're kidding me.
<Kamion> Mithrandir: cron.daily ran during my base-config run (from anacron)
<Mithrandir> ewwwww
<Kamion> I spy a smoking gun
<jdub> mdz: ross burton has asked for a sync of valgrind to more sanely debug gnome things that are affecting us, Riddell is checking if the reverse-depends works with it, and Mithrandir suggests the amd64 camp will have a debugging orgy if it goes in - your thoughts?
<Keybuk> ...and wiped your apt cache? :p
<Kamion> correct
<Kamion> well, partially
<Mithrandir> Kamion: that's utterly, utterly, utterly crack.  I guess I wasn't bitten because my machine was faster, or something.
<Kamion> I imagine it's something to do with age/size of the .debs
<Keybuk> isn't it a bit of a d'oh to be running cron during an install anyway? :)
* jdub wonders where he pulled reverse-depends...
<Mithrandir> jdub: apt-cache rdepends?
<Kamion> Keybuk: cron is configured by that stage - I don't see why it's actively bad
<Diziet> mith: umask> Shared filespaces and personal groups.  Surely you've been exposed to this argument before ?
<Kamion> yeah, I think it's deleting all .debs over 30 days old
<Mithrandir> Diziet: well, that's a point, but iirc sshd (among other things) will be really, really unhappy if you don't chmod g-w ~/.ssh and such.  It's easy enough to change for people who want that.
<Kamion> and since I use cp -a, the timestamp from the archive is preserved
<Kamion> Mithrandir: that's an sshd bug, I keep meaning to fix that
<jdub> Mithrandir: probably
<jdub> Mithrandir: more likely it was a brainfart
<Mithrandir> Kamion: how, really?
<Kamion> in fact I did fix some of that recently
<Mithrandir> Kamion: did you have your release blockers chat with mdz yesterday or is that for today?
<Diziet> mith: sshd should be fixed too.
<Kamion>   * Allow ~/.ssh/config to be group-writable, provided that the group in
<Kamion>     question contains only the file's owner (closes: #314347).
<mdz> morning
<Kamion> Mithrandir: yesterday
<Keybuk> morning Mr. Z
<Mithrandir> speak of the devil.  Hi mdz.
<Kamion> I couldn't convince upstream of the need for that sshd fix though
<daniels> christ, the east coast is waking up
<daniels> er, west cosat, even
<Diziet> -chiark:~> grep -i mode /etc/ssh/sshd_config
<Diziet> StrictModes no
<Mithrandir> daniels: quick, go to bed.
<daniels> oh whatever
<daniels> Mithrandir: yeah
<Diziet> It would be nice if you could say  StrictModeUmask 002
<Keybuk> so zsh gets upset if you run compinit twice
<Keybuk> which is somewhat odd, but hey
<jbailey> jdub: What do you mean? =)
<daniels> seb128: it's too late for me to think more about 14365 now
<jdub> jbailey: currently grub bugs go to debzilla
<jbailey> jdub: Is that Ubuntueze for /dev/null?
<jdub> /dev/muck
<Kamion> jbailey: close enough
<daniels> seb128: i'd say 'i think you're right', but I might regret it in the morning
<jbailey> jbailey: Given that I've known all of grub's upstream over its history, I'm probaby the most qualified for them.
<jbailey> 'want', might be too strong of a word. =)
<jbailey> But sure. =)
<jdub> now that you've convinced yourself
<jdub> convince me ;)
<Kamion> mdz: what's the best way to disable /etc/cron.daily/apt temporarily? I can think of at least four variously hacky ways
* jbailey puts on a short skirt, nylons, and bats his eyelashes at jdub.
<jdub> schwing!
<jbailey> jdub: I also already have a pile of grub bugs, more won't hurt. =)
<jbailey> ... much
<Keybuk> ok, figured it.  by running compinit in my zshrc after adding ~/.zsh to fpath so my _bzr function could be found ... it decides to bitch about the writableness of .zsh/_bzr and stamp all over .zcompdump when I run sudo
<Keybuk> which is odd, but hey
<Keybuk> replacing it with just compdef worked
<Keybuk> zsh is weird sometimes
<jdub> mjg59: so how'd you fix the colour?
<mjg59> jdub: Got a gimp palette from the picture, swapped the colours by hand, changed the picture to RGB and then reindexed it to the new palette
<mjg59> www.srcf.ucam.org/~mjg59/tmp/ubuntu.png
<wasabi> Can we animate that?
<wasabi> Ya know how OS X starts with the light screen, with only the little twirlly thing in the middle rotating colors?
<wasabi> I want to do that with the Ubuntu logo.
<wasabi> Have the brown shades rotate around.
<jbailey> y'mean make Mark, Matt and James dance in circles?
<wasabi> Totally.
<wasabi> Without shirts, no less.
<Keybuk> sorry, I'm veto'ing any attempt to get James topless
<zul> ditto
<jbailey> wasabi: Sounds like you have to appeal to the sabdfl or give it up. =)
<jdub> mjg59: what do you think about making the progress bar a ~5px line at the very bottom
<jdub> ?
<mjg59> jdub: Could do
<mjg59> For now I've just moved it below the logo
<Keybuk> that might look sexy, or it might not be obvious what's happening
<jdub> Keybuk: mmm
<jdub> plus it won't be at the edge on wacky screens anyway
<jdub> hard to use the edge for much
<Keybuk> indeed
<Keybuk> it floats in the middle on my old laptop as it is
<jdub> Keybuk: what do you think of the current artwork?
<Keybuk> I'd like a box around the bar, so you can tell how far it's going to go
<jdub> (latest usplash upload is the same, just a bit cleaner)
<Keybuk> other than that, I thought it was simple and elegant
<Keybuk> with slightly retro fonts that I found rather appealing
<jdub> or maybe a non-black background for the prog bar
<Keybuk> I didn't agree with puppy at all
<jdub> light beige on dark beige
<Keybuk> it has to be a black background
<jdub> i think a single line box will look a bit poxy
<Keybuk> possibly, if it were very dark brown
* jdub forgets what that bit of prog bars are calle
<jdub> d
<Keybuk> the queue can be almost subliminal, just as long as it gives the brain something to measure against
<jdub> trough?
<jdub> the slot bit
<Keybuk> if it was light on dark, it'd look a bit odd
<Keybuk> more like a moving shutter than a progress bar
<jdub> oh
<jdub> perhaps if we had a rounded box
<jdub> ala winxp ;)
<jdub> http://people.ubuntu.com/~jdub/2005/usplash/winxp-professional.jpg
<Mithrandir> which isn't a progress bar, just a moving thingie
<jdub> yeah, but look at the trough :)
<mirak> hi
<mirak> anyone is responsible of ppc kernel builds ?
<Keybuk> the trough is black
<mirak> otherwise b&w G3 won't boot because they will not initialise the ide harddrive
<mirak> hum sorry
<mirak> wrong paste
<jdub> Keybuk: "the rounded border around the trough"
<mirak> the cmd646 module must be built into the kernel, otherwise you can't boot on blue & white G3
<mirak> if the initrd is on the /dev/hdc, you can't boot
<daniels> seb__: also, hillarious metacity bug if you can reproduce
<mjg59> mirak: Hmm? Why?
<daniels> seb__: have your current command in the window title, and then run a REALLY long command
<Diziet> daniels: I just fixed up your broken gsfonts-x11 upload, FYI :-).
<daniels> seb__: you'll end up with all the text overlapping each other -- it looks like it wraps, but on to the same
<daniels> line
<daniels> Diziet: um, I uploaded gsfonts-x11?
<Diziet> gsfonts-x11 (0.17ubuntu1) breezy; urgency=low
<Diziet>  -- Daniel Stone <daniel.stone@ubuntu.com>  Thu, 30 Jun 2005 06:05:31 +1000
<Diziet> That's you, isn't it ?
* daniels blinks.  yeah.
<mirak> mjg59: because, the G3 avec two ide controlers, one for the harddrives, and one for the cdrom or other hard drive, zip whtaver
<daniels> Diziet: thanks, in any case
<Diziet> You changed the depth of the symlinks, but they were all relative so you should have changed the number of ../'s in them too.
<mirak> mjg59: if cmd646 is not built into the kernel, you won't get the root device, since it's on what the system is on
<Diziet> NP.  I just thought I should let you know.
<daniels> Diziet: cool
<mirak> mjg59: you won't get the initrd either
<mjg59> mirak: What does that have to do with whether it's in the initrd or not?
<mjg59> The kernel doesn't read the initrd off disk
<mjg59> The bootloader does
<mirak> mjg59: ok, so cmd646 is probably not into initrd as well
<mirak> I don't know but it doesn't work
<mjg59> mirak: Right. That sounds quite possible
<Kamion> Mithrandir: to be more exact, you have to be unlucky enough for cron.daily to run between update-notifier being configured and the end of pkgsel, I think
<Kamion> anyway, fixing now
<mjg59> mirak: The person to talk to is jbailey
<Kamion> that should deal with a lot of semi-unreproducible base-config bugs
<Mithrandir> Kamion: how are you fixing it?
<mirak> I forgot to say the problem is on breezy new kernels
<Keybuk> jdub: http://people.ubuntu.com/~scott/ubuntu-bar.png  is kinda what I was thinking
<Kamion> Mithrandir: sticking a bunch of stuff in /etc/apt/apt.conf.d/99base-config to effectively disable /etc/cron.daily/apt, and removing that file when I'm done
<slomo> Keybuk: looks nice :)
<mirak> jbailey: hey, are you there ?
<Kamion> fortunately update-notifier is only installed as part of desktop, which simplifies the problem somewhat
<Keybuk> you could probably use an even darker colour for the trough border too, it only needs to be subliminal
<Mithrandir> Kamion: evil
<Mithrandir> Kamion: but I guess it works.
<Kamion> all the other solutions I could think of were worse
<Kamion> this at least doesn't involve mucking around with other packages' files
<jdub> Keybuk: gotcha
<Diziet> kamion: Can't we fix the cron.daily/apt to look at the ctime too ?
<Kamion> Diziet: I have to disable it anyway; I don't want it to do an apt-get update run in the middle of the installation
<Kamion> with hindsight, that explains other bugs
<Diziet> apt-get update>   Urgh!
<Diziet> But it should definitely be fixed not to look at the ctime.
<Diziet> (as well)
<Diziet> I mean, _to_ look at the ctime.
<Kamion> mm, yes, I agree
* Kamion goes to file a bug
<Mithrandir> hm, I should look at the Xen d-i integration stuff tomorrow or so.
<Lathiat_> mjg59: sweet, my laptop lcd actually turns off now, however
<Lathiat_> mjg59: i have to move the mouse to bring it back on
<Lathiat_> mjg59: known?>
<Lathiat_> mjg59: (when i open the lid, it should pop up straight away me thinks)
<Amaranth> should it?
<Amaranth> i don't think windows does that
<Lathiat_> i think it should
<Lathiat_> if i open my lid
<Lathiat_> i more than likely want to use my laptop
<Lathiat_> so the screen should turn back on
<Lathiat_> it used to
<Kamion> Lathiat_: it gets bad on laptops with faulty lids ...
<Lathiat_> Kamion: ah
<Kamion> dunno if that's the reason though
<Lathiat_> be nice if it was at least an option then
<Lathiat_> but i can see the reasoning there
<Lathiat_> tho those laptops suck
<Lathiat_> ;p
<Kamion> in my case it's not so much due to the laptop sucking as it is due to a small child knocking the laptop off the desk and it incurring a four-foot drop onto the floor
<Kamion> quite impressed it survived otherwise unscathed actually
<mjg59> Lathiat_: Uh. In what situation?
<Lathiat_> mjg59: opening my laptop lid
<Lathiat_> the screen stays (presumably dpms) off
<Lathiat_> turns on as soon as i move the mouse or whatever
<Treenaks> Kamion: http://www.atoker.com/tmp/protection.png
<Lathiat_> Treenaks: :)
<mjg59> Lathiat_: Sounds like we're not getting a lid event when you open the lid
<Lathiat_> mjg59: oh?
<Lathiat_> mjg59: thats quite possible actually i used to have problems with it not vtswitching back
<CarlFK> Kamion - what is the preseed line I need to select a dictionary?
<Lathiat_> how do i debug that?
<Lathiat_> (sometimes it worked, sometimes it didnt
<Kamion> CarlFK: that question isn't supposed to be asked; it will be suppressed
<Kamion> Treenaks: heh
<CarlFK> Kamion - ok, Ill keep hitting enter
<mjg59> Lathiat_: Easiest way is to check /var/log/acpid
<mjg59> It'll log each event it handles
<Kamion> CarlFK: but look at the wamerican/wbritish .config scripts and you should be able to work it out
<ogra> Treenaks, i didnt know you had a SoC project :)
<Treenaks> ogra: I don't... just repasting links :)
<ogra> hehe
<CarlFK> hitting enter a few times sounds easier ;)
<ogra> Treenaks, i know :)
<Lathiat_> mjg59: hrm, it seems to
<Lathiat_> nto quite sure whats what really
<Treenaks> Kamion: have you seen #14007 (WEP/restricted mode b0rkage in installer)
<Lathiat_> but it seems to execute lid.sh twice
<Lathiat_> due to the lid button
<Kamion> Treenaks: yes
<Treenaks> Kamion: ok :)
<Chipzz> hi... sorry for asking this, I tried a while ago on #ubuntu, nut no-one could answer my question there... I have been running breezy since hoary was released, but somehow I'm missing the splash-screen image file... can anyone tell me what package generates it? I have checked packages.ubuntu.com, but no success
<CarlFK> Chipzz - figure out what isn't doing what it should be and file a bug report
<Chipzz> CarlFK: that is /exactly/ the problem - I do not know against which package to file a bug
<Chipzz> the boot splash image is .xpm.gz file somewhere in /boot, so I suppose it is actually generated
<CarlFK> if onone answers, take a guess.  it will get corrected.
<jdub> Chipzz: it's compiled into usplash
<jdub> we're not using evil bootsplash at all
<Chipzz> jdub: dunnow what exactly is used
<ryanthiessen> Chipzz, instructions here: http://lists.ubuntu.com/archives/ubuntu-devel/2005-August/010208.html
* Riddell hopes the usplash image can be changed for different ubuntu variants
<Chipzz> ryanthiessen: thx a lot!!! :)
<jdub> Riddell: it is slightly challenging, requiring a usplash rebuild at this stage
<jdub> Riddell: have you redone the kubuntu logo with the new ubuntu font (particularly the k)?
<Riddell> jdub: didn't even know there was a new font
<Riddell> jdub: where to find it?
<jdub> Riddell: apt-get install ttf-ubuntu-title
<Chipzz> ryanthiessen: hmmm, I have apt-get installed usplash, lsb-base and initramfs-tools are up to date, but it still cant find an image :/
<Chipzz> root@Vertex:~ # dpkg-reconfigure linux-image-2.6.12-7-686
<Chipzz> ...
<Chipzz> Searching for splash image... none found, skipping...
<jdub> Chipzz: run mkinitramfs -o /boot/initrd...<yourkernelversion>
<jdub> Chipzz: there is no separate image file
* Chipzz reads usplash readme
<jdub> Chipzz: i believe that reference is from grub
<Riddell> jdub: new valgrind looks fine, kcachegrind uses callgrind which doesn't like valgrind 3 but debian doesn't pacakge callgrind so it's no loss.  and the kdesdk-scripts rdepend is fine
<jdub> Riddell: tops
<Chipzz> /usr/share/initramfs-tools/hooks/usplash > that would explain
<jdub> mdz: approval for valgrind sync?
<Chipzz> jdub: it is
<Chipzz> hmmm... no luck... still no splash image found
<mjg59> Lathiat_: You get two lid events, one on close and one on open?
<Chipzz> ow wait
<Riddell> jdub: is there actually any difference in that font?
<ryanthiessen> Chipzz: that splash image refers to grub, not usplash
<Chipzz> ryanthiessen: yes, but that was exactly my question... I don't have /boot/grub/splash.xpm.gz ... so what package takes care of installing that file?
<Keybuk> hmm, random
<Keybuk> should we change the grub image to be like the usplash one?
<lamont> seb__: aroudn?
<Chipzz> hmm lemme reboot to check
<Chipzz> BBIAB
<jdub> Riddell: yes, quite substantial
<jdub> Keybuk: i'm actually playing with that now :)(
<jdub> Chipzz: nothing installs that file
<Chipzz> so how does it get there?
<jdub> it doesn't
* Keybuk checks out the new usplash
* lamont has a question for mdz when he gets bored..
<jdub> we don't ship a grub splash
<lamont> infinity: you awake?
<Chipzz> so that message actually doesn't relate to the boot splash?
<ryanthiessen> Chipzz: if you want one, download one or make one and put it there :-)
<jdub> Chipzz: not at all, that's what i said :)
<Chipzz> fsck
<Chipzz> firefox just crashed on me :P
<Chipzz> ah well
<jbailey> I didn't think we did a grub image on Breezy install...
<jbailey> Seems like it just risks complicateing serial setups.
<jbailey> Or console over ethernet
<jdub> we don't
<Mitario> mako, ping
<lamont> jdub: how much do you know about cairo vs glitz and what should/shouldn't need libglitz to build?
<Chipzz> the boot splash worked :)
<Chipzz> very nice :)
<jdub> lamont: nothing should use libglitz to build at this stage
<lamont> sigh
<Chipzz> thx people! :)
<jdub> it's way sassy
<jdub> it has the sass
<pitti> bah, daniels completely broke my X :-(
<Keybuk> well, that totally barried the world
<bddebian> barried?
<Keybuk> yes
<Keybuk> network wouldn't work, then gdm wouldn't start
<jbailey> bddebian: It's okay.  Hey means "Barri", not "Barry".  We're still not out to get you. ;)
<bddebian> You mean buried?
* jbailey hides.
<bddebian> heh
<Keybuk> no, barried
<ogra> *g*
<Keybuk> gone the way of the Barry
<bddebian> doh
<pitti> jbailey: may I humbly ask again for the plan of the libc update? we getting damn close to freezes now...
<Keybuk> it's a British thing
<jbailey> pitti: Today, if possible.
<bddebian> Barry is bad?
<pitti> jbailey: ah, good
<jbailey> pitti: I got involved in some docteam stuff which is also due in about the same timeframe. =)
<Keybuk> http://www.urbandictionary.com/define.php?term=barried
<bddebian> Wow: barry: Someone who reeks of awesomeness.
<jbailey> bddebian: I's also a joint of marijuana. =)
<bddebian> Aye :-)
<bddebian> Damn now I really feel unworthy.  I can't even live up to my own name :-)
<jbailey> We'll wrap you in cigarette paper for Hallowe'en...  That way I won't be the only one dressed up at UBZ. =)
<Keybuk> what you dressing up as?
* Keybuk is always up for dressing up
<jbailey> Keybuk: Dunno yet.  It's about the range where I shold probably start thinking about it, though.
<jbailey> It's really annoying to try and pick the morning of the 31st.
<Keybuk> hehe
<Keybuk> depends on the form for dressing up
<Keybuk> some of the stuff I own wouldn't make it through customs
<jbailey> Coming into Canada, or returning home?
<Keybuk> yes
<jbailey> Canadian customs folks aren't that picky unless you've got things made from endangered species.
<sivang> jbailey: lol
<jbailey> *US* customs, you have a much greater risk of 'crimes of moral turpitude' or some such like that.
<Keybuk> hehe
<Keybuk> That's used for WHAT?! :p
* sivang is going to watch the original 1981 hitchhiker's guide series adapted from BBC audioscripts. ROCK! :)
<sivang> jbailey: that terminal problem still hasn't been resovled, right?
<sivang> I am still getting this on my irssi terminal
<jbailey> sivang: Terminal problem?
<jbailey> "I'm not dead yet!"
<sivang> jbailey: you recall that irssi terminal screen erasing it self with blue background?
<jbailey> Ah, yes.  that still occurs.
<sivang> jbailey: anyway, I have to run again :-(
<sivang> see you all tommorrow
<bddebian> Later sivang
<bddebian> jbailey: And you wonder why I have a complex ;-P
<jbailey> =)
<jdub> hrm, i don't have maila ccess atm
<jdub> can someone mail ubuntu-uk and sounder with this?
<jdub> http://linuxworldexpo.co.uk/content/view/37/77/
<jdub> ^ would be good to have an ubuntu stand in the .org
<jdub> Keybuk: ping?
<Keybuk> jdub: pog
<jdub> n/m, i can post
<Keybuk> we're so far ahead of you, we're practically IN THE FUTURE
<Keybuk> there's no room in the .org stand
<jdub> oh
<Keybuk> Jane confused matters by trying to talk to the organisers, who want us to have a ker-$$$ stand instead
<jdub> oh
<jdub> JANE!
<Keybuk> we might be able to stick a bloke in an Ubuntu t-shirt on the end of the Debian stand
<jdub> Keybuk: gnome stand is always a fair shot too
<Keybuk> yeah
<jdub> helps if you're me
<Keybuk> actually, Brian hasn't got back to me yet, I should beat him up :p
<jdub> ;-)
<Keybuk> you've not met Brian Teeman have you?  he's a cool guy; does the .org pavilion every year
<jdub> nup
<Mithrandir> hmm, october 5th to 6th.
<jdub> funny, if i arranged my travel slightly differently, i could've come :)
<Keybuk> does remind me that we need to ring the nice lady at the Amsterdam House again
<Keybuk> she usually does us a very good deal
* jdub is itching to run xen on his lappy
<Keybuk> why?
<elmo> it's shiny
<Keybuk> for those who spend all day at home polishing it?
<Mithrandir> does there exist any other reason to do stuff than shinyness?
<elmo> Mithrandir: the other kind of shiny.  $$$
<zul> Mithrandir: because its 3l33t
<Keybuk> you can't talk, multi-arch-boy ;)
<slomo> elmo: did you already read my query?
<edwarddes> if your looking to run xen on your laptop, see the announcement on ubuntu-devel maining list about my summer of code work
<jdub> edwarddes: i did, and it's making me itch!
<elmo> slomo: eh, pls mail me, I'm busy now and this doesn't look simple or obvious
<jdub> unfortunately, i have a policy of only running ubuntu-shipped kernels
<slomo> elmo: ok, will do
<edwarddes> you may run into issues using the basic kernel configs i provided with laptop hardware
<jdub> well, more an oath than a policy
<edwarddes> oh, well, if it makes you happier, im working on a more ubuntuish kernel config to ship with it
<jdub> it's not really possible to build xen modules separately, is it?
<mdz> lamont: ?
<elmo> jdub: no
<elmo> or more to the point, you need to patch the kernel regardless
<Mithrandir> jdub: it's not a module.
<edwarddes> no, it modifies a bunch of the i386 arch stuff
<Mithrandir> edwarddes: which kernel version have you based it on?
<jdub> will there be a day when all kernels are xenabled?
<jdub> or are there good reasons to pick and choose
<jdub> ?
<edwarddes> people are working on merging the xen patches into the mainline kernel tree
<Mithrandir> jdub: which is why I think the work done by benno is really nice.  It requires a minimal patch to the kernel and gives you the same performance as Xen.
<edwarddes> but you cant have a kernel that will run on native hardware and one that will run on the xen hypervisor
<jdub> Mithrandir: hmm. i should check up on what he's doing
<jdub> Mithrandir: will be intersting for breezy+1
<edwarddes> but once the xen support is in all the kernel releases, it would be simple to modify the ubuntu kernel config and just rebuild with xen
<Mithrandir> jdub: http://l4ka.org/projects/virtualization/afterburn/
<wasabi> So has anybody actually used Xen to boot windows or are teh mods to extensive to do?
<wasabi> without source etc 
<edwarddes> with the new VT-x or pacifica extensions that will be availible soon from intel and amd it will work
<Mithrandir> wasabi: the mods aren't redistributable.
<wasabi> Ahh.
<wasabi> So I can find them, somewhere. ;)
<edwarddes> they facilitate full virtualization at a hardware level
<wasabi> Awesome.
<wasabi> Can't wait.
<pitti> To continue, enter "Ja"; to abort, enter "Nein": Ja
<pitti> bah, that looks *so* ugly
<pitti> yay partial l10n
<ogra> pitti, not for your granny ;)
<ogra> at least you get that its asking for Ja or Nein even if you dont understand english :)
<pitti> yes, and granny won't have a clue what is the correct answer...
<bddebian> heh
<ogra> ;)
<slomo> elmo: sent the mail... when you have further questions just ask here :)
<Mithrandir> ogra: luma upstream is asking if we can sync from Debian.  It should be safe, according to him.
<Mithrandir> ogra: (it's a merge, 'cause of the python version.), but would you mind?
<ogra> anything that depends on it ?
<Mithrandir> python-smbpasswd, it seems
<ogra> i.e. anything that could break or cause extra work ?
<Mithrandir> it's just a recommends, not a depends
<Mithrandir> so I doubt it
<ogra> go for it :)
<Mithrandir> willdo
<kayfelix> hey people. I have a sound problem. Everything is there, running, looking peachy... but no sound. System beep works over the speakers though, so im pretty sure HW is all setup and working. Its an AC'97 Realtek onboard soundcard on an ASROCK K7S41GX mainboard, im running kubuntu and to be honest, am completely at a loss as to what to do next.
* ivoks likes new screensaver lock :)
* bur[n] er likes the new usplash :)
<ivoks> that too :)
<ogra> :)
<ivoks> if only nvidia would open source it's drivers :)
<ivoks> you know there is a bounty 30.000$
<ivoks> for person that will make nvidia driver S3 suspend and bring it back to life
<bddebian> Heya Seveas
<Seveas> hi barry
<mpt> npnufn
<ivoks> mpt: bad day? :)
<mpt> ivoks: No, I just noticed that word in the splash screen :-)
<mpt> ubuntu
<mpt> npnufn
<ryanthiessen> ha!
<ivoks> :)
<chmj> mpt: that ubuntu when you read it upside down
<bddebian> Apparently you people don't have enough to do. ;-P
<lamont> hrm... so all these i386 packages that have libglitz.la in their .la files, but no Depends: libglitz1-dev, I can do -build uploads of without anyone screaming, yes?
#ubuntu-devel 2005-09-07
<jbailey> I seem to be able to resolve www.ubuntu.com, but not archive.ubuntu.com, anyone else seeing this
<jbailey> ?
<lllmanulll> Works with me
<lllmanulll> tiramisu ~/icons>ping archive.ubuntu.com
<lllmanulll> PING archive.ubuntu.com (82.211.81.151) 56(84) bytes of data.
<lllmanulll> 64 bytes from 82.211.81.151: icmp_seq=1 ttl=48 time=45.7 ms
<lllmanulll> 64 bytes from 82.211.81.151: icmp_seq=2 ttl=48 time=44.3 ms
<lllmanulll> --- archive.ubuntu.com ping statistics ---
<lllmanulll> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
<lllmanulll> rtt min/avg/max/mdev = 44.316/45.025/45.734/0.709 ms
<lllmanulll> tiramisu ~/icons>
<jbailey> Thanks, seems to work now.  Weird.
<mpt> lllmanulll unclogged it
<lllmanulll> Right :)
<lllmanulll> Hey, anybody knows what's up with the Google's Summer of Code project ?
<lllmanulll> I've been trying to contact seb128 all day, but he's unreachable
<mpt> lllmanulll: seb128 was here until 8 hours ago
<ajmitch> morning
<mpt> timezone problems, perhaps
<lllmanulll> Well, he came online a few times, but didn't respond to my /query
<lllmanulll> And we're on the same timezone
<lllmanulll> Anyway, nevermind :)
<Kamion> perhaps try mail instead
<zul> is the wiki down?
<elmo> works for me?
<zul> hmm....that sucks
<mjg59> WORKSFORME NOTABUG
<Burgundavia> zul, others have been reporting issues with the wiki
<sladen> gah, why do I have too many channels?
<WaterSevenUb> mvo, synaptic didn't make it yet into Rosetta?:)
<lamont> mdz: I have a list of libglitz.la depending packages that I need to discuss with seb128, and then probably upload a few of them for rebuilds to finish that transition completely
<lamont> just as an oh-by-the-way
<lamont> (sadly, gcc-4.0 and gimp appear to be on that list - hence my need to talk with seb128 before I go fixing things..)
<lamont> mdz/seb128: specifically, the following packages (in at least 1 of the 3 architectures) have /usr/lib/*.la files which contain the string "libglitz.la", but do not Depend on any libglitz package:
<lamont> dia-newcanvas gcc-4.0 gcompris gimp gtkgl2 gtkglext libctk libquicktime libsigcx somaplayer
<lllmanulll> Lots of people need seb128 now :)
<lamont> lllmanulll: well, truthfully speaking, I could just upload -build kicks of all of those (and it's possible that I will need to), but I'd like to check first.
* dereks needs seb128 :)
<lamont> queue forms to the left. :-)
<dereks> lamont: haha
<lllmanulll> hehe, I guess he's sleeping, and will come back in about 6 hours ? :)
<lamont> sounds about right
<lllmanulll> But he's my 'mentor' for the Google 'Summer of Code' program, which deadline is about... huh... right now
<bddebian> Doh
<lllmanulll> Couldn't get to him for the whole day, must have been pretty busy
<dereks> lllmanulll: what was your project?
<lllmanulll> dereks, "Gnome panel enhancements"
<lllmanulll> https://wiki.ubuntu.com/GnomePanelEnhancementsIdeas
<ryanthiessen> lllmanulll: looks great
<lllmanulll> ryanthiessen, Thanks :)
<ryanthiessen> it's a small thing compared to the rest of what you did, but I'm quite looking forward to the separator :-)
<lllmanulll> Ah :)
<lllmanulll> Unfortunately, I don't think it will make it for breezy
<ryanthiessen> d'oh
<lllmanulll> Well, I guess it's up to seb128 :)
<lllmanulll> But the freeze are already passed, aren't they ?
<lllmanulll> s/freeze/freezes
<ryanthiessen> so much of the great SoC projects didn't make breezy :-(
<lllmanulll> Right... The freezes were a bit early
<lllmanulll> But breezy++ will be even better :)
<ryanthiessen> it's going to just miss firefox 1.5 too, I imagine there will be a lot of people using backports
<lllmanulll> Well, I need some sleep now (4:42 am here)  :)
<ryanthiessen> g'night 
<lllmanulll> If seb128 comes back, tell him I desperately need him :-p
<lllmanulll> Good night :)
<jsgotangco> mm?
<jsgotangco> we have firefox 1.0.6
<jbailey> Are newer firefox revisions really adding that much that people are desperate to get them?
<ajmitch> new shiny things
<xhaker> jbailey, check the ff roadmap
<xhaker> but i wouldn't say desperate.. but if breezy ships with 1.5 then it has 100+ points.. heh
<xhaker> has=would have
<jsgotangco> we have a freeze schedule
<ajmitch> xhaker: rather unlikely, I'd say
<jsgotangco> not a good idea to go against it
<xhaker> i'm not the one bringing this up
<xhaker> i've just given my opinion
<jbailey> xhaker: I've always found the firefox plans a bit weak,  since they say things like 'feature complete', witout providing a URL to the list of features. =)
<xhaker> jbailey, i think they've improved a bit now, with this deer park 
<xhaker> should i call it approach?
<jbailey> Ah, cool.
<ryanthiessen> jbailey: the feature I'd like most is that the dialog box popups are replaced by error pages -- but I'm not arguing against the freeze
<xhaker> they look like they care now
<jbailey> Cool.
<jbailey> I have to admit to using ephy, so it's alwyas the core bits that I want.
<jbailey> And I've been pining for useful svg for years, another few months won't hurt me. =)
<xhaker> not only that, the new engine, the svg support, the fixed back/forward behavior.. to name a few 
<ryanthiessen> jbailey: I use ephy too -- and when it's built against ff1.5 it will get that feature too :-)
<lamont> jdub: you awake?
<xhaker> ryanthiessen, you can have the error pages now, just have to edit some wierd key
<jbailey> lamont: He was at like 2pm our time.
<jbailey> rebooting, justasec
<jdub> lamont: i am now!
<jdub> lamont: thanks very much!
<lamont> jdub: ??
<jdub> lamont: was a lovely dream about fountains and meadows!
<jdub> and WATERFALLS!
<jdub> AND THEN YOU COME AND WAKE ME UP!
<lamont> what - computer beeps and wakes you up???
<jdub> heh
<jdub> no
<lamont> you should mute that when you sleep...
<jdub> i am just having a morning hate
<lamont> heh
* lamont was working at bludgeoning some creul hacks in, involving breezy-changes...
<lamont> but I should be able to subscribe the hacky-address
<lamont> success. :-)
<ryanthiessen> xhaker: do you recall what that key is?
<xhaker> browser.xul.error_pages.enabled
<xhaker> set to true
<ryanthiessen> thanks!
<xhaker> the only gripe i have with it is that the address changes in the editbox
<xhaker> try it and you'll see what i mean
* lamont -> home
<xhaker> haha, ryanthiessen i have just discovered another way :P
<ryanthiessen> xhaker: you mean the address bar?  it's not doing that for me right now...
<xhaker> it used to
<xhaker> i didn't enable it before because of that
<xhaker> i'm trying out tor.. and it spits out a nice 403 page in the browser too :P
<wasabi> jdub: nm rewriting resolv.conf sucks because it also overwrites nameservers added by VPNs. THAT"S WHY. I had forgotten my real reason earlier. ;)
<jbailey> wasabi: C'mon, tell us how you really feel. =)
<wasabi> Haha.
<wasabi> I had just brought up how that annoyed me a few days ago, but I couldn't remember WHY
<jbailey> It also would toast any other resolv options that folks wanted in there by hand.
<jdub> wasabi: the whole point of NM rewriting resolv.conf and using bind is to handle complex situations like internet+VPN name resolution
<wasabi> Well, that doesn't work, right now, because VPNs don't yet play nice. =/
<wasabi> Or do they and mine is just broke?
<jdub> mmm, hopefully soon there'll be better support for static profile configuration and things like openvpn
<jdub> indeed, it could be very soon if you wrote it! :)
<wasabi> RIght now I use pon, it uses resolvconf
<wasabi> so it merges with my existing config.
<wasabi> ANd it works great, until nm clobbers resolvconf
<jdub> and NM is *intended* to be a whole new world
<jdub> you could either:
<jdub> a) add better support for static profiles
<jdub> b) add support for whatever vpn software you're using
<wasabi> What are the deficienes with resolvconf, so I can think NM is better?
<wasabi> deficiencies.
<jdub> resolv.conf won't let you use different DNS servers for different networks
<wasabi> I mean resolvconf without the .
<jdub> it's mostly irrelevant
<wasabi> Oh?
<jbailey> jdub: Err..  Are you planning on chewing on glibc's resolver code with this?
<jdub> jbailey: hrm?
<wasabi> So... I know you might think this is silly.
<wasabi> But can bind start on !53?
<jbailey> Perhaps you mean something different by that.  I interpreted what yousaid as "I have two interfaces, ppp0 to the Internet, and eth0 to my local lan.  I can refer traffice for ppp0 to an external nameserver, and traffic for eth0 to an internal nameserver based on routing"
<wasabi> And can glibc know of it?
<wasabi> I realize bind is a much better resolver engine than plain ol resolv.conf
<jdub> jbailey: yeah
<wasabi> But I do run some local copies of bind for test configs and stuff.
<bob2> wasabi: why? bind it to localhost.
<jdub> (which is what NM does with it)
<wasabi> Yes, but I run my own copy of bind.
<wasabi> Sometimes. For development stuff.
<jdub> sudo netstat -pan | grep $(pidof named)
<wasabi> I guess I could run my own copy on !localhost heh
<bob2> yeah
<jdub> wasabi: make a new lo on 127.0.0.2 :-)
<wasabi> oh!
<wasabi> Hah! 
<wasabi> Great idea!
<wasabi> Thinking outside the box!
<bob2> haha
<wasabi> Such a crazy concept never occured to me.
<bob2> good thing they gave a whole /8 to loopback
<jdub> Kamion: ping
<wasabi> I don't think I have ever considered making a new lo for anything ever.
<wasabi> I have no complaints now.
<wasabi> Carry on.
<wasabi> jbailey: man-di has sort of taken over Eclipse and I'm letting him, in Debian anyways. He's sorta working on it a lot now, and I just don't have time.
<wasabi> Soon as he gets his feature complete with mine, and breezy is out, i'll sync it.
<jdub> sometimes it is painful watching technology changes in progress, NM is a rough one
<wasabi> Work is just kicking my ass.
<wasabi> Wonder if I can make NM run on .2 heh
<wasabi> brb
<xhaker> wonder if NM should always run on .2
<hub> ghawd
<hub> I have to repatch pmount
<hub> I hate filenames in uppercase
<jsgotangco> what the heck i see jdub, bob2 and chmj  in the xscreensaver prompt
* lamont looks around for someone with stock hoary system who is willing to test something for him
<lamont> specifically, my fix for 14130
<Burgundavia> lamont, I have one
<lamont> Burgundavia: wget http://people.ubuntu.com/~lamont/postfix_2.2.4-1ubuntu2 and install it - it shouldn't ask you any questions
<lamont> (this is assuming that you haven't mucked with debconf priorities, and that you still have the hoary version of postfix installed beforehand)
<Burgundavia> lamont, I have a pure hoary install, just a sec
<lamont> cool... if it does ask for mailer type, then I'll go ahead and make myself a fresh install to play with
<Burgundavia> lamont, getting a 404
<lamont> gah
<lamont> Burgundavia: wget http://people.ubuntu.com/~lamont/postfix_2.2.4-1ubuntu2_i386.deb
<lamont> :-(
<lamont> daniels: imlib+png2 build says: In file included from cache.c:5:
<lamont> gdk_imlib_private.h:104: error: syntax error before 'XShmSegmentInfo'
* Burgundavia curses his isp
<lamont> p.u.c/~lamont/buildLogs/Test/i/imlib+png2/1.9.14-16.2ubuntu2/imlib+png2_1.9.14-16.2ubuntu2_20050901-1255-i386-failed.gz 
<jsgotangco> lamont, installed
<jsgotangco> i get a postfix configuration
<lamont> jsgotangco: you got a question?
<lamont> sigh
<lamont> well, that's something for my list tomorrow then
<jsgotangco> yep postfix configuration screen
<lamont> grumble
<jdub> at least one of the gtk2hs guys uses ubuntu :-)
<jdub> http://www.haskell.org/gtk2hs/gallery/Cairo-demo/Cairo_demo_8
<jdub> (the dude doing cool cairo work!)
<whiprush> rock
<whiprush> </jdub>
* whiprush blogs angry.
<whiprush> jdub: I think mjg59 is a bad influence on me.
* ajmitch takes a look at whiprush's blog
<jsgotangco> pretty long blog for anger
<whiprush> yeah
<whiprush> ok, so feel good story of the day, I showed my boss the new usplash stuff.
<whiprush> And he was like "feel free to not get charged vacation time for your next ubuntu trip."
<whiprush> schwing!
<jsgotangco> heh
<jdub> whiprush: woo!
<jdub> whiprush: "oh, by the way boss, THAT'LL BE IN OCTOBER! THANKS!"
<jsgotangco> jdub, you are so prominent on the xscreensaver prompt heh
* ajmitch really has to see this new xscreensaver crack
* Burgundavia runs gnome-screensaver
<whiprush> me too.
<whiprush> I thought g-s was the default until I did a fresh install the other day
<Burgundavia> xscreensaver is so 90's
<jsgotangco> this was during the smackdown at the hotel
<jsgotangco> everyone was kinda drunk already
<whiprush> then I realized I had switched to it previously.
<Burgundavia> whiprush, I hear rumours of it being default for .14
<whiprush> I would welcome that.
<jdub> jsgotangco: scary.
<Burgundavia> along with g-p-m and fusa
<whiprush> Burgundavia: oooh oooh, NetworkManager too
<whiprush> by then it should be in great shape
* ajmitch hopes that NM is nice & shiny by then
<jsgotangco> "someone else" doesn't jive
<Burgundavia> ya
<jsgotangco> "login as a new user" perhaps?
<whiprush> I hate the lull periods before a release. It tends to make you go "ooh, +1 will just be so awesome."
<jsgotangco> well that's the time people clean up
<jsgotangco> for end users they just wait...
<Burgundavia> oh god xscreensaver is a cludge
<whiprush> jdub: so apprently calvin@novell is converting his desktop to ubuntu so they can provide ifolder packages.
<Burgundavia> whiprush, you serious?
<whiprush> yep.
<Burgundavia> nice
<jsgotangco> ifolder crack
* Burgundavia watches Novell convert to Ubuntu is 2 years
<whiprush> I was surprised to find quite an iFolder
<whiprush> presence on the ubuntu site.  I'm hoping to build packages for all of
<whiprush> our stuff and place them on our web site so people can just add it to
<whiprush> their apt sources.
<jdub> whiprush: like most of the rest of them ;)
<whiprush> yeah
<whiprush> I hung out with one of their hula interns, at boston they can run whatever they want
<jdub> we should invite him to join MOTU instead of maintaining a separate repo
<Mithrandir> whiprush: we should MOTUise him, yes
<whiprush> apparently ubuntu is the overwhelming favorite.
<whiprush> I believe Martin has been corresponding with them over email.
<whiprush> I'm idling in #ifolder, I will mention it to calvin soon.
<jsgotangco> Mez did the backport right?
<whiprush> No
<whiprush> It's a pain right now
<jsgotangco> ahh
<whiprush> they're working on making it more better repackageable though.
<whiprush> For one, their simple server is now a seperate package, etc.
<whiprush> which would open the whole thing up for easy deployment, right now you have to build the server out of cvs, etc.
<Burgundavia> the other thing that could use some repackagable love is banshee
<whiprush> well, they've patched stuff up to make it easier to build in ubuntu
<ajmitch> Burgundavia: tseng is on it
<whiprush> they're really receptive to us at the moment
<whiprush> tseng is all over it
<ajmitch> Burgundavia: don't worry, the mono team is rocking at the moment
<Burgundavia> ajmitch, cool. Muine is pissing me off right now
<Mithrandir> is iFolder stuff going to be in breezy (universe)?
<ajmitch> Burgundavia: tell me your problems..
<whiprush> I kind of feel bad for them, right now it seems that our users are more receptive to their projects than the opensuse community
<ajmitch> Mithrandir: could be, if it's ready & we get an exception for it
<Mithrandir> ajmitch: well, if nothing depends on it, it's an easy exception. :-)
<whiprush> Mithrandir: it's a bitch to build, you'll have to ask tseng. I'm not holding my breath
<Burgundavia> ajmitch, the notification area control causes muine is sef fault
<ajmitch> Mithrandir: yeah, we've got some freeze policies for universe though
<ajmitch> Burgundavia: ok, amd64?
<Burgundavia> ajmitch, i386
<ajmitch> hm, filed a bug on it?
<ajmitch> sadly most of the mono apps got demoted to universe due to various reasons
<Burgundavia> ajmitch, not yet. I didn't get very good feedback from tseng about bug filing on muine. I think he also dislikes Malone
<ajmitch> he doesn't like the unreproducible bugs 
<ajmitch> I'll also watch muine bugs, though
<Burgundavia> I need to test on my fresh breezy install box
<ajmitch> right
<Burgundavia> then I will file
* ajmitch needs to burn a breezy install disc
<Burgundavia> but I cannot get my laptop online at home, due to my ISP
<HrdwrBoB> due to your ISP?
<ajmitch> that's unfortunate
<whiprush> jdub: so ... large appliances that cool things. Update?
<jdub> working on it
* ajmitch is using the laptop at the moment, albeit in XP :)
<Burgundavia> MAC acdy restirction, only 2 machines get real address. I am too broke to buy a router
<whiprush> cool.
<ajmitch> Burgundavia: we'll have to ship you one
<ajmitch> :)
<Burgundavia> only have a hub right now
<ajmitch> the other boxes are running linux?
* Burgundavia is now working, so being broke will go away soon
<Burgundavia> yes
<Burgundavia> I really should set up my desktop box to be a router, but meh
<ajmitch> why not play the one-armed router hack, and use NAT?
<Mithrandir> or just do MAC spoofing
<Burgundavia> laziness
<ajmitch> or better, have 2 NICs in the box
<tepsipakki> argh.. why oh why does wlan-modules get loaded before wired ones..
<Burgundavia> and I don't know where my extra NICs are
<ajmitch> hm, using my camera as usb mass storage device doesn't work when its battery is flat, what a pain 
<pitti> Morning
<ajmitch> hey pitti 
<ajmitch> how are you?
<jbailey> pitti: Hey..
<jbailey> pitti: Your update actually even works better than the previous one =)
<jbailey> pitti: A number of strings that weren't showing up localised before now are =)
<whiprush> pitti!
<pitti> Hi ajmitch 
<pitti> ajmitch: great, thanks! :-)
<pitti> jbailey: wow, that's really unexpected... :-)
<pitti> hi whiprush 
* pitti feels really welcomed
<jbailey> pitti: I thought it might be. =)
<pitti> Hi daniels! Just replied to the X breakage mail
<carstenh_> morning pitti
<pitti> Hi carstenh_ 
<pitti> carstenh_: do you have fire for me? :-)
<carstenh_> pitti: not yet, after the breakfast :)
<whiprush> jdub: volvoguy is local to me and I just caught up on their list; if they need hosting then I've jsut mailed him offering unlimited hosting for whatever they need.
<whiprush> hmm, has the art team been that hard up for hosting?
<jdub> nup
<jdub> they seem to think they're waiting for art.ubuntu.com to go live, but they don't actually need it to do artwork :)
<whiprush> oh I see.
<wasab1> Do we have a methodology for packaging add-on modules and making sure they get compiled for each new kernel release?
<wasab1> For instance, mac-on-linux.
<jdub> wasab1: no, we've tried very hard to avoid it
<jdub> putting all our modules in the linux-image build
<wasab1> Ahh.
<wasab1> Can MOL fit in there?
<wasab1> And, ancilliary to this question, I am trying to compile MOL and cannot figure out how to get it to install into /lib/2.6.12-7-powerpc, long name, etc.
<wasab1> make-kpkg is not agreeing
<CarlFK> are the torrents at http://cdimage.ubuntu.com/daily-live/current actually being used?  I get the feeling nothing is seeding them
<jdub> CarlFK: possibly not; ask elmo or Znarl 
<wasab1> Bah. I am this |  | close to just hand moving them in there.
<jdub> wasab1: you have to change the version in the makefile
<jdub> i forget
<jdub> long time since i've built my own
<jdub> YAY!
<wasab1> Agreed, Yay.
<wasab1> Too bad these modules aren't in the archive. =(
<CarlFK> wow - 550K/s eta 20 min to wget the live image.  who cares about BT?  ;)
<wasab1> Hmm.
<wasab1> .torrent files should support a HTTP file path in them, in case of no seeds.
<wasab1> Byte-range gets could be used.
<wasab1> Would make a torrent self seeding.
<CarlFK> well, that assumes 2+ extra steps: tweek the torrent, tweek the client, put the file on a web server
<CarlFK> I think it would make more sense for the person creating the torrent to just seed it ;)
<wasab1> sure, but HTTP can be mirrored, like Ubuntu is.
<wasab1> I guess you could run seeds on each mirror. Anyways, just sounds like a nice little feature.
<CarlFK> the mirros could just be BT clients
<tepsipakki> kamion: around?
<jdub> HA HA HA HA HA
<jdub> whiprush: "hope fumes"
<jdub> ha ha ha ha
<whiprush> :(
<whiprush> It's not funny.
<CarlFK> here is my idea how to use BT to replace the current mirror system: http://p2p.noreply.org/p2p/DirDistribution
<whiprush> I really do hope
<pitti> elmo: polygen sync, please
<pitti> elmo: affix sync, please
<pitti> Moins mvo
<pitti> elmo: zsync sync, please
<ajmitch> hi mvo 
<mvo> hey pitti, hi ajmitch 
<mvo> good morning all
<pitti> elmo: python2.3 sync, too (that was the last one for today, promised :-) )
<ajmitch> elmo: and for me, scummvm & f-spot sync
<pitti> jbailey: do you know whether ia32-libs will disappear by breezy?
<pitti> jbailey: I'm asking because it still has a vulnerable zlib version, so whether I need to fix it or not
* mvo goes to see dholbach presentation for his thesis now
<pef> morning
<pitti> Hi pef
<tepsipakki> bah, there seems to be no way to tell the kernel to load e100 before orinoco on install?
<JaneW> hey doko
<JaneW> :)
<doko> good morning, JaneW, yes I've network access again, the central access point of my provider in Berlin was damaged ...
<JaneW> doko: sounds bad - glad you managed to get back...
<pitti> Hi doko
<desrt> doko; so what's the story with this mouse wheel business?
<pitti> Hey seb128 
<seb128> hey hey pitti
<pitti> Hi kronoss 
<kronoss> hi pitti 
<doko> desrt: tell me, what information you need? did you get feedback from the other guys?
<desrt> doko; was it on the bug?
<desrt> doko; it'd be good if you can identify what event devices corresponds to your mouse and see if wheel events register there
<desrt> doko; basically, one by one run hd /dev/input/event0, event1, event2 etc
<desrt> and move the mouse around to see
<seb128> desrt: so this wm crasher is an upstream issue :)
<desrt> then once you find it see if wheel events are reported
<desrt> seb128; yes it is.  and there's a patch available
<desrt> 315000 iirc
<seb128> I've just read elijah's and yours comment
<seb128> thanks guys
<desrt> thank the guy who found it :P
<desrt> i tried looking for it for about an hour... i was just lost
<desrt> doko; wb.
<desrt> doko; did yo catch the instructions?
<doko> desrt: didn't save them, I'll try a clean install first, to rule out upgrade problems, but not today
<desrt> doko; k.
<sivang> morning all
<sivang> anybody has an idea why when you don't have enough room on /boot, and you were attempting kernel upgrade which failed in the middle, you get left without network getting weird erros of permission denied when trying to get a lease?
<sivang> (/me is curious to understand how that works)
<sivang> I was getting the permission denied errors although I was root, on the SIOCSIFADDR and freinds..
<sivang> seb128: morning, did you get my email from a couple of days ago about the gimp?
<seb128> sivang: probably, was that something that should get a reply?
<thesaltydog> Just upgraded from hoary to breezy with a dist-upgrade. I am experiencing a tremendous performance loss. Each disk access is longer, even starting the terminal takes twice than before..
<sivang> seb128: not really, just one more thing - should I continue with gnome-applets? (or is it too late now since we're reaching/in preview freeze)
<seb128> sivang: you can continue for after preview
<sivang> seb128: k, cool. I'd be interested in seeing your patch to gimp, are you making a plugin for it, or just going to plain hackish way? ;)
<seb128> sivang: I'm not going to write a plugin for sure, why should I?
<sivang> seb128: I second that, but when I discussed that with neo over #gimp, he said that would be the best way to allow it to stand future changes and patches, and would be much easier to maintain since the core is likely to change...
<thesaltydog> There is a bug in pango that has been fixed few days ago (Gnome Bug 312075). This bug makes Anjuta unusable. Is it going to be fixed in Breezy too?
<seb128> sivang: yeah, I agree, but writting a plugin is some work
<seb128> thesaltydog: are pango guys going to roll a new tarball?
<thesaltydog> I am not in contact with them, just trying to use my Anjuta and found this: http://bugzilla.gnome.org/show_bug.cgi?id=312075
<seb128> thesaltydog: 312075 states that's no a pango bug
<doko> seb128: did you get my message yesterday about the untranslated messages in gnome-panel (Applications/Places/System)? They are translated in the de.po file, but appear untranslated in the panel
<thesaltydog> seb128, they say there is a pacth.
<seb128> "Both scintilla and Anjuta were fixed and released recently.
<seb128> "Both scintilla and Anjuta were fixed and released recently."
<seb128> for anjuta yep
<seb128> not pango
<seb128> doko: nop
<sivang> seb128: oh well, maybe if we see that it's being broken in the future, we'll make a plugin out of it..
<seb128> doko: what de.po file?
<thesaltydog> seb128, sorry I was believing that scintilla widget was something related to pango
<seb128> thesaltydog: np, but it's not
<seb128> sivang: like for every single other patch
<thesaltydog> seb128, anyway.. could I count again on my anjuta in the near future, or should I switch back to hoary?
<sivang> seb128: right ;)
<doko> seb128: there's only one in gnome-panel?
<seb128> thesaltydog: ask on #ubuntu-motu, that's an universe package
<thesaltydog> seb128, ok
<seb128> doko: gnome-panel doesn't ship any .po, they are stripped by language-packs ... do you use a language-packs, a local build ... ?
<pitti> Connecting to cdimage.ubuntu.com|82.211.81.176|:80... failed: Connection refused.
<pitti> hmmm
<pitti> who killed cdimage?
<ogra> Kamion, ping
<jdub> elmo: planet update whenever you're ready
<jdub> elmo: it's for tin tin
<pitti> ogra: ah, the http proxy of my provider died, apparently
<ogra> heh
<pitti> not funny...
<ogra> cant you work around that ? 
<sivang> pitti: you should switch the another
<pitti> sivang: there is no other provider, otherwise I would have done that ages ago
<doko> seb128: according to pitti, language packs are not yet merged from rosetta ...
<doko> seb128: I'm just wondering, why it's available in french, but not in german ...
<doko> where's the difference?
<Mithrandir> Kamion: hmm, last night's server install seems broken, dash isn't copied in.
<sivang> pitti: :(
<sivang> doko: lol
<seb128> doko: pitti creates language packs by hand
<seb128> doko: strace -e open gnome-panel and grep for gnome-panel.mo to know which one it tries to open
<seb128> doko: gnome-panel-2.0.mo
* seb128 is away for ~1h
<sivang> pitti: what's does the guy mean in #12694 with "Remote CUPS queue" ?
<pitti> sivang: well, a remote CUPS server
<sivang> pitti: ah, like a another machine running cups and the client uses IPP to send printjobs to?
<doko> seb128: hmm, how to start gnome-panel with strace? it wants to restart itself ...
<pitti> sivang: yes
<pitti> sivang: still remember your "Remote CUPS server" patch for g-c-m?
<sivang> pitti: yes ofcourse :)
<seb128> doko: gnome-session-remove gnome-panel && strace ...
<sivang> pitti: it was also 50% yours 
<pitti> the backend, yes
<ajmitch> pitti: language-selector is yours?
<sivang> seb128: what other interesting args does gnome-session have? ;)
<sivang> ajmitch: mvo's I think
<ajmitch> ok
<pitti> ajmitch: mvo
<seb128> sivang: that's not an argument
<seb128> sivang: gnome-session-remove is a binary
<sivang> seb128: doh! sorry, what other interesting binaries then? =)
<seb128> dpkg -L gnome-session | grep bin
* seb128 away now
<sivang> seb128: bye
<doko> hmm, looks like you can't play that gnome-session-remove game repeatedly
<seb128> doko: only if it's startedby the session
<seb128> doko: other way it doesn't restart and you don't need it
<doko> pitti: why are my locale.gen settings overwritten by installing language packs???
<pitti> doko: hm, they shouldn't be overwritten, just some added
<doko> pitti: but if there's already a de_DE.UTF-8, it's appended again, and again, and again. I use dpkg-reconfigure locales to get rid of them, and with the next update they appended again :-(
<Burgundavia> seb128, are we going with totem-gstreamer or -xine for breezy?
<doko> pitti: nice game, with every install/update of a language package, they are appended ...
<thesaltydog> after a breezy upgrade from hoary, I am experiencing a great disk performance loss. Whast am I missing?
<doko> seb128: ok, I was fooled by the menu items beeing translated, without having language packs installed ...
<sivang> pitti_laptop: do you remember what my GUI patch required in order to show the Global Setttings menu entry?
<sivang> pitti_laptop: (i.e. something from cups..)
<ajmitch> elmo: sync of anjuta from unstable, also
<sivang> pitti: what packages includes the backend scripts you did that my gui patch looks for?
<pitti> sivang: cupsys
<Mithrandir> Kamion: can I just fix 9213, or do you have some testing you might want to do for that?  I have a patch already
<chmj> pitti: ping 
<pitti> hi chmj 
<sivang> bah! here that irssi gnome-terminal bug again :-/
<sivang> pitti: cupsys seem to not have those files, do you have them on your machine?
<pitti> sivang: d'oh, indeed - where did they go???
<sivang> pitti: I don't know I was shocked they see they vanished , spotted that out when firing up g-c-m from terminal
<pitti> sivang: I'll look at it ASAP, but not now; can you please file a bug?
<sivang> pitti: ofcourse
<pitti> sivang: thanks
<zyga> pitti: ping
<pitti> Hi zyga 
<zyga> pitti: hi, there are more problems with messed up pl.po files
<zyga> pitti: I've loaded and fixed another one: kcheckgmail
<zyga> pitti: would you take a patch?
<Kamion> jdub: pong
<Kamion> tepsipakki: yo?
<sivang> pitti: bug filed
<Kamion> ogra: pong
<pitti> zyga: sure
<zyga> pitti: I've got a little perl script that can fix this kind of mess if anything else comes up
<Kamion> Mithrandir: yeah, I think something's busted with server installs, although dash is an odd place for it to happen
<sivang> pitti: I wasn't able to assign it directly to you, is this new in b.u.c ?
<zyga> pitti: ok I'll mail you the diff
<Kamion> Mithrandir: if you've got a fix for that cp thing, please absolutely feel free to go ahead
<pitti> sivang: hm, shuold work, anyway, I assign it myself
<Kamion> might want to chuck it upstream too, though I haven't checked their svn lately
<ogra> Kamion, what do i have to do to get edubuntu-server back on the CD again ? it vanished
<zyga> pitti: mail away
<Kamion> ogra: you need to prod me to run 'baz update' on cdimage *cough*
<Kamion> ogra: (done)
<ogra> heh
<ogra> Kamion, what about the preseeding ? 
<zyga> pitti: if you want the script it's here: http://www.suxx.pl/tools
<WaterSevenUb> pitti, Hi! How do you decide which langpacks ship with the ISO's? How many are shipped nowadays?
<pitti> WaterSevenUb: not many any more, since CD space is short; I hope to be able to add some more soon
<zyga> pitti: how about putting *only* language-selector .mo files and running it automatically on first run?
<WaterSevenUb> pitti, can you give me one number?:) is portuguese one of them? are you based in something like this: http://www.infoplease.com/ipa/A0775272.html?
<sivang> Kamion: what would be the right way to invoke build.sh from debian cd to try and build an image? (I have the mirror locally) 
<zyga> (sane for CD version)
<pitti> zyga: I don't understand
<Kamion> sivang: don't
<zyga> pitti: don't ship langpacks on the cd - they will most likely be outdated and will take up space
<Kamion> sivang: better start from the wrapper scripts in colin.watson@canonical.com--2005/cdimage--mainline--0
<pitti> zyga: oh, we need to, for people without network
<zyga> pitti: ship only all .mo files for language-selector and auto-run it on first login
<Keybuk> so, forgive me for being newbie team member, but PreviewFreeze means no uploads unless approved right?
<Kamion> Keybuk: yes
<zyga> pitti: then make langpack-cd :)
<pitti> WaterSevenUb: pt is shipped on install i386 and amd64, and on live pwerpc and ia64
<ogra> i've seen no mail calling out the freeze though...
<Kamion> ogra: oops, ok, looking now
<ogra> normally mdz sends one
<WaterSevenUb> pitti, pt (Portugal) or pt_BR ? 
<ogra> Kamion, could you trigger a testbuild afterwards ?
<pitti> WaterSevenUb: that contains both
<pitti> WaterSevenUb: we only split per-languge, not per-country in addition
<pitti> zyga: that collides with our principle of shipping only one CD
<zyga> pitti: true
<sivang> Kamion: thanks, I want to be able to continue cherry-picking should the current flags won't suffice for CHRP booting
<WaterSevenUb> pitti, ok... If I download now the daily build of Breezy I should have a full support of Portuguese? I think I saw a big problem so I need to test it now :)
<sivang> pitti: maybe we can hook up some script to get a dbus event and restart cups everytime this happens?
<sivang> pitti: (e.g., a new printer is connected)
<sivang> pitti: s/dbus/hal/
<pitti> WaterSevenUb: if you grab the i386 or amd64 one, yes, it will be there
<Kamion> ogra: yes
<pitti> sivang: no, that would be crap
<WaterSevenUb> pitti, ok... see you in a few minutes .
<pitti> sivang: we need to fix the bug, not work around it
<ogra> Kamion, yay :-D thanks
<Kamion> sivang: you can have a look at how build-image-set in cdimage invokes it
<pitti> sivang: the bug is not in cupsys, I thinkj
<pitti> sivang: it's somewhere in the gnome level
<Kamion> I use build_all.sh though
<Mithrandir> Kamion: the missing dash is an archive-copier problem, it seems.
<Kamion> ogra: is the edubuntu.seed you sent me meant to be a renaming of the previous server.seed?
<Kamion> Mithrandir: but archive-copier shouldn't really be doing anything much for server installs
<ogra> Kamion, that should be the default seed, not matter how you name it :) 
<Kamion> oh, no, sorry, not true
<Mithrandir> Kamion: it copies discover1, but not its deps.
<Kamion> ogra: I mean, you don't want workstation.seed to install the server, right?
<ogra> Kamion, and the current edubuntu.seed should become workstation and be optional
<sivang> pitti: ah I recall you already tried tracing this one, right?
<Kamion> Mithrandir: oh, blah, I think I understand
<Kamion> Mithrandir: ok, that's fixable fairly easily
<pitti> sivang: no, not really
<ogra> Kamion, but i want the server to be the default
<sivang> pitti: eh then I mistook that for another bug, sorry
<Kamion> ogra: hmm, I'll have to do isolinux/yaboot config fixups then, ugh
<ogra> s/server/server+desktop
<ogra> Kamion, sorry for that ...
<Kamion> ogra: done, amd64/i386 bootloader configs fixed up but not powerpc yet
<ogra> Kamion, ok, im only after a working i386 for now... 
<sivang> Kamion: I guess just attempting to run this snippet together with creating the CDIMAGE_ROOT won't do much good? ;)
<Keybuk> seb128: d'oh, of course, -g forces all variables to be zero-initialised
<Keybuk> possibly one of gcc's least helpful behaviours
<pitti> Keybuk: wow, thanks for that hint; that could explain a whole lot of heisenbugs I recently saw...
<Keybuk> that totally explains the metacity crash
<Keybuk> and why it went away when it was compiled for debugging
<zyga> pitti: could you explain something to me
<pitti> sure
<zyga> pitti: yesterday I've manually checked every .po in all langpacks and kde-i18n packages (for polish)
<zyga> pitti: why kcheckgmail not among them?
<zyga> s/why/why was/
<pitti> hm, lemme look
<Kamion> sivang: which snippet?
<pitti> kcheckgmail |    0.5.0-1 | http://archive.ubuntu.com hoary/universe Sources
<pitti> zyga: universe packages are not handled by langpacks, just main
<pitti> zyga: universe debs ship their own mo files
<jsgotangco> ok this works
<zyga> pitti: so all universe packages need to be checked manually
<pitti> zyga: I suppose, yes
<pitti> well...
<zyga> pitti: any advice on how to pull all sources from universe repo?
<pitti> zyga: I could make it a bit easier for you
<pitti> zyga: we indeed import all translations, we just ship main translations in langpacks
<Kamion> Keybuk: wow, really? Is that documented?
<pitti> zyga: if you are fine with a slightly older tarball (about a week old), I can give you everything
<zyga> pitti: all I need are pl.po's for everything - a script can check them automatically and generate fixed ones
<zyga> pitti: fine - those errors are probably way older
<pitti> zyga: ok: http://people.ubuntu.com/~pitti/langpacks/breezy-current.zip
<zyga> thanks :)
<pitti> zyga: that will always contain the most recent archive of all po files
<pitti> zyga: generated daily usually, just not right now since we changed the import process
<pitti> zyga: beware: 240 MB
<Keybuk> Kamion: I don't think so ... I just noticed it once
<zyga> pitti: thats fine :)
<JaneW> seb128: ping
<zyga> pitti: eta 35min, I'll ping you if anything needs fixing
<Kamion> ogra: edubuntu rebuild in progress
<JaneW> seb128: hello, I was just wondering if you have an update on LaunchpadIntegration. Sivang was asking about it the other day too. Is it ready to progress to green yet?
<ogra> Kamion, yay, thanks :)
<ogra> JaneW, ^^^
<JaneW> YAY :))
<tepsipakki> kamion: just needed to know if it is possible to change the order of the network interfaces on install
<tepsipakki> kamion: but it seems no
* JaneW hold thumbs, crosses fingers and toes etc
<tepsipakki> kamion: at least on my thinkpad the orinoco gets eth0 when I'd like the e100 to have it
<Keybuk> Kamion: given the code
<Keybuk> int main() { int a; a+=1; printf("%d\n", a); return 0 }
<Keybuk> syndicate scott% gcc -O2 -fPIC example.c
<Keybuk> syndicate scott% ./a.out
<Keybuk> -1208167843
<Keybuk> syndicate scott% gcc -g -O0 -fPIC example.c
<Keybuk> syndicate scott% ./a.out
<Keybuk> 1
<Diziet> -davenant:d> gcc -Wall -O1 example.c 
<Diziet> example.c: In function `main':
<Diziet> example.c:1: warning: implicit declaration of function `printf'
<Diziet> example.c:1: warning: `a' might be used uninitialized in this function
<Diziet> After I fixed your syntax error.
<Keybuk> Diziet: right, it's just an example to show gcc's idiotic "zero-initialise variables in -g so the bugs go away"
<Diziet> Or am I missing your point ?
<Diziet> It does what ?
<Keybuk> see above ... with just -O2 you get a random number
<Keybuk> but with -g -O0 you get 1, because the uninitialised variable is set to zero anyway
<Keybuk> "gcc is your friend, oh yes"
<Diziet> You're changing the -O and the -g at the same time.
<Keybuk> right, it's an effect of both
<Robot101> Keybuk: an effect of either, or both together? what does -g -O2 do?
<Kamion> tepsipakki: not easily; it's just whatever order they get hotplugged in
<Keybuk> Robot101: dunno, didn't ever investigate that much
<Keybuk> it's not documented behaviour
<Keybuk> it's just something gcc does
<Keybuk> -O2 or -g -O0 are the two common compilation options
<Keybuk> usually you do the latter when something compiled with the former crashes -- and then the bugs go away
<Robot101> except Debian builds everything -g -O2 then strips it, don't we?
<Keybuk> syndicate scott% gcc -g -O2 example.c
<Keybuk> syndicate scott% ./a.out
<Keybuk> -1208593827
<Robot101> so it's orthogonal to -g, removing zero initialisation is an optimsation
<Diziet> In my tests it depends only on -O.
<Robot101> but this is a good reason to use compiler warnings and listen to them :P
<Keybuk> it could be just the -O, yeah
* Keybuk notices another bug in the gcc documentation
<Keybuk> -O0 (this is the default) ... No it's not!  You changed the default in 4.0 you fools
<Diziet> -O1 is sufficient to make it `work'.  And this is probably accidental.
<Diziet> To be fair -O0 produces code so verbose it's hard to read the asm by hand.
<tepsipakki> kamien: yeah.. a pity
<tepsipakki> kamion: now that I have two nic:s, I need to preseed which one to use, and that is quite tricky because all desktops use eth0 ;)
<tepsipakki> but doable
<tepsipakki> just some blood, sweat and tears
<Diziet> The bugzilla is sending me all of these n-m bugreports, which I plan to ignore until breezy+1.  What should I do with them in the bugzilla ?
<Keybuk> LATER/REMIND?
<Diziet> What does that do ?
<Diziet> It would be better if I could somehow send them to the MOTU whose package it is.
<Keybuk> nothing in particular, now I think about it
<Kamion> IME bugzilla's LATER resolution is a good way to lose stuff
<Kamion> Diziet: I can change the default assignee if I know who it should be
<Kamion> and you can certainly reassign the existing ones
<Diziet> default assignee> Yes, that would be nice but there seems to be no way to find out who to pick !
<Diziet> I remember having an IRC conversation with various people yesterday.
<Diziet> Why oh why oh why don't we use the Maintainer field ?
<Kamion> it was j^, if I remember correctly; let me try and hunt down who that is
<Diziet> Oh, yes, it was.
<Diziet> Deciding the bug destination based on chasing up the person behind an IRC nick remembered from the previous day hardly seems like a sane process !
<Kamion> yeah, I know
<Kamion> actually I'm chasing up the URL to his packages and I'll fish it out of the changelog there
<Kamion> Jan Gerber
<Kamion> I'll mass-reassign all the existing bugs
<Kamion> oh, he doesn't have a bugzilla account
<Kamion> mutter
<Diziet> For future reference, could I do the mass reassign myself next time ?
<Kamion> you should be able to, yes
<Kamion> find the "change several bugs at once" link
<Kamion> (on any bug list)
<Diziet> I don't have one of those.
<Diziet> AFAICT.
<Kamion> go to "Prefs" and then "Permissions"; does it mention "editbugs"?
<Diziet> No, only canconfirm.
<Kamion> ogra: IIRC you can grant people editbugs; could you do so for Diziet? e-mail address in /msg
<thesaltydog> my breezy upgrade from hoary is very sloooow. 40 seconds to open an openoffice document, 8 seconds to open a terminal, 7 seconds to open nautilus... where should I start investigating?
<thesaltydog> logs look apparently good..
<zyga> mvo: morning :)
<mvo> hey zyga 
* mvo is back from dholbachs diploma presentation
<mvo> hey pitti, thanks for your mail
<pitti> mvo: how was it?
<pitti> mvo: 1.0 I hope :-)
<Kamion> ogra: new edubuntu install CDs up
<ogra> Diziet, done
<mvo> pitti: not quite but close enough! he did pretty well and had nice latex-beamer slides
<Kamion> hmm, but still no edubuntu-server, d'oh
* Kamion scratches head
<JaneW> hmmm
<ogra> hmm, and the report somewat exploded...
<ogra> oh, mostly ppc... nm
<ogra> Kamion, indeed i want netcfg/disable_dhcp; sorry, my fault
<mvo> pitti: about this aptitude problem, can you still reproduce it? 
<Kamion> ogra: you managed to overflow the CD size on all three architectures, that's why :)
<ogra> what is the current allowed size ? i can live with 800MB images :)
<Kamion> though I think something else is wrong too
<Kamion> CD 1 filled with 647467976 bytes ... (limit was 653262848)
<JaneW> kamion: ping
<Kamion> 800MB overflows all physical CDs I'm aware of ...
<Kamion> JaneW: yes?
<ogra> can we make that at least 700 ?
<JaneW> kamion: sorry to bug, I know you are V.busy atm, but many of your goals are still listed as WIP in BreezyGoals, I was owndering if there are any updates...?
<Kamion> ogra: I'll see what I can do, but you're 91MB over the limit on amd64, 74MB on i386, 112MB on powerpc
<Kamion> JaneW: I've been on vacation
<JaneW> Kamion: yes I know
<ogra> Kamion, that was expected....
<Kamion> and firefighting since then, so most of my goals are in the same state as they were at feature freeze
<JaneW> Kamion: mdz wanted all goals off WIP (after Feature Freeze) yours are conspicously still there - but I know you have mitigating circumstances ;)
<JaneW> Kamion: as long as mdz accpets that, I won't bug you about them ;)
<Kamion> I'll talk to mdz about what the status of BrandingForDerivatives should be
<Kamion> Mithrandir was looking at MountingHDDFilesystems, but I don't know how far he got
<Kamion> the PackageSelection ball isn't really in my court any more
<Kamion> mvo: PackageSelection?
<Mithrandir> Kamion: AIUI, it got lost in feature freeze, so I stopped working on it.
<Kamion> JaneW: the live CD part of MountingHDDFilesystems is already listed under deferred goals; do I need to do anything to the non-deferred line in the wiki page?
<Kamion> ogra: the CDs won't work at all reliably until they're under the limit, one way or another
<ogra> so we'll have to switch to dvd it seems
<JaneW> Kamion: is the stuff in the non-deferred line done?
<Kamion> JaneW: yes
<JaneW> Kamion: if so it can go green (one of the 3 shades) :)
<JaneW> Kamion: great, is it still being tested or fully complete?
<JaneW> Kamion: I'll update it for you.
<Kamion> JaneW: no need, doing it now
<Kamion> I've just set it to implemented for the moment, will decide more fully later
<JaneW> great thanks
<JaneW> Kamion: perfect thanks
<Kamion> ogra: 100MB or so doesn't seem like an insurmountable barrier; you have lots of language packs in ship still, for instance
<ogra> in the end we will have *all* langpacks in :)
<zyga> pitti: ping
<Kamion> or you could lose thunderbird
<ogra> so we'll end up with dvd anyway...
<Keybuk> Kamion: what installs hfsplus, hfsutils, grub, initrd-tools, language-pack-gnome-en, linux-*, openoffice.org, openoffice.org-gtk-gnome ?
<pitti> Hi zyga 
<Keybuk> they're installed on this system, but aren't deps of any of the meta packages
<ogra> hmm, dropping thunderbird is a good idea :)
<zyga> pitti: just a thought: would hevily compressed .po files be smaller than .mo files?
<pitti> zyga: I doubt it
<zyga> pitti: I'm thinking about compiling .mo during install 
<Kamion> Keybuk: debootstrap, debootstrap, grub-installer, base-installer, base-config, base-installer, used to be ubuntu-desktop, used to be ubuntu-desktop
<pitti> zyga: no, that would be evil
<Kamion> Keybuk: the first two are an anomaly because we don't have architecture-specific priorities (katie limitation)
<ogra> Kamion, i'll look what i can drop for now, i'll poke you again for a rebuild later
<Kamion> ok
<michele> hello
<Keybuk> and the last two could have been a mismatch between Task: and the meta-packages?
<michele> pitti, I read in the AudioInfrastucture page "hack ALSA's OSS emulation to support opening /dev/dsp multiple times and route it through dmix"
<michele> pitti, has that been implemented?
<WaterSevenUb> pitti, I've just tested breezy... it seems that the problem, also present in Hoary is that when I choose Portuguese, and Portugal in the installation, by default it is installed Portuguese (Brazil), which imho is bad in the user perspective.
<pitti> michele: no, it was determined to be impossible
<Kamion> Keybuk: yes, possible, especially if you did a netboot install since amd64 still had openoffice.org (1) until recently
<Keybuk> this was a netboot onto i386
<Kamion> and architecture-specific Task fields don't work either
<pitti> WaterSevenUb: right, but that's rather an installer bug
<michele> pitti, oh sad. thanks
<Kamion> pitti: ?
<pitti> WaterSevenUb: the language package offers both countries, it's just a matter of what is installed in /etc/environment
<WaterSevenUb> pitti, also... I was asked during installation that I should connect to the network as usual for full language support, although... in the end... it was present langpack and gnome pack.
<WaterSevenUb> pitti, should I file a bug or contact someone?
<Kamion> pitti: never heard of that bug
<pitti> WaterSevenUb: that's fine
<Kamion> WaterSevenUb: language-support-pt isn't on the CD
<Kamion> no room
<pitti> WaterSevenUb: that does not refer to language-pack-*, but to language-support-*
<Keybuk> ok, cool
<Diziet> I wish I knew what `space alien' means in the partitioner :-).
<Kamion> Diziet: there's a help button somewhere
<Mithrandir> Diziet: uhm, context?
<Mithrandir> ah, that one.
<Keybuk> was just updating my keybuk-* packages and wondered whether I'd installed those over-enthusiastically
<pitti> WaterSevenUb: so you really chose Portugal as country and have pt_BR.UTF-8 in /etc/environment?
<Kamion> it's one of the Anton-Zinoviev-thought-it-was-pretty partman runes
<Mithrandir> those icons are slightly hard to guess.
<WaterSevenUb> pitti, let me check;)
<WaterSevenUb> LANGUAGE="pt_PT:pt"
<WaterSevenUb> LANG="pt_PT.UTF-8"
<WaterSevenUb> but I am pretty sure the translations are not the ones for Portuguese (Portugal)!
<WaterSevenUb> just looking to synaptic they are in Portuguese (Brazil).
<pitti> WaterSevenUb: ok, so at least that part worked fine
<sivang> whee I just saw the new screensaver login , kool :)
<Kamion> there's mostly-solid-face (keep existing data on partition), skull-and-crossbones (format partition that already has data on it), mostly-hollow-face (format blank partition)
<sivang> was it a SoC of someone?
<jsgotangco> heh
<jsgotangco> no that was during UDU
<jsgotangco> the great smackdown
<Kamion> I think sticking to the letters that it uses on serial console installs would've been better personally
<sivang> jsgotangco: really? who worked on it?
<Kamion> K, F, f respectively
<WaterSevenUb> pitti, (language-selector was not working too ... maybe normal still)
<jsgotangco> no idea but obviously you see jdub, bob2 and chmj
<WaterSevenUb> pitti, so what can be wrong?
<pitti> WaterSevenUb: what *is* wrong actually? the translations itself?
<Kamion> WaterSevenUb: it could be that there simply aren't any pt_PT translations
<Kamion> so it's using pt_BR as a fallback?
<pitti> yes, that's entirely possible
<WaterSevenUb> pitti, no.... Synaptic and others are using pt_BR. In Hoary I am using the same applications in pt_PT, I guess the translations should be there.
<pitti> WaterSevenUb: right, there is a pt_PT synaptic
<pitti> WaterSevenUb: I /msg you
<ajmitch> a user should not be allowed to lock the screen on the live cd... because it's not letting me back in :)
<Diziet> Oh, what I'm calling space-alien might be skull-and-crossbones.
<pitti> ogra: yay new screensaver
<ogra> :)
<pitti> Hi jdthood 
<jdthood> hiya
<tepsipakki> kamion: is there currently something wrong with parted.udeb?
<Kamion> tepsipakki: not to my knowledge
<tepsipakki> it fails on me, but I'll recheck its not the hd
<seb128> doko: k
<ajmitch> partman appeared to hang for me, but I haven't tested if it's due to a dodgy CD burn
<seb128> Keybuk: oh, right
<seb128> JaneW: I guess we can change it right, will do
<zyga> ajmitch: switch to vt1, passwd ubuntu
<zyga> pitti: could langpacks use bzip2 to compress .mo files?
<ajmitch> zyga: it wasn't terribly urgent, I'm just waiting for dd to finish copying the whole drive contents :)
<JaneW> seb128: great, thanks :)
<Keybuk> seb128: I guess you've seen the patch on upstream gnome's bugzilla for metacity?
<pitti> zyga: they already do
<tepsipakki> kamion: for some reason the hd is not recognized. worked yesterday, and I can boot the previous installation
<seb128> Keybuk: yep, I'm pondering patching or waiting for the new tarball
<pitti> ogra, mvo, doko: http://www.fh-augsburg.de/~goehlert/misc/plaetzchen.gif
<ogra> pitti, sweet :)
<mvo> pitti: haha, great :)
<sivang> pitti: what does it say?
<pitti> sivang: it's a babelfish-ish translation of an english cookie error message; only for Germans, I'm afraid
<tepsipakki> kamion: hoary install works, so it's the hardware detection bit that is broken
<tepsipakki> kamion: by "yesterday" I mean the version that was mirrored here yesterday morning (~07:00 UTC)
<pitti> doko: do you have some time to debug that locale.gen issue?
<Kamion> tepsipakki: feel free to file a bug on the hw-detect component, attaching /var/log/syslog from the installer
<Kamion> tepsipakki: it might well be a kernel bug though; hardware detection is mostly a hotplug job nowadays
<tepsipakki> uhm, remembered that the netboot-image is a couple of days old..
<ogra> Kamion, i took out all langs except en, de, fr and es for now and removed thunderbird, epiphany and the GL screensavers, do you think thats enough ?
<ogra> ...having screensaers installed at all is silly btw... since they are disabled in ltsp anyway now
<siretart> infinity: I see that you synced ghc6
<Kamion> ogra: don't know, we'll find out on the next build
<ogra> Kamion, after the updated metapackage is in the archive... i'll ping you...
<infinity> siretart : Yes, I'm going to bootstrap with that version, PLEASE don't intruduce a new ghc upstream.
<Kamion> oh damn, now I see why server wasn't getting added to the CDs
<ogra> why ?
<Kamion> fixing
<ogra> ah, good :)
<Kamion> I forgot a line in tasks/Edubuntu_breezy
<infinity> siretart : This will be "Good Enough" for breezy, we can break the world with new upstream after breezy+1 opens.
<siretart> infinity: sistpoty already prepared a solution for this
<siretart> infinity: he basically packaged a snapshot of ghc6, which builds with gcc-4.0
<infinity> siretart : Yes, and I'm asking, PLEASE don't do that.
<infinity> siretart : Those snapshots have known problems.
<infinity> siretart : 6.4, however, is known to be just fine, and won't introduce any new FTBFS bugs to deal with.
<ivoks> ahm...
<ivoks> in breezy is mozilla-firefox package that installs by default
<ajmitch> ah, so we shoudl just get on with fixing the packages that build-dep on ghc6 then
<Kamion> ogra: another build's in progress
<siretart> infinity: ok, this means that we are better off with ghc 6.4 even if that means that we build them with gcc-3.3
<ivoks> problem is... that firefox is useless on 30 computers i just installed (i can't see any text/menus)
<infinity> siretart : In the end, it's all universe stuff, and you guys can do what you want, but I've been tracking ghc stuff for months, and I'm pretty confident that you'll be in a world of hurt if you upgrade to a snapshot.
<ajmitch> infinity: it just would have been nice to hear that you were going to do this
<infinity> siretart : If you're willing to defer to my judgement on this one, I'll bootstrap the version I just sycned, and you'll be on your way.
<ajmitch> so we didn't have to spend the time looking into it
<infinity> ajmitch : I hadn't planned on it until the change was made in Debian.
<siretart> infinity: aah, ok. in this case, thanks for the information. all we wanted is a installable and working ghc6 in universe
<infinity> ajmitch : Sorry. :/
<ivoks> ok... bugzilla :)
<ajmitch> infinity: it's ok
<infinity> siretart : If you guys are sure you can restabilise the haskell world after introducing a new upstream, I can bootstrap that for you instead, but this route is much less hassle.
<ajmitch> a working ghc6 is a definite plus
<jbailey> pitti: ia32-libs will still be around for breezy.  amd64-libs is gone, though.
<ajmitch> since we've got users who must have darcs yesterday
<siretart> infinity: I thought that gcc-3.4 (or 4.0) was a requirement. therefore we concentrated on the new snapshot
<infinity> Yeah, darcs is about the only reason I currently care about haskell as well (well, that and the fact that there's a LARGE tangle of stuff that's FTBFS waiting on ghc...)
<siretart> jepp
<Kamion> ogra: I've bumped you to 700MB CDs as well
<infinity> siretart : There's no C++ code in ghc, so it's safe to use 3.3
<ogra> Kamion, thanks :)
<siretart> infinity: cool :)
* infinity runs off to work on apache stuff now.
<ajmitch> great, hopefully a lot of the FTBFS stuff will just fall out with a rebuild
<ogra> i wonder if you even still can buy 650 MB CD media... it seems ages ago that i had such a small one around here
<infinity> ajmitch : Most of it will fall into line with zero effort, yes.
<infinity> ajmitch : There's a few circular deps tangled up with ghc6 that need to be done at the same time, and I'll do those myself, the rest should just require rebuilds to get them in line.
<ajmitch> infinity: thanks
<ajmitch> I'm glad the mono bootstrapping is far less work now, compared to a mess like ghc6
<infinity> ghc6 would be simple, if it wasn't for the gmp3 split.
<doko> pitti: locale.gen: it's on my list, but I'm unsure how we should support "I only want to keep one of the de/fr locales"
<infinity> But no big deal.
<Kamion> ogra: yes, definitely. I think most of my plain CDs are
<Kamion> some older drives, too ...
<tepsipakki> kamion: yes, now it works with the latest netboot-image, d'uh
<Kamion> tepsipakki: what were you using before?
<tepsipakki> some image dated earlier this week, I think
<tepsipakki> does netboot support usplash?-)
<Kamion> it's in desktop the same way it is on CD install
<Kamion> +s
<tepsipakki> but is it in the netboot-initrd?-)
<tepsipakki> so I can just see the nice logo while installing (preseeded)
<Kamion> no, usplash is not in any installer initrd
<pitti> doko: that's another issue, I'm mainly interested in the duplication bug now; I replied to the bug report
<torkel> ogra: did you ever manage to convince elmo to do a sync of openafs from Debian unstable?
<jordi> jdub: people keep asking me when we get a list. Do you have some estimation on how much longer it'll take to get resolved?
<jordi> jdub: if we know that ubuntu-l10n-* is the way we want to do it, can we get mine created and get the others renamed another day?
<ogra> torkel, 1.3.82-1 is in... 
<jdub> jordi: yes, going to sort them tonight
<Kamion> ogra: new Edubuntu CDs up
<torkel> ogra: the kernel module will probably not build with 2.6.12, which makes the whole package more or less useless
<jordi> jdub: hmm, tonight is probably pretty soon for ya, right?
<jordi> jdub: thanks dude
<ogra> Kamion, thanks
<sivang> jdub: my IBM contact re: box borrowing is out of the office, she's going to be back around 4th september, then I'll update again
<pitti> carlos: here?
<carlos> pitti, hi
<carlos> pitti, yes
<ogra> Kamion, is there any log wher i can find out more about the report ? i.e. whats holding back edubuntu-desktop on i386 suddenly ? 
<jdub> Kamion: where is the baz repo for seeds?
<ogra> Kamion, nm, found it
<torkel> ogra: getting 1.4RC1 on breezy would be a really good thing as it works with 2.6.12
<ogra> torkel, seems ok to me... 
<ogra> elmo, can you sync openafs from debian unstable please ? 
<torkel> ogra: thanks a lot
<ogra> torkel, wait till its synced before cheering
<torkel> ogra: I trust in you getting it synced :-)
<pitti> lamont-away: ping
<Kamion> ogra: not really unfortunately
<Kamion> ogra: but I bet the CD overflowed; when that happens, the report is essentially garbage
<ogra> Kamion, but it looks very good... 
<ogra> oh
<ogra> can you find that out anywhere ? 
<ogra> i though i could just drop epydoc and am done... the report looks quite good for i386
<zyga> pitti: how about creating region CDs?
<Kamion> ogra: amd64 is about 6MB over; powerpc is about 50MB over; i386 fits
<jdub> ok dudes
<jdub> i need a little bit of help
<ogra> Kamion, yay... thats what i wanted to hear :)
<Kamion> zyga: we'd rather other people do that; our CD creation resources are getting strained as it is
<zyga> pitti: like north america, south america, europe (could be split up) and so on
<jdub> in october/november, i am going to be spreading the love
<pitti> zyga: we discussed about it, but first it is against the one-cd philosophy, sencond, it would require us to test 200 images rather than 4
<mjg59> jdub: All over our faces?
<zyga> Kamion: resources == creating pressed cds or making iso images?
<Kamion> zyga: both, plus testing as pitti mentions
<zyga> Kamion: I see :/
<pitti> jdub: shall we help you carrying 200 boxes of ubuntu cds?
<ogra> Kamion, let me rip out epydoc and i'll ping you agian for a rebuild... i think then i'm done for today (if this thing installst then)
<jdub> mjg59: possibly. london is on the itinerary.
<jdub> i need a name for the tour
<Kamion> ogra: yeah, looks like it
<zyga> Kamion: what it the average number of CDs ordered daily?
<jdub> last month, i was thinking of calling it the "northern tornado tour"
<Kamion> zyga: lots. I don't have the figures.
<jdub> but, ah, events have made that somewhat offensive
<Kamion> zyga: it consumes quite a lot of money
<zyga> Kamion: I wonder i sending free CDs is wise in the long term... 
<jdub> (i was hoping to make a  refernece to breezy, but anyway)
<jdub> so my fallback is the BadgersBadgersBadgersTour
<zyga> Kamion: they should be like $1 so that people who don't need them won't bother
<Kamion> zyga: consider it marketing
<jdub> anyoen else have ideas?
<Kamion> it's cheaper than many marketing campaigns, and astonishingly effective
<zyga> Kamion: well so far you are doing quite okay :)
<mjg59> jdub: Pants Off 2005?
<jdub> zyga: we've shipped 3 million hoary CDs
<jdub> zyga: half that of warty CDs
<Kamion> jdub: Badgers->Badger would make that more pronounceable
<tseng> BadgerBadgerMushroom
<jdub> Kamion: but less people would go to badgersbadgersbadgers.com ;)
<zyga> Kamion: in poland there are about 3 linux magazines - none of them ever shipped with ubuntu cd, lots of fedora core, makdrake, freebsd (I know it's not linux), slackware and aurox (polish redhat clone)
<zyga> jdub: wow, that's *alot*
<jdub> tseng: was thinking about something Schnakey
<Treenaks> jdub: "Expedition: Northern Hemisphere"
<zyga> jdub: did you try to contact any gov officials to get ubuntu into schools?
<jdub> zul: nice seeing lots of you in the kernel changelogs :-)
<jdub> zyga: there is a lot of ubuntu in schools, as it happens
<jdub> in some cases, we are working with governments and businesses to make it happen
<jdub> in others, we just get to hear the success stories :)
<Treenaks> jdub: and the pictures that go with them :)
<jdub> yes
<jdub> lots of gdm glow pr0n :-)
<zyga> jdub: is there any info about per-country progress? I'd like to know how my country is doing
<jdub> zyga: not directly - are you on the ubuntu-pl loco team?
<zyga> jdub: you mean in rosetta? yes - anything else - no
<jdub> zyga: lists.ubuntu.com/mailman/listinfo/ubuntu-pl
<Kamion> ogra: we should fix python-epydoc, too ...
<Kamion> causes problems for Ubuntu
<ogra> oh, ok... but i focus to have a working CD for now, there are testers waiting... i'll look at epydoc directly afterwards :)
<zyga> jdub: I know that's offtopic but the page defaults to iso-8859-1 instead of -2 even though meta key is okay :/
<Kamion> oh, python2.4-epydoc just needs to be promoted to main
<ogra> oh
<ogra> it wasnt already ? wher does it cme from ? 
<ogra> Kamion, can you do that ? then i'll change my seed back
<ogra> hmm, anastacia is dead it seems
<Kamion> ogra: (a) epydoc got uploaded recently, check breezy-changes, (b) yes, doing now, please revert the seed change, (c) I was just running cron.sync and may have intersected with mdz's cron job
<ogra> ah, good
<Kamion> Migrated python2.4-epydoc_2.1-9ubuntu1_all.deb from universe to main in breezy suite.
<elmo> Riddell: ?
<ogra> Kamion, as soon as it hits main, i'd be ready for another build
<ogra> (seeds are ready)
<Kamion> sure
<ogra> thanks :)
<ogra> hmm, i wonder if i really need emacs in edubuntu
<Treenaks> ogra: only if you want to corrupt lots of poor unsuspecting souls ;)
<ogra> Treenaks, in a classroom ? 
<Treenaks> ogra: ... even more
<Treenaks> then
<ogra> Treenaks, i doubt it... and its about 20MB i could save
<bddebian> Hello
<WaterSevenUb> kamion,pitti, it looked like the problem was only affecting synaptic. I'm going to file a bug.
<Kamion> WaterSevenUb: I've fixed the localechooser bug that made it happen, so the synaptic bug is not so urgent any more
<Kamion> -Portuguese;1;pt;pt_PT.UTF-8;pt;PT;pt:pt_BR:en_GB:en;kbd=lat0-sun16(utf8)
<Kamion> +Portuguese;1;pt;pt_PT.UTF-8;pt;PT;pt_PT:pt:pt_BR:en_GB:en;kbd=lat0-sun16(utf8)
<Kamion> thanks for your patience
<WaterSevenUb> kamion, you mean it's not urgent because it's going to use pt despite the fact that it has the translation named pt_PT?
<Kamion> no, I mean it's not urgent because I fixed localechooser to list pt_PT ahead of pt in LANGUAGE
<Kamion> (though that will only take effect on fresh installs, of course; for existing installs, edit /etc/environment and add pt_PT: in front of the first pt
<Kamion> )
<WaterSevenUb> kamion, ah, ok:) 
<WaterSevenUb> kamion, thanks guys.
<pitti> Kamion: that still confuses me, though; why do we need to prefer one over the other? wouldn't that just chnage the bug the other waay round?
<Kamion> pitti: no, there's a separate Portuguese (Brazilian) option in the installer
<pitti> Kamion: ah, ok. Makes sense then
<pitti> thanks
<Kamion> and that puts pt_BR:pt:pt_PT in LANGUAGE, so I just changed the Portugal one to match that
<pitti> WaterSevenUb: thanks for your efforts to check that
<WaterSevenUb> pitti, you are welcome.
* Kamion wanders off for a bit while CDs build; with any luck this can be Colony 4
<ogra> Kamion, edubuntu too ? 
<lamont-away> pitti: ack
<pitti> lamont-away: Hi, how are you? I sent you mail in the meantime
<lamont-away> pitti: ok - I'll look at my email
<Kamion> ogra: it's building; haven't decided what to do about it wrt C4 yet
<ogra> Kamion, thats my job, if its good, i'll copy it to rookery, that one is linked from the edubuntu tzesting docs
<ogra> but it looks very good (at least for i386) i hope epydoc wont overflow x86 now
<fsmw> jdub, hi
<fsmw> is here something from ubuntu installer team?
<fsmw> somebody
<Robinho_Peixoto> hi
<jdub> fsmw: Kamion is the man to speak to :-)
<fsmw> thanks jdub 
<fsmw> Kamion, ping!
<Robinho_Peixoto> i am create a patch for the Bug 14523 bug i don't know wath the file put on bugzilla. A new esound_0.2.36-1ubuntu5.diff.gz or the patch for esound_0.2.36-1ubuntu5.diff.gz. Sorry, i don't speak english.
<seb128> Robinho_Peixoto: a patch with your changes is fine
<Robinho_Peixoto> i will put a new esound_0.2.36-1ubuntu5.diff.gz
<fsmw> where can i find the source code for ubuntu-installer?
<fsmw> should i use debian-installer from its subversion copy?
<jdub> fsmw: all of the source packages of all the components :)
<fsmw> jdub, how can install that sources?
<jdub> fsmw: apt-get source ...
<jdub> fsmw: but tehre are a lot of packages :)
<fsmw> humm, i want to fix some translations in d-i
<fsmw> i'm seeing that typos from 4.10 and still are in breezy
<fsmw> so i want to send a patch
<mjg59> jbailey: Around?
<fsmw> i guess that i need .po files from d-i
* jdub wonders if d-i is in rosetta
<jbailey> mjg59: Yup, 'sup?
<mvo> jdub: IIRC it is in rosetta
<pitti> does anybody know how I can check the validity of a file descriptor without actually reading from it? something like peek()?
<mjg59> jbailey: Bad things happen to USB if we resume from hibernation with USB modules loaded
<pitti> oh, there is pread()
<mjg59> jbailey: Would it be possible to hack the resume script to unload USB before attempting to resume?
<jbailey> mjg59: What does that do if you're running off of usb harddrive?
<mjg59> jbailey: We don't support suspending to USB devices anyway
<jbailey> Or I guess it's screwed anyway at this point...
<mjg59> Ideally we'd attempt to resume before loading the USB modules, but I don't know how practical that is
<Kamion> fsmw: http://people.ubuntu.com/~cjwatson/installer-po/, more or less
<Kamion> fsmw: if they're translations that are also present in the Debian installer, it is MUCH easier for me if you can get them fixed upstream; I'm not good at acting as a go-between for translations into languages I don't speak
<jbailey> mjg59: 'kay, so, hmmm..
<mjg59> Otherwise they get loaded, unloaded and loaded on a normal boot
<Kamion> ogra: if it's part of Colony 4, by definition it goes into the release directory on cdimage; if you want to make releases not part of the Colony series, you're welcome
<jbailey> I guess the question there is to walk through all of the usb bus, and unload those drivers, and then try to guess what the usb controller modules might be?
<jbailey> mjg59: I can hardcode a list for now, I guess.
<mjg59> jbailey: It's only the hcd drivers that are the problem
<fsmw> Kamion, i'm looking for some typos in spanish translation so i guess that i'll look in es.po
<Kamion> fsmw: indeed
<fsmw> let me check what happens there
<mjg59> jbailey: As I said, ideally we'd be able to split the hardware detection into built-in disk and hotplug hardware sections, and resume from disk between the two of those
<ogra> Kamion, my tests go a bit further then just installing a desktop, i dont want to slow down the colony releases...
<fsmw> Kamion, is that the only one .po file in the instaler?
<Kamion> ogra: ok, in that case perhaps it's better for you to do it independently
<Kamion> fsmw: that's a collated .po file made up of all the others put together
<fsmw> ok
<jbailey> mjg59: Lemme think through this and catch up with you.  What do you mean by 'built-in disk', like modules compiled into the kernel?
<mjg59> jbailey: Like a disk that's actually *in* the hardware
<ogra> Kamion, thats what i thought... i think mdz isnt happy about it, but i'd rather not have impact on the normal release process
<mjg59> So native IDE or SCSI controllers
<mjg59> Not USB or Firewire
<jbailey> mjg59: So before I walk the usb bus?  That's doable, I guess.  We'd still have to unload ?hci_hcd, though.
<mjg59> jbailey: Hm. 
<fsmw> Kamion, on the other hand i get some english dialog in breezy even if i choose spanish, i'm installing from CD-i386
<Kamion> fsmw: that's not a surprise, our translations have never been complete because we changed strings from Debian
<Kamion> we've been trying to reduce the size of the delta there
<zyga> fsmw: what message is that?
<Kamion> I'm happy to take translations for Ubuntu-local strings
<fsmw> Kamion, is there a way to help with that?
<jbailey> jbailey: Unless there's some sort of information in /sys that will tell me that it's a nic or a storage controller?
<jbailey> mjg59: ^^
<Kamion> fsmw: yes, send me translations :)
<jbailey> I'm losing it.
<fsmw> zyga, i found a typo that say "Comproando ..." should say "Comprobando", but i can't find that string in the .po file
<Kamion> fsmw: I just fixed that earlier today; somebody else reported it
<bddebian> jbailey: losing? ;-)
<jbailey> bddebian: Shush, you.
<jbailey> ;)
<zyga> fsmw: grep the .mo files
<mjg59> jbailey: /sys/bus/pci/*/class
<mjg59> devices/*/class, rather
<Kamion> fsmw: it's in http://people.ubuntu.com/~cjwatson/base-config-po/
<fsmw> Kamion, ok i see, that typo was in the last two ubuntu releases.
<jbailey> mjg59: 'kay. Hmm
<jbailey> That could actually be nice a few ways.
<Kamion> fsmw: yes, it came from an Ubuntu-specific translation and nobody corrected it until the other day ...
<jbailey> I could generate a queue of them, and defer some of the loading to the local and nfs scripts.
<jbailey> That way the nfs mount doesn't bother loading local devices, and local doesn't bother with NICs.
<fsmw> i see it, i was looking to patch it, is there some file not translated to spanish?
<Kamion> I don't understand
<jbailey> mjg59: A concern I have about delaying the loading of the usb controller is that I already have to have a sleep 2 in there to let the usb bus scan catch up in case there's a device on there.
<mjg59> jbailey: Hmm.
<mjg59> jbailey: The timing ought to work out the same overall, though - we're effectively just reordering stuff
<jbailey> That would be resume faster, but possibly cause me to have to up the timeout since we'd be just waitingon the controller.
<jbailey> Right 'cept that the bus scan happens while other thing happens right now.
<mjg59> Ah
<mjg59> Well, the unplug/replug dance would also be bad
<mjg59> It gives a small race
<jbailey> Yeah.
<jbailey> Noone I've asked has been able to tell me how to tell if a bus scan is completed from userspace.
<Kamion> fsmw: look for fuzzy or untranslated messages in the two URLs I gave above, as well as http://people.ubuntu.com/~cjwatson/shadow-po/
<mjg59> jbailey: Ok, anything with a class of 0x01.... is a storage controller
<Kamion> fsmw: then send me the updated .po files and I'll merge them after the preview release
<mjg59> 0x02.... is a network controller
<Kamion> cjwatson@ubuntu.com
<fsmw> ok Kamion
<mjg59> See /usr/include/linux/pci_ids.h
<jbailey> mjg59: 0x01 for all of SCSI, IDE and SATA?
<mjg59> jbailey: Let me check for SATA, certainly SCSI and IDE
<jbailey> If you don't have one handy, I can hop onto one.
<Kamion> fsmw: as I said, it tends to make my life more difficult if you change already-translated messages that come from Debian; if you could send changes to that upstream, I'd greatly appreciate it
<fsmw> i see you mean, send the translations to debian team?
<jbailey> Looks like class 0x01018f
<Kamion> fsmw: yeah, the Last-Translator: field and/or debian-i18n@lists.debian.org
<fsmw> ok
<fsmw> thanks!
<mjg59> jbailey: SATA has the same class as IDE
<Kamion> thanks to you
<fsmw> btw thanks for your work at ubuntu, is really great
<jbailey> Oh, I see. I didn't see the ... after your 0x01 =)
<jdub> fsmw: how are we doing in chile? popular?
<fsmw> jdub, we're giving ubuntu cd's in our GNOME meetings, we're doing one GNOME meeting by month
<fsmw> next one will be september 10
<jdub> awesome!
<jdub> SOFTWARE FREEDOM DAY!
<Robinho_Peixoto> what the command do you use for create a patch ?
<fsmw> of course meetings are arround the country
<jbailey> mjg59: I'll have to think about how to rearrange this then to split that up.  Right now the resume stuff happens in local-premount, by which time all the usb bits have to be loaded for booting.
<Kamion> Robinho_Peixoto: diff -Nru or similar
<fsmw> unfortunatly i miss the last one, and due to the death of my brother in law i don't know if i'll attend to the next one
<Kamion> between old and new trees
<mjg59> jbailey: Yeah
<Robinho_Peixoto> Kamion: The result is very different
<mjg59> jbailey: If we unload and reload there, then you have no idea how long the bus rescan is going to take, which is a pain if / is on USB
<fsmw> on the other hand i use ubuntu at the university so my students use it too ;-)
<Kamion> Robinho_Peixoto: different from what?
<Kamion> and in what way?
<lamont-away> daniels: ping
<jbailey> mjg59: Right, lots of suckage.
<jbailey> I'd have to do something clever like reload only if there was an image in the swapfile.
<jbailey> Doable, but way too fUgly.
<Kamion> Sigh. I should really learn to run CD builds under screen.
<fsmw> Kamion, as i see you have some files not updated, there are some typos fixed in d-i svn
<Kamion> fsmw: the last mass sync we did was in July
<fsmw> i see
<Kamion> since that was upstream version freeze, we haven't been routinely pulling in new translations since then
<Kamion> and it gets quite difficult to do so as code and English strings diverge along with translated strings ...
<hmrocha> hello
<hmrocha> i updated my breezy packages yesterday and today i noticed that "lock screen" is different
<hmrocha> it's great btw
<hmrocha> but it would be much better if you could add the amount of time the computer has been locked
<jdub> herzi: how up to date is your hula package in universe?
<mvo> Kamion: amd64 install is coming along nicely here, all langpack dependencies work fine now! 
<herzi> jdub: not really
<Kamion> mvo: great, thanks
<herzi> we should try to get alex' packages into universe
<mvo> Kamion: I have prepared a new notification-daemon that fixes some arrow drawing problems. is this something for after preview or can I do a upload before?
<mdz> morning
<mvo> good morning mdz
<herzi> jdub: i can work on that this weekend
<bddebian> Morning mdz
<Kamion> mvo: is that the thing where sometimes the notes end up in the top left-hand corner of the screen?
<mvo> Kamion: that and when the notification applet is placed in the bottom
<Kamion> mvo: I think that's OK, if that's the only change
<mvo> Kamion: ok, thanks
<jdub> herzi: no pressure, just interested ;)
<Kamion> damnit, powerpc daily overflows by 4MB or so
<Kamion> mdz: it's really getting tempting to kill thunderbird from the powerpc CD
<Kamion> mdz: (it's either that, or language packs like Japanese, German, and French ...)
<tortoise_> can someone confirm this bug for me, searching using the gnome search tool always searches your home directory what ever directory one selects for searching.
<mdz> Kamion: fine with me
<mdz> Kamion: likewise for emacs
<jdub> Kamion: removing gimp would give you a nice boost
<jdub> Kamion: i'd prefer to see it out of the desktop seed than not shipping thunderbird on the cd
<herzi> svenl: ping
<Kamion> jdub: removing stuff from desktop on one architecture is harder
<jdub> Kamion: happy for it to be done for all
<Kamion> you serious?
<jdub> yes
<Kamion> gimp seems fairly headline
<jdub> it's also not fairly GCF :)
<jdub> (greatest common factor)
<Kamion> two mail clients is not GCF
<Kamion> one mail client is GCF
* jdub has been meaning to write up FirstAgainstTheWall spec :)
<jdub> Kamion: though, and it pains me to say it, i understand people choosing thunderbird over evo :)
<Kamion> what should people use to crop photos?
<jdub> gthumb
<Kamion> hmm
<jdub> f-spot
<Kamion> f-spot isn't on the CD
<jdub> details
<Kamion> important ones :)
<jbailey> jdub: I have to admit last I used the moz email client was pre mozilla-1.0
<jdub> ;-)
<jbailey> jdub: And *boy* was it bad. =)
<Kamion> GCF-wise, I feel happier about removing emacs than either gimp or thunderbird
<jdub> jbailey: thunderbird is OE to evolution's O (ie. far more attractive to most people)
<Kamion> although I admit to being a vi bigot
<elmo> I'm an emacs bigot
<elmo> and I'd be much happier to see emacs go than gimp or thunderbird
<jdub> Kamion: yeah, seems sensible (much bigger too)
* mvo agrees
<wasab1> Apple figured it out.
<jbailey> jdub: Ah interesting.  I wonder if I would find that, given that I dislike FireFox's UI and prefer ephy.
<elmo> I think jdub's entirely wrong about gimp too; it may not be "GCF", but it's a real win having it on the CD
<wasab1> Mail.app is a simple client, but also a kick ass corporate client.
<jdub> elmo: it's one of the first i'd remove when we have real pressure
<jdub> definitely emacs is more appropriate to remove first
<svenl> herzi: pong ...
<bddebian> emacs should be stricken from the planet
* bddebian hides
<mvo> daniels: around?
<jdub> jbailey: do you like IMAP that doesn't work like sucking uluru through a straw?
<Kamion> emacs21 it is, powerpc CD only
<Kamion> FirstAgainstTheWall++, by the way - I have to make this kind of decision at short notice moderately often when trying to get CDs out, and it'd be nice if the priority order for removal got some consideration rather than just whatever people around on IRC at the time happen to think :)
<jdub> ok, will do it some time :)
<jdub> maybe make it a small UBZ BOF
<Kamion> also, make smaller packages kthxbye
<jdub> s/BOF/session/
<jdub> j00 must add 7zip support to dpkg!!!111
<jbailey> jdub: Sure. =)  I've worked with the evo folks a few times to help with bugs.
<Kamion> naw, man, zoo is the way forward
<elmo> FirstAgainstTheWall needs some better rationalization than "I don't think many people use it"
<jdub> if the rationalisation were as such, we should remove from the CD straight away, rather than putting it on a priority list :)
<herzi> svenl: you told me about an image to set up the pegasos the way it was delivered, can you give me access to that image?
<Kamion> well, no, it does make sense to fill the CDs
<Kamion> but we need to know what falls off first
<elmo> jdub: that's a nice attitude and all but it's entirely disconnected from the reality of what's on our CD
<jdub> we have > 650MB of GCF worthy packages :)
<jdub> elmo: wow, i don't think so - and i don't think organic growth since warty has had a negative impact on it either
<jdub> our desktop seed is remarkably focused
<svenl> herzi: no chance. i can make you available the newer version though.
<elmo> haha
<svenl> herzi: what do you want exactly though ? It is something like 3GB of data in total.
<herzi> well, i'd like to be able to re-stage it before i start to start modifying the stuff (re-partitioning, etc)
<herzi> svenl: it would be okay if you can burn it on a dvd and give it to me once we meet again
<svenl> herzi: ah, ok.
<svenl> herzi: well, my problem is with my upload, but i have the (newer) images at ppczone, in separate pieces though.
<ogra> Kamion, :(
<ogra> Kamion, still no edubuntu-server installed...
<Kamion> ogra: which version?
<ogra> Kamion, and the late command to build the ltsp client wasnt called
<ogra> Kamion, .3
<ogra> Kamion, edubuntu-server is on the CD, but doesnt get copied to disk... the ltsp stuff gets copied but not configured by base-config
<svenl> herzi: you do know how to build ubuntu-installer ? 
<Kamion> ogra: check /preseed/edubuntu.seed on the CD, make sure it looks right
<ogra> yup, a second...
<Kamion> ogra: then e.g. 'echo GET base-config/late_command | debconf-communicate' please
<Lathiat> mjg59: so, i definately get a lid up event but it doesnt wake my screen up, i can tell cus if i put my switch down, then hit the keyboard to unactivate it then watching the log i lift the switch back up and an event fires
<ogra> Kamion, the edubuntu.seed looks ok
<ogra> Kamion, but it doesnt seem to get run by default....
<Kamion> oh, meh, I'm a moron
<Kamion> that has never worked for edubuntu
<Kamion> fixing
<Kamion> look for DEFAULT_PRESEED in debian-cd/tools/boot/breezy/* and you should see the problem fairly quickly
<ogra> Kamion, where would i find that dir ? 
<Kamion> ogra: never mind
<Kamion> (but colin.watson@canonical.com--2005/debian-cd--ubuntu--0)
<ogra> :)
<ogra> ah
<mjg59> Lathiat: Ok. Can you stick a set -x in /etc/acpi/lid.sh and see what code it executes when you open the lid?
<Kamion> ogra: fixed, will do you another rebuild once cdimage isn't maxed out doing other things
<ogra> oki
<Lathiat> [Fri Sep  2 23:56:33 2005]  received event "button/lid LID 00000080 0000000b"
<Diziet> My debconf database has an entry in it owned by `unknwon'.
<ogra> ping meif its there :)
<Lathiat> [Fri Sep  2 23:56:53 2005]  received event "button/lid LID 00000080 0000000c"
<Lathiat> (down, up)
<Kamion> debconf (1.4.51) unstable; urgency=low
<Kamion>   * Colin Watson
<Kamion>     - Fix spelling of "unknown" in copied database items with no owners.
<Kamion>  -- Joey Hess <joeyh@debian.org>  Wed,  8 Jun 2005 23:03:01 -0400
<Kamion> Diziet: ^--
<Kamion> ogra: I'll be gone by then, as I'm going to watch a play this evening; I'll kick it off before I leave but you'll have to watch for it yourself
<Diziet> k: Aha.  Should we have that in breezy ?
<pef> someone can help me about the GLUTransition ?
<Lathiat> pef: whats up'
<Kamion> Diziet: yes; stuff copied as part of the hoary install will still have it though. It's not really worth the trouble of a migration script as far as I know.
<Diziet> Right.
<Diziet> Oh, yes, there it is.
<Kamion> (did you just find it while browsing?)
<pef> Lathiat: I have xlibmesa-gl | libgl1, xlibmesa-glu | libglu1 as recommends in a debian/control file, shoud I replace them with libgl1-mesa | libgl, libglu1-mesa | libglu ?
<pef> Lathiat: the problem is with libgl1 and libglu1
<Lathiat> pef: oh you have something with dependencies not just build-deps?
<Lathiat> pef: what package?
<pef> Lathiat: galan (and I find this strange in Recommends field, no ?)
<Lathiat> interesting
* Lathiat pkgstats
<Diziet> Ahhh, I seee.  It's asking me once about the ispell dictionary and once about the wordlist.  I think that's silly.
<Lathiat> pef: thats... most interesting
<Lathiat> pef: ask infinity or daniels im not totally sure 
<Lathiat> pef: but sounds possibly ok
<Kamion> Diziet: there's something generally wrong with the dictionaries-common infrastructure - it should apparently be inheriting default answers from the installer (e.g. en_GB => wbritish, that sort of thing), but isn't
<pef> Lathiat: so libgl and libglu will be another non currently existent packages
<Diziet> k: That would be sensible.
<Diziet> Do you know who's looking into this, if anyone ?
<Lathiat> pef: so, libglu1-mesa | libglu1, libgl1-mesa | libgl1
<Lathiat> pef: i think
<ogra> Kamion, ok, thanks for all
<Kamion> Diziet: I sent a mail to ubuntu-devel and dict-common-dev earlier today about it, and got a reply from one of the dict-common-dev maintainers
<mjg59> Lathiat: Did you put the set -x in the script file? You should get more output than that
<Kamion> Diziet: I won't have time to look at it more until Monday, though; I've just applied a band-aid to get us past the next CD release. As far as I know nobody else is looking at it.
<pef> Lathiat: ok, thanks, will ask to Daniel for confirmation
<Lathiat> mjg59: yeh there is i can msg it to you
<Lathiat> mjg59: doesnt seem to give any more output than with +x tho
<mjg59> Lathiat: Hm.
<Kamion> Diziet: if you're talking about a first-time install, I suspect the problem is that dictionaries-common's guessing doesn't work if dictionaries-common is installed in one apt run and then the wordlists themselves are installed in a second apt run.
<Lathiat> http://bur.st/~lathiat/lid.txt
<daniels> mvo: hm?
<Kamion> This happens in our scenario, because we install the desktop first and then language-support-* after that
<mjg59> Lathiat: Uh. Put set -x in the file, don't chmod -x it :)
<Lathiat> oh
<Kamion> (they're in separate runs so that the desktop still gets installed even if language-support-* is uninstallable)
<pef> daniels: I have a problem with GLUTransition
<Lathiat> like, put "set -x" on a line at the top?
<mvo> daniels: I send you a mail about a dri problem on the r200 because I thought you might be sleeping or something 
<mjg59> Lathiat: Yeah
<mjg59> Lathiat: Just after the /bin/bash bit
<rubenv> Lathiat: I tested your i8k suspend config again
<Lathiat> updated
<lamont-away> Kamion: mdz: if a package is FTBFS in the archive (but binaries are present), can I still upload fixes for the FTBFS?
<Lathiat> rubenv: no luck?
<daniels> mvo: ah, okay
<Lathiat> rubenv: works for me ;p
<daniels> pef: do tell
<lamont-away> given the freeze and all that
<rubenv> Lathiat: doesn't work here, but the opposite config does work
<rubenv> Lathiat: what bios have you got?
<Lathiat> rubenv: A14
<Lathiat> rubenv: A13 also works
<rubenv> hmmm, mine has an A12
<mjg59> Lathiat: The xscreensaver-command -deactivate bit really should be turning your screen back on
<pef> daniels: oups, misunterstood, think you are dholbach, sorry ;)
<Kamion> mjg59: from that log it looks like 'su - $USER' should be 'su $USER'
<rubenv> I never update my bios (no win), but my replaced bios came with A12
<Lathiat> mjg59: well uh, it doesnt? ;p
<Diziet> k: No, I'm talking about an upgrade from hoary.
<mjg59> Kamion: Yeah, true
<Kamion> Diziet: oh, um, ok; that could be related but I don't know anything about that scenario
<rubenv> Lathiat: we need a third opinion ;-)
<mjg59> Lathiat: Well, it's documented as ding so and works here...
<daniels> pef: no worries!
<Kamion> mjg59: could make a difference if :0.0 is owned by a different user?
<Diziet> k: OK, well, I'll put it on my list of things to investigate.
<Kamion> Diziet: congratulations, you're looking into it ;-)
<mjg59> Kamion: Yeah, but I can't see any way that that could be happening
<mjg59> Kamion: In that case there'd have been an error from xscreensaver-command
<Kamion> ah, yes
<Lathiat> mjg59: hrm
<hmrocha> do you think you could show the amount of time the computer has been lock in the new "lock screen" image?
<hmrocha> it would be a great feature for my faculty
<Lathiat> mjg59: so what does hitting the keyboard do
<Kamion> lamont-away: if they're fixing only the FTBFS, and fixing that doesn't involve major changes (like binaries jumping from a much older version because no version since then managed to build), I'd say that's fine
<ogra> hmrocha, its a very intrusive change to do that, we are near preview release...
<Lathiat> mjg59: well, xset dpms force on works
<Lathiat> (xscreensaver-command --activate; sleep 2; xset dpms force off; sleep 5; xscreensaver-command --deactivate; xset dpms force on)
<lamont-away> Kamion: I'm thinking trivial stuff like missing build-deps/missing includes
<lamont-away> Kamion: these are the breezy-autotest failures: we have a binary with that version in the archive, but it is now FTBFS if you try to rebuild
<lamont-away> (and it's also probably just plain FTBFS for poor little hppa/sparc)
<mjg59> Lathiat: Hmm. If you edit lid.sh and put an xset dpms force on just above the xscreensaver bit, does it work?
<Diziet> The xserver-xorg config script tries to build a list of available drivers by looking in /usr/lib/xorg etc. in its config script.
<Lathiat> mjg59: yep
<Kamion> Diziet: whoa, no wonder it doesn't work
<mjg59> Lathiat: Ok
<mjg59> Lathiat: It seems that xscreensaver doesn't always succeed in doing the dpms transition itself
<Kamion> lamont-away: fine for the next couple of days anyway; after that we do have to lock down more so that we have consistent CD images everywhere
<lamont-away> Kamion: OK.
<lamont-away> Kamion: scream when we lockdown, OK?
<Lathiat> mjg59: any chance of making that    
<mjg59> Lathiat: Yeah, just including it now
<Lathiat> mjg59: .. the default ;p
<Kamion> lamont-away: yeah; I should imagine on Monday/Tuesday we'll want to just stop making changes so we can sit and test
<Lathiat> sorry my ssh got cut off
<lamont-away> Kamion: ok
* lamont-away -> office
<jdub> it'll grow back
<Lathiat> mjg59: thanks
<Diziet> daniels: ping
<daniels> Diziet: be quick
<daniels> Diziet: i'm just on my way out to bed
<Diziet> Ah, hello :-).
<Diziet> You made a change to xorg:
<Diziet>   * Fix module searching in xserver-xorg.config.in (closes: Ubuntu#14430).
<Diziet> But 14430 is something about gksudo.
<Riddell> elmo: pong
<daniels> Diziet: maybe 24340?
<daniels> er, 14340
<Diziet> That looks more like it.
<Kamion> #14340 was the xorg-commin typo
<Diziet> Oh, so it is.
<Diziet> Did you change it to make it run find in /usr/lib/xorg/modules in the config script, or did it do that already ?
<elmo> Riddell: could you take a look at the noatun-plugins bug pls?
<elmo> Riddell: should be easy transition thing
<daniels> Diziet: i changed it to deal with /usr/lib/xorg/modules earlier
<elmo> I'd assign it to you, but someone fascisifed our bugzilla
<daniels> Diziet: i fixed it to ... well, to work ... in -55
<daniels> or -56 or whatever
<daniels> it's definitely bedtime
<Riddell> elmo: what's the bug number?
<daniels> seb128: btw, you're right about that gnome-applets/xkb bug, could you please close it as it's fixed by now
<Diziet> OK.  I'll try to catch you about this on Monday.  I don't want to just start messing with things until I understand why they're the way they are.
<Kamion> daniels: that seems optimistic in a .config script
<Kamion> which runs before unpack ...
<elmo> Riddell: 14552
<Diziet> Let the poor guy go to bed :-).  I've got plenty else I can be faffing with.
<daniels> Kamion: i guess that would explain why we always fall back to the architecture default list.
<daniels> Kamion: it's a brandenism
<Diziet> I noticed it because it prints an error message.
<Kamion> well, "runs before unpack" -> "sometimes runs before unpack", anyway
<daniels> Diziet: oh, sweet.  what's the error message?
<Kamion> yeah, what the man said, get some sleep
<Diziet> During hoary -> breezy.
<daniels> Kamion: obviously we need to have xserver-xorg p-d on all the drivers then.
<Diziet> /usr/lib/xorg/modules/somthing: ENOENT
<Diziet> and then it carries on anyway.
<Kamion> daniels: that doesn't help for .config
<daniels> Diziet: okay, I'll probably just 2>/dev/null that one
<Diziet> No no no.
<Kamion> it's run before *anything's* unpacked
<daniels> Kamion: oh right, some times it gets run bef ... yeah, that
<mvo> mdz: can you please change the default gnome-app-install bugzilla qa-contact to "niran@niran.org"?
<daniels> Diziet: (we do find /usr/X11R6/modules/ /usr/lib/xorg/modules/ -name '*_drv.*'
<Diziet> Indeed.  But in this case, /usr/lib/xorg/modules doesn't exist.
<daniels> right
<Diziet> Yet.
<Diziet> This is just fundamentally incorrect.
<Diziet> If you need information about what's installed, you have to do it in postinst.
<daniels> Diziet: /usr/lib/xorg/modules only exists in our brave new modular server world
<daniels> Diziet: we don't *need* it as such, but it is nice
<Kamion> ([ -d /usr/X11R6/modules ]  && find /usr/X11R6/modules/ ...; [ -d /usr/lib/xorg/modules/ ]  && find /usr/lib/xorg/modules/ ...), anyway
<elmo> Kamion: any objection to me removing anything but the current installer image from hoary + warty?
<daniels> Diziet: it's not mine, I inherited it and tweaked it
<elmo> kamion: i.e. trash daily-installer-* and the T-1 and T-2 in installer-*
<daniels> but I think I'll probably end up moving all of .config to .postinst
<Diziet> Definitely don't just 2>/dev/null the messages.  That's just a recipe for deeper mysteries.
<Kamion> elmo: let me just check the .jigdo files
<daniels> Kamion: yeah, but getting the output right (it's multiply sedded and grep -v'ed) was enough of a pain in the arse that this was easier
<daniels> anyway, 0234
<Diziet> Anyway, do you want me to pass the buck to you or do you want me to put it on my todo list ?
<daniels> this seems to be my bedtime of choice
<daniels> Diziet: pass the buck, it's a quick fix
<Lathiat> mjg59: hrm, open screen -> screensaver comes on, dont unlock -> close screen -> screen doesnt go off -> open again, unlock... after a few seconds the screen blacks
<Diziet> I'm not sure I approve of your quick fix, but fair enough.  It'll avoid me building X here :-).
<daniels> Diziet: i have a different quick fix in mind
<daniels> -d /foo && PATHS="/foo"; -d /bar && PATHS="$PATHS bar"; find $PATHS -name ...
<daniels> foop
<Kamion> elmo: warty jigdos say installer-*/20040801ubuntu20; hoary jigdos say installer-*/20041227ubuntu24
<Diziet> danies: Sounds more sensible, yes.
<Kamion> elmo: anything else for warty/hoary is fine to trash
<Kamion> well, morgue, anyway :)
<Diziet> I'll file a Debian bug about the fundamentally wrong thing.
<mjg59> Lathiat: Ah. Interesting.
<mjg59> Lathiat: Sounds like an xscreensaver bug
<ogra> mjg59, ?
<elmo> Kamion: excellent, thanks
<mjg59> ogra: Hi
<ogra> hey mjg59 
<ogra> Lathiat, open screen == open lid ?
* ogra doesnt understand that sentence
<silbs> how many languages are on the CDs we ship? And is that number the same for live and install?
<silbs> (I'm updating the copy on the physical CD sleeves and would like to mention languages)
<Kamion> silbs: no, quite different, and it varies by architecture too, and I don't think we can give a concrete answer for the breezy release yet
<mjg59> ogra: It sounds like xscreensaver queues lock requests, rather than ignore them if it's already locked
<silbs> Kamion: how about a vague number, e.g., "more than X"?
<ogra> mjg59, *sigh*
<Riddell> elmo: that's part of kdeaddons which is the last part of the kde 3.4.2 upload that I'm about to get to nowish
<silbs> (where hopefully X can be something like 10, not 1 or 2)
<ogra> mjg59, this code is so odd...
<Riddell> mdz: the kdebase upload was part of kde 3.4.2 which was started ages ago but was waiting on xmkmf.  am I ok to finish it with kdeaddons and kdeartwork?
<Kamion> silbs: 12 for install/i386, 1 for live/i386
<ogra> powerpc has 2 less
<ogra> and amd64 has 12 too on install if i can count
<Kamion> amd64's the same for install and live; bizarrely live/powerpc has 12
<ogra> heh
<Lathiat> ogra: yeh
<Kamion> live/amd64 and live/i386 are both slightly larger than live/powerpc at the moment; I'm not sure where the difference lies
<Lathiat> mjg59: is it? is xscreensaver what initially blanks the screen?
<Kamion> oh, many fewer X drivers
<silbs> Kamion: thanks
<mdz> Riddell: we are in preview freeze now; are they critical for preview?
<Lathiat> mjg59: ok so 
<Kamion> silbs: I do think we need to get that number up, but I don't know where to get the space from at the moment
<Lathiat> mjg59: the xset dpsm force off should still work
<Lathiat> mjg59: which, it doesnt
<Kamion> going back to the FirstAgainstTheWall thing from earlier
<Kamion> python-* would be an obvious place to start, but I like having my job ;)
<ogra> Lathiat, xscreensaver handles dpms itself additionally... probaly they clash
<Lathiat> ogra: ah ok
<Lathiat> ogra: be nice if that worked
<mjg59> Lathiat: Mm?
<jdub> Kamion: there are some python things that could be stripped tho
<mjg59> Lathiat: I'm afraid I don't understand the current situation
<Kamion> jdub: well, I agree, but I always thought that
<ogra> Lathiat, i'll look at it, but i cant promise anything...
<mjg59> Lathiat: You close, open, close, open, unlock and then it relocks?
<Lathiat> ogra: ok
<ogra> mjg59, its a dpms problem...
<Lathiat> mjg59: no
<mjg59> Lathiat: Ah
<ogra> it doesnt lock again, but blanks
<Lathiat> mjg59: i close, open, the unlock dialog comes up, i then close it again, the dpms doesnt turn it off
<mjg59> I've misunderstood
<Lathiat> however when i do finally disactivate the screensaver
<Lathiat> some kind of queued dpms off happens
<Lathiat> so im gussing that screenblank doesnt return
<mjg59> Lathiat: Oh. Christ.
<Riddell> mdz: depends if slang transition is critical
<Lathiat> until it unlocks
<Lathiat> err, the xscrenesaver part of screenblank
<mjg59> Lathiat: Uhm. Yeah, which still sounds like an xscreensaver problem. Hrmph.
<mjg59> Possibly that should just be backgrounded
* mjg59 backgrounds it
<Lathiat> i'll test that
<mjg59> Which would then unambiguously make it an screensaver problem, and so not my problem :)
<mjg59> Lathiat: Just background the xscreensaver bit of it
<Lathiat> yep
<Lathiat> that works
<mjg59> Lathiat: Ok, cool
<mdz> Riddell: I wouldn't say so
<mdz> Riddell: how are the kubuntu CDs looking?
<Riddell> mdz: ok, so post preview then?
<Riddell> mdz: I havn't been able to test them, no cd burner here (kde conference)
<mdz> Kamion: what do you think about increasing the size limit in debian-cd?   both for purposes of error checking and having working images, it is better to have an oversized iso than an incomplete one
<mdz> Riddell: oh, I thought you were back.  when do you return?
<mdz> Riddell: the kubuntu CDs haven't seen much love, and time is short for preview
<Riddell> mdz: sunday, this week is hacking week
<Kamion> mdz: can I think about that later? I have to be five minutes' drive away in ten minutes' time
<mdz> Kamion: ok
<mdz> Kamion: will mail a reminder
<ogra> Kamion, edubuntu builds ? 
<Kamion> ogra: give me a second already
<Kamion> mdz: I have Edubuntu and Ubuntu CD builds running at the moment
<ogra> Kamion, err, mdz can do that too, right ? 
<ogra> ah, ok
<mdz> yes
<ogra> mdz, but they are already running apparently :)
<Kamion> mdz: the Ubuntu build I did just now was bad for a couple of reasons, but the next one should be OK; if people could test that this evening, I'd appreciate it
<pef> why some packages haven't the same name when I try to fetch them using aptitude ? (apt-get source iris works, but aptitude download iris not, aptitude download xmms-iris works)
<Kamion> I'll test it myself when I get back later
<Kamion> pef: source packages and binary packages often have different names.
<Mithrandir> Kamion: we should make d-i support multiple heads. :-P
<pef> Kamion: ok, thanks !
<ogra> mdz, if Kamion's change works the edubuntu CD is in preview state for amd64 and i386 ... ppc has a size problem i'll have to solve
<Kamion> Mithrandir: haha
<Kamion> pef: (it's not about apt-get vs. aptitude - aptitude's download command fetches binary packages rather than source packages)
<Mithrandir> Kamion: I think we might need to teach the linux console about multiple heads first, though. :-)
<pef> Kamion: is there a particular reason fo this difference of name ?
<jdub> Mithrandir: but i've heard kernel hackers referring to the linux console as a multiheaded beast!
<Kamion> pef: source packages often generate multiple binary packages
<pef> Kamion: oh right, I now understand, thank you !
<Mithrandir> jdub: my new setup here is _really_ sweet.  2 nice 17" LCDs and a dualcore athlon64.
<jdub> oof. yum.
<Kamion> pef: also, the source package is often just called whatever upstream call it, while the binary package may conform to some particular naming scheme (like libfoo-bar-perl for Perl modules)
<Mithrandir> I've just borrowed a 3800+ for a week until my CPU arrives, then I'll have a 4400+
<Kamion> although practice there varis
<Kamion> varies
* jdub is getting a 24" dell LCD, hopefully next week
<jdub> my eyes will be bursting with delight
<jdub> instead of pain
<jdub> ;-)
* Mithrandir decideds that xoog is a good host name
<Mithrandir> jdub: passive CPU cooler, passive cooling on graphics card, just two 12cm case fans and the really, really silent PSU fan.
* Mithrandir gives jdub a bucket to drool in.
<Mithrandir> :-)
<jdub> passive cooling == RAWK
<elmo> err
<elmo> this new xscreensaver lock thing is temporary right?
<Diziet> mdz: Did Keybuk talk to you about my dpkg conffiles fix ?
<mjg59> elmo: ?
<ogra> elmo, feel free to submit new artwork, i ave no objection to change the pic
<pef> bye !
<elmo> ogra: dude, I don't want to submit new artwork - I want us to use something !April-1st
<mirak> hi
<bddebian> Hello mirak
<mirak> I have some questions about initrd and kernel modules
<ogra> elmo, if anybody submits a 90 color indexed xpm with the right size to me, i'm fine with changing it ... and other suggestions are welcome too ...
<mirak> who loads the initrd, is it the kernel or the bootloader ? 
<mirak> how the bootloader manage to read all the linux file systems ?
<mjg59> mirak: The bootloader
<mjg59> mirak: By having code to do so
<mdz> Diziet: no
<mdz> Diziet: sounds like a post-preview change to me, though
<mirak> mjg59: I am still iinvestingating why this G3 can't boot ubuntu kernel 2.6.12-8
<Diziet> OK.  I don't have much of an opinion.  It's mainly to smooth upgrades.
<mjg59> mirak: If it's failing because it can't find the root filesystem, it's almost certainly an initramfs-tools bug
<mirak> mjg59: how can I know if the module for the ide device is in the initrd ?
<mirak> can I mount the initrd
<mirak> ?
<mjg59> mirak: Assuming you're using initramfs-tools, it's just a gzipped cpio archive
<mirak> mjg59: i don't use such tools, it's the kernel I got with apt-get
<mjg59> mirak: Which will be using initramfs-tools, assuming you're up to date
<mirak> ok
<mjg59> ogra: I'm not sure about the "someone else" thing
<mirak> what is a cpio archive ?
<ogra> mjg59, talk to mpt
<mdz> daniels: find: /usr/lib/xorg/modules: No such file or directory
<mdz> daniels: is that expected?
<ogra> mjg59, its his wording
<Diziet> How strange.  The openoffice.org2-l10n-en-gb postinst seems stuck talking to CUPS via HTTP.
<mjg59> mdz: Already been covered
<mdz> ok
<mjg59> ogra: And I really do follow elmo's opinion on the graphic, I'm afraid...
<ogra> mjg59, and he insisted he doesnt like the word user in any dialog... as well as "new login"
<mjg59> ogra: Also, the bullet points for the text aren't centred
<ogra> bullet points ???
<mirak> mjg59: how to extract it ? :(
<mjg59> ogra: The circles that appear when you type
<mjg59> mirak: Using cpio
<ogra> mjg59, thats a trivial change
<mdz> mjg59: did you and jbailey decide how to get usplash->mkinitramfs going?
<mjg59> ogra: I think they ought to be centred vertically in the box
<mjg59> mdz: Not yet
<Lathiat> mjg59: i noticed that on my screen, the progressbar cuts into the reeflection, however on my friends it doesnt, any idea?
<mjg59> ogra: I don't think it helps that the "Someone else" button looks quite like a text entry field 
<mjg59> Lathiat: Upgrade usplash and regenerate your initrd
<ogra> mjg59, ok, i'll put it on my list for after preview.... probably someone from the art team submitted a new picture by then and i can do both in one change
<mirak> mjg59: why do they use cpio and not gzip ?
<Lathiat> mjg59: how recent was that changed?
<Lathiat> cus i did that yesterday
<ivoks> ogra: could you help me with something?
<Lathiat> i'll try again
<ogra> mjg59, thst the button from the clearlooks theme...
<mjg59> Lathiat: Yesterday
<ivoks> ogra: on #ubuntu-motu?
<Lathiat> mjg59: ok
<mjg59> ogra: Yeah. But on that background, it looks like a text entry widget.
<mdz> mjg59: we need either that (preferable) or a workaround for the install, for preview
<mdz> jbailey: ping
<mjg59> mirak: It's a gzipped cpio file
<mjg59> mirak: That's used because that's what the kernel understands
<mjg59> ogra: Hm. Who are the people in the picture?
<ogra> mjg59, http://www.grawert.net/020505%20059.jpg
<mirak> mjg59: ok thanks I extracte it :p
<mirak> extracted
<sladen> ''CEO looks on as Ubuntu hackers stop off for some quick fun''
<ivoks> elmo: please, don't ignore me :) could you remove mozilla-firefox from universe in breezy? it's obsolete (ogra said it's ok)
<ogra> mjg59, if too many people complain i'll probably just switch to a plain color or so
<mjg59> ogra: I think a plain background with the Ubuntu logo would be fine
<ogra> but boring
<mjg59> Yeah
<mjg59> But the default artwork we ship /is/ fairly boring
<ogra> mjg59, i'd like something as cool as your usplash pic ;)
<ogra> mjg59, thats not boring at all...
<ogra> mjg59, but i was hoping someone from the art team might have something nice... so lets see and wait...
<ivoks> usplash is awsome!
<mirak> mjg59: I don't know what's wrong because the module is in
<mirak> jbailey: hey
<mjg59> mirak: Then file a bug against initramfs-tools
<mirak> mjg59: what bug can it be ?
<mirak> I don't understand where it can come from
<mjg59> mirak: I've no idea. I don't maintain that package.
<mirak> can you explain just a bit what the tools have to with that ?
<mirak> because the kernel is in the initrd
<mirak> hem the module
<mirak> cmd64x
<mjg59> mirak: Right, so it should be getting loaded and work. Except it isn't.
<mirak> but it doesn't seems it's loaded at all
<mjg59> mirak: Which means there's a bug in initramfs-tools
<mirak> ah
<mirak> ok
<mjg59> So please file a bug against initramfs-tools
<jbailey> mdz: pong
<jbailey> mirak: Hello
<jbailey> mirak: Lemme make sure I understand the backscroll right: The driver is in the initramfs-tools and not getting loaded?  Does it drop you to a shell prompt?
<Diziet> No, it's definitely a space alien and not a skull-and-crossbones.  But it's on the partitions it's going to erase.
<elmo> doko: or here even - please de-seed libneon23-dev
<Diziet> Ah, elmo, got you !
<mdz> jbailey: we need an answer for this usplash/initramfs issue 
<Diziet> Are you going to sort me out some md5sums files or shall I do my plan B ?
<doko> elmo: ok
<jbailey> mdz: For being able to rip and replace the usplash bits in the initramfs, right?
<elmo> Diziet: your md5sums broke ftp-master :P
<Diziet> Oops.
<elmo> Diziet: anyway, check out archive.ubuntu.com now, it has them
<Diziet> So it does, excellent.  (I'm sure it didn't a day or two ago ...).
<Diziet> Oh, damn, I forgot to ask for a find-ls.  (How come you don't have a find-ls ?  Does noone use Lee McLoughlin's mirror on debiand-format archives any more?)
<infinito> anyone here does know about d-bus?
<Diziet> I've half-read some of the manuals ...
<sladen> jbailey/mdz: for the moment could you just have a small packages that depends on usplash, linux-image-xxx.yyy and initramfs and regenerates the initramfs.  You can come up with something better later
<Diziet> inf: Are you seeing a usage message during dbus configure ?
<mdz> jbailey: for getting it enabled immediately when usplash is installed, and updated when usplash is updated
<infinito> Diziet: no, i just want to know if it can be used to mintor if a device is being used
<elmo> Diziet: you mean ls-lR?
<elmo> Diziet: does 'mirror' need the uncompressed version, or can I ship with just .gz?
<elmo> Diziet: and no, AFAIK most people use rsync or debmirror these days
<ogra> infinitdbus only forwards messages between processes
<ogra> infinito, you can have two apps (one that monitors, one that displays) using dbus indeed
<infinito> ogra: uff yes..... excuses.... i didnt remember
<Diziet> elmo: ls-lR or find-ls; either will do for me or Lee McLoughlin's program (which is not what I'm using).  And gzipped is fine.
<Diziet> I'm going to package up magicmirror because it's incredibly cool.
<infinito> ogra: whats the best way to see if /dev/video is being used?
<mdz> jbailey: it seems increasingly reasonable for usplash to regenrate the initramfs for the default kernel if it is an official initramfs kernel
<hunger> mjg59: Great solution for the acpi-support with hda problem! Works great!
<ogra> infinito, lsof probably, or fuser
<ivoks> elmo: thank you :)
<Diziet> magicmirror can dedupe via hardlinks across mirrors of different things.  Just the thing for n debian-derivatives.
<sladen> what about having the kernel package install an alternatives script that usplash can call if it exists...
<mdz> jbailey: the only issue would be determining whether that is true
<infinito> ogra: thanks :)
<mdz> jbailey: if necessary, patch kernel-package to provide that information via a public interface
<jbailey> mdz: Right, but the kernel could drop an md5sum /var/lib or something to track whether it generated the initramfs or not.
<jbailey> And then anything interacting with it could update that easily enough.
<mdz> jbailey: right, all this would be wrapped in an update-initramfs script anyway
<mdz> of which newer versions can be pulled in by future kernels if we decide to implement that
<mdz> jbailey: this should be your top priority as it is preview-critical
<jbailey> a'ight
* mjg59 goes out
<jbailey> mjg59: Bah. ;)
<elmo> Diziet: ok, there's a ls-lR.gz now, or whenever the archive next pulses
<Diziet> elmo: Excellent, thank you very much.
<siretart> elmo: I really don't want to annoy you, but could you have a look at the keys of ivoks and slomo? they both have quite a backlog of package that they want uploaded...
<jbailey> elmo: Thanks.
<jbailey> mdz: As part of this, should initramfs-tools update the current initramfs when it's upgrade too?  It's all the same mechanism at that point.
* Diziet goes to have some dinner.  TTFN everyone.
<mdz> jbailey: that sounds sensible
<mdz> jbailey: during the freeze we won't be making disruptive changes to initramfs, and during development, it'll help get immediate testing for your changes
* jbailey nods
<mdz> jbailey: I wouldn't feel comfortable about this with mkinitrd, but mkinitramfs is thankfully a lot more deterministic
<jbailey> *lol*
<mvo> ping jamesh (not sure what TZ you are currently in)
<Riddell> elmo: can you update the chroot on novo
<elmo> Riddell: hum, doing
<jdub> http://www.gnome.org/~jdub/blog/projects/ubuntu/1125687160
<jdub> ^ READ IT AND WEEP
<Nafallo> jdub: that's not northern, Sweden is northern ;-)
<jdub> argh, i just got four autoreplies from my announce mail
<jdub> and all four were from germans!
<ogra> jdub, not me :)
<sivang> jdub: what was the announce email about?
<jdub> sivang: http://www.gnome.org/~jdub/blog/projects/ubuntu/1125687160
<ogra> sivang, ubuntu-devel :)
<jdub> BadgerBadgerBadgerTour!
<ogra> yay
<sivang> ogra: ah yaya!!
<sivang> whee
<sivang> jdub: are you coming here sometime soon? ;)
<jdub> sivang: heh, not on the plan so far, but maybe :)
<jdub> sivang: get ilug to send a petition ;)
<sivang> jdub: I'll try that, yeah
<Treenaks> jdub: Care to celebrate my birthday in Amsterdam? (18-oct) :)
<Treenaks> jdub: over a beer
<Treenaks> jdub: (that's in the middle of EuroOSCON)
<Treenaks>  I'll mail it :)
<lamont> ENOPITTI
<jdub> Treenaks: rock on :)
<jdub> Treenaks: put yourself on the wiki page :)
<hmrocha> hello
<hmrocha> is it possible that you add a timer to lock screen? so that the users know for how long the computer has been locked?
<bur[n] er> hmrocha: i think at this stage in the game, a new feature might be out of the question
<hmrocha> but the new lock screen was added yesterday!
<bur[n] er> really?  i thought there was a feature freeze
<hmrocha> i updated the packages last night and today, when i locked the screen, it appeared a box asking for a password and a new button to let me switch to another user
<mvo> bur[n] er: that was sort of a exception, it was just re-added and is around since hoary (more a regression-bugfix than a feature)
<hmrocha> it's a great feature being able to switch to another X session
<mvo> hmrocha: ^----
<hmrocha> mvo, what's that?
<mvo> hmrocha: I was answering to the "but we are in feature-freeze" questions some lines below :)
<mvo> (just to bring it to your attention)
<hmrocha> ok
<mvo> and not below but above :)
* mvo should go to bed or something
<hmrocha> i'll wait for the feature to be included in a future version :)
<hmrocha> breezy is much better then hoary :)
<mvo> hmrocha: you may want to file a wishlist bug, but it's likely that the next release will use gnome-screensaver instead of the current xscreensaver 
<ogra_ltsp> very likely
<mvo> even that :)
<ogra_ltsp> ;)
* mvo waves to ogra
<hmrocha> where can i file a wishlist bug?
* ogra_ltsp is sooo happy about the status of the edubuntu CD now :-D
<mvo> hmrocha: bugzilla.ubuntu.com
<hmrocha> thanks
<hmrocha> are you thinking about including beagle by default in the next version of ubuntu?
<mpt> ogra_ltsp: If it's any consolation, OS X also queues lock requests rather than ignoring them if it's already locked. The other day kiko fiddled with the catch on my iBook's lid, and sent it into a *permanent* loop of sleep -> unlock dialog -> sleep -> unlock dialog -> sleep -> ...
<mpt> ogra_ltsp: Do you have a screenshot handy of the current unlock dialog? (My Breezy laptop's at home)
<ogra_ltsp> mpt, i dont think xscreensaver does, that was a wrong assumption from mjg59 for a different problem...
<ogra_ltsp> mpt, currently not... i'll take one for you as soon as i can (xnest doesnt work on ltsp)
<mpt> "Someone Else..." works only if the person currently logged in has their name in big letters at the top
<ogra_ltsp> it has...
<mvo> hmrocha: beagle is available in universe
<mpt> otherwise, it's "else what??", so "New Login..." would indeed work better
<mpt> It's also very weird to have a button for starting a new session but not a button for resuming the existing one, but you can't do anything about that right now
<ogra_ltsp> its the same dialog i showed on the mockup screenshot before, just the unlock button is missing and the someone else button moved to the middle
<hmrocha> mvo, i know, i'm running it
<mpt> ogra_ltsp: :-/ I can understand why people would look at it and go "huh"
<mpt> ogra_ltsp: In that case, perhaps it should be moved right under the name
<ogra_ltsp> mpt, in fact i already have a bug "please change that background pic"
<ogra_ltsp> above the password stuff ... ugh...
<bur[n] er> lol
<ogra_ltsp> thats a lot of work.... moving stuff around there isnt really easy
<ogra_ltsp> (not a lot of work, but time consuming)
<mpt> Sorry, if I'd known the OK button wasn't going to be possible, I would have moved the other one from the outset
<mpt> roll on gnome-screensaver :-)
<ogra_ltsp> mpt lets talk about changes after preview, i cant (shouldnt) change it now anyway
<mpt> sure
<mvo> mdz: could you please make "kov@debian.org" the default qa contact for gksu bugs?
<mdz> mvo: you now have editcomponents privileges and can do it yourself ;-)
<mvo> mdz: I can? then I will do that, thanks :)
<ogra_ltsp> mdz, edubuntu starts looking really good :)
<ogra_ltsp> mdz, two little glitches left... (dhcp server doesnt start after installation and base-config/late-command ltsp-build-client isnt run yet)
<ogra_ltsp> mdz, else its in its ready
<ogra_ltsp> s/in its//
<mdz> ogra_ltsp: ltsp-server-standalone should restart dhcp3-server in its postinst; if you could send me a tested patch that would be great
<ogra_ltsp> mdz, i'll do but tomorrow...
<mdz> yep
<ogra_ltsp> mdz, could the nfs timeout be on the server side?
<mdz> ogra_ltsp: glad to hear it's looking good
<mdz> I'll see if i can try an install over the weekend
<ogra_ltsp> i think if i have another short session with kamion about base-config we're done
<mdz> ogra_ltsp: it's possible, but traffic traces seem to point to a client fault
<ogra_ltsp> i think i saw it go away when i restarted portmap, i'll do some tests tomorrow
<mvo> ping ogra_ltsp 
<ogra_ltsp> pong mvo
<mvo> ogra_ltsp: do you got the /msg I send you?
<ogra_ltsp> mvo, about the cat ? 
<ogra_ltsp> mvo, grmpf
<ogra_ltsp>  Private messages from unregistered users are currently blocked due to spam problems, but you can always message a staffer. Please register! ( http://freenode.net/faq.shtml#privmsg )
<ogra_ltsp> heh
<mvo> ogra: oh, right
<zyga> hello everyone
<zyga> 2 hours on the bike after several years hurts :)
<mvo> hey zyga!
<zyga> mvo: hey, what's up? :)
<mvo> zyga: the usuall dance at freeze time, bugs bugs bugs :)
<zyga> mvo: did you hear about that issue with language-selector, it's supposed to pull country codes from some country-code package
<zyga> :-))
<zyga> good I'm not maintaining any package :)
<mvo> zyga: not sure, do oyu have a bug-number at hand?
<zyga> mvo: I'm not sure if anyone filed a bug
<zyga> mvo: I cannot remember who told me about it, carlos or jordi probably
<mvo> zyga: right now language-selector has it's own languages file for the mapping. that may be improved, right
<mvo> zyga: thanks, I'll get in touch
<zyga> mvo: does that mean l-s could jus dgettext(country_pack, country_name) ?
<mvo> zyga: the language file does only contain some mapping information (to map language-codes to human readable strings)
<zyga> mvo: yeah I know - I read the source
<zyga> mvo: but that means you could drop the sed scripts making .pot files and just pull everything from country-something 
<zyga> (assuming that they have everything that is)
<zyga> I'm not sure about the languages though
<mvo> zyga: good question, I'm not sure (and too tired) TBH
<mvo> zyga: do you think we could talk about it tomorrow again? it was a long day
<zyga> mvo: sure, I was just going to bed myself :)
<zyga> till tomorrow then
<mvo> zyga: cheers
#ubuntu-devel 2005-09-08
* mvo goes to bed now
<ogra> night mvo
<lamont> daniels: if I rebuild xaw3d, then I get no libXaw3d.so.6.1 (as of early july, it appears) - is that expected?
<Robot101> jbailey: ping
<Robot101> jbailey: why is mdrun not used in the initrds to assemble /'s md by UUID instead of device name?
<jbailey> Robot101: ...
<jbailey> Robot101: I do use mdrun in the initramfs...
<jdub> you may use it man, but do you UUUUUUSE it... maaaan?
<jbailey> jdub: Aren't you supposed to be asleep?
<Robot101> jbailey: oh... I was looking through p.u.c/~scott/patches/initrd-tools... but you've completely ditched mkinitrd?
<lifeless> jbailey: its 9am
<jdub> it's 9am!
<jdub> not that i actually went to sleep at all
<jbailey> Robot101: Right. =)
<jdub> regardless
<jdub> it's 9am!
<jbailey> Robot101: Seeking testers for the stuff before I upload it to Debian, but I think I might just start doing it.
<Robot101> jbailey: I'll give it a whirl now
<jbailey> jdub, lifeless: It's 9am on a *Saturday*
<jdub> SMELLY CANADIAN!
<jdub> BACK IN YOUR BOX!
<Robot101> jbailey: I can't switch from my own kernel to a stock kernel because mine uses /dev/hdX for my SATA, the stock uses /dev/sdX
<jbailey> Only because I've been hauling boxes.
<jbailey> Robot101: And you have a dislike of using SCSI device names? =)
<Robot101> jbailey: no, the stock uses libata for my VIA SATA, and my kernel config predates libata and I never changed it yet
<jbailey> Ah. =)
<jbailey> So something that'll need to change eventually, just not right now.
<Robot101> now I'm bored of compiling kernels, and I certainly don't want to have to hand-compile a kernel that uses libata soley so that mkinitrd can write the correct devices into /script
<jbailey> Oh, I see. =)
<jbailey> Yeah, mkinitrd sucks for a number of reasons.
<Robot101> how much will I need to pull from breezy to make this go?
<jbailey> Gimme a sec, I'll see what I can assemble for you.
<Robot101> will it work with a stock debian kernel or do I need ubuntu's?
<jbailey> It occured to me that there isn't a suitable busybox in Debian. =(
<jbailey> Pretty much any kernel should do.
<Robot101> I've got breezy in sources.list
<Robot101> I'll throw a few things in and see what happens :)
<jbailey> klibc, busybox-cvs and initramfs-tools then
<Robot101> jbailey: what other stuff does mkinitramfs do that mkinitrd doesn't? some udev funk and acpi...?
<tseng> jdub: are you coming to philly yet?
<jbailey> I think the only thing it does that mkinitrd doesn't is easy nfsroot.
<jbailey> Aside from that, it's just a much cleaner design.
<Robot101> I was having fun picking apart exactly what this initrd did
<Robot101> I had to scp it to my laptop because of course, my hand-rolled kernel on my desktop doesn't have cramfs either
<Robot101> :)
<jdub> tseng: you going to pitch for it? :)
<jbailey> cramfs is teh suck too.
<tseng> jdub: dunno, im not really in philly proper
<tseng> jdub: hannah is?
<Robot101> jbailey: how do I get this going then, just mkinitramfs -o /boot/initrd.img-2.6.12-1-k7 and give it a go?
<jbailey> Robot101: Basically, yup
<jbailey> You might not want to overwrite your working config. =)
<Robot101> well this is the point, initrd.img-2.6.12-1-k7 *doesn't* work :)
<jbailey> ;)
<Robot101> Kernel version too old.  initramfs-tools requires at least 2.6.12.
<Robot101> egg... chicken...
<jbailey> Err. 2.6.12-1-k7 *is* 2.6.12...
<Robot101> yes but that's the kernel I'm trying to get working, not the one I'm running :D
<jbailey> Can you please check to see how you're tripping the version check?
<jbailey> It shouldn't be checking the running kernel.
<jbailey> Oh!
<jbailey> I see.
<jbailey> You didn't pass it a verison number.
<jbailey> That would be bad.
<jbailey> mkinitramfs -o /boot/initrd.img-2.6.12-1-k7 2.6.12-1-k7
<jbailey> It doesn't attempt to parse your output filename, it assumes you want the running kernel version.
<Robot101> trundle trundle...
* Robot101 reboots :)
<Robot101> well that's a bit of an arse
<Robot101> it loaded the right module which has just wedged
<Robot101> sata_via... tum ti tum
<Robot101> then ata1: dev 0 ATA, max UDMA/133, 160086528 sectors
<Robot101> and then locked up
* Robot101 tries with no apic, that's never worked properly on his box
<Robot101> jbailey: rock, it worked!
<Robot101> jbailey: aha, /dev/pts isn't mounted
<Robot101> jbailey: is that usually in fstab on ubuntu?
<Robot101> hmm... no...
<jbailey> Umm, I think udev might mount that?
<jbailey> No, mountvirtfs does
<Robot101> that's odd
<jbailey> Swiching to stock kernels now should be as simple booting with it and changing the root= line in grub, I think.
<Robot101> with mkinitramfs you mean
<jbailey> Right.
<Robot101> I didn't need to change the root line because it's still /dev/md0
<Robot101> still puzzled by the pts lackage
<jbailey> Oh, I see. =)
<jbailey> I  hadn't realised you were on raid.
<jbailey> So in that case, yes, you shouldn't have to change anything.
<jbailey> It'll just autodetect all of that.
<jdub> Mitario: you in amsterdam?
<Mitario> jdub, umm, 'bout 50km
<Robot101> well the reason mkinitrd didn't work was because a) it didn't load my sata driver plus b) it hardcoded the path to my SATA drives as hdX
<Mitario> jdub, 1 hour by train :)
<Mitario> jdub, or do you actually mean now?
<Robot101> jbailey: can I put something in kernel-img.conf to use mkinitramfs from now on?
<jdub> Mitario: https://wiki.ubuntu.com/BadgerBadgerBadgerTour
<jbailey> Robot101: Right.  There's none of that hardcoded in there.
<jbailey> Robot101: Ubuntu's kernels will do it automatically.  I don't think Debian's kernels have the hack, but they might.  Try adding: "ramdisk = /usr/sbin/mkinitramfs
<jbailey> "
<jbailey> ISTR Fabio sent it off to Manoj, but I didn't track if it was accepted or not.
<Mitario> jdub, ah cool! well, I can always drop by :)
<jdub> Mitario: rad :)
<Robot101> jbailey: the funny thing is, mkinitrd will work for now... :)
<Robot101> actually, it might be too shit to work out that sda and sdb are from sata_via
<Robot101> scratch that, it is.
<jbailey> That logic always scared me.  It was so bloody fragile.
<Robot101> oh well, every time I pull down a stock kernel the next reboot will be an "oh shit" :)
<Robot101> until we burninate mkinitrd
* jbailey checks which channel we're in.
<jbailey> Oh good.
<jbailey> I can safely encourage you to just use Ubuntu here. =)
<Robot101> feh :P
<Robot101> its tempting actually, but I think at some point I'll go Xen and run debian and ubuntu at the same time :)
<Robot101> but probably sit at ubuntu and have debian in the background
<Robot101> :)
<Robot101> just because I can really...
<jbailey> ISTR a recent announcement saying that we're going to Xenify our stuff sometime.
<Robot101> yeah, xen 3.0 actually works now
<jbailey> Ah, handy.
<Robot101> like acpi, apm and stuff
* jbailey checks for ppc support/
<Robot101> I'm surprised ppc support has been so long coming
<Robot101> ooh, the Debian images do have ramdisk =
* Robot101 fixinates
<tseng> jdub: i cant comment on your blog post about pyjamas
<tseng> jdub: it is calling out to me
<elmo> xen-3 is out?
<Robot101> elmo: poorly phrased, I meant xen 3.0 will actually work on most hardware
<xTina> Hm, is there a known bug with dpkg > 1.10.27ubuntu1 (e.g. the one built against the fixed zlib) that causes the unpacking step of apt-get install kubuntu-desktop on a fresh system to fail reliably (but sometimes with different packages) if dpkg has been updated beforehand? 
<xTina> I tried it repeatedly on multiple systems with automated installs -- if I insert a dist-upgrade before installing kubuntu-desktop, the installation fails in 90% of the attempts, if I keep the old dpkg until kubuntu-desktop has been installed it works 100%.
<jbailey> Robot101: Anyhow, anything esle you need?  I think I'm otherwise going to wander away for the evening.
<Robot101> jbailey: no I'm hugely grateful, and encourage you to spread mkinitramfs far and wide :)
* Robot101 qualifies above remark about PPC support in Xen by adding that when Xen was released, a security reasearch team chipped in and said "oh yeah we've been doing that on PPC for 2 years, we'll merge it in"
<Robot101> team in IBM, even
<jbailey> Robot101: Lovely.  Yeah, I need to get around to merging that in to Debian.  *sigh*  Too much to do. =)
<Robot101> jbailey: anything I can help with?
<Robot101> jdub: couldn't tempt you up to cambridge for bit when you're in london? :)
<jbailey> Robot101: If you'd be willing to help negotiate  adding busybox-initramfs to whichever busybox is being maintained, that would be lovely.
<Robot101> jdub: add * drink ale with debian-uk in cambridge :)
<jbailey> In Ubuntu, busybox-cvs is more recent, but I think the busybox package is a better choice in Debian.
<jdub> Robot101: i'll put a ? ;)
<jbailey> Robot101: If someone is actively caring about this, it's incentive to beat klibc into shape.  initramfs-tools is just a simple upload.
<Robot101> jdub: post to debian-uk@chiark.greenend.org.uk and fix a date :)
<Robot101> jdub: or badger people in #debian-uk on OFTC
<tseng> you said badger
<jdub> "Catch up with RobertMcQueen, ColinWatson and the whole Cambridge debian-uk mafia?"
<jdub> ^ haw haw
* tseng does the peewee bit about running around screaming
<Robot101> jdub: I'm not a very high ranking member of the UK cabal :D
<jdub> Robot101: anyway, you should post :)
<Robot101> jdub: to what, my blog? :)
<jdub> debian-uk :)
<Robot101> oh right
<Robot101> I thought you'd found a comical hackergotchi for me :D
<Robot101> http://images.google.com/images?q=robot
<Robot101> :)
<Robot101> jdub: any particular date preference?
<Robot101> jbailey: ahh, I worked out the pts problem
<Robot101> jbailey: it's because I've not been able to upgrade udev :)
<Robot101> jbailey: because of being on <2.6.12
* Robot101 tries that
<jbailey> Our udev doesn't have that deficiency.. =)
<jbailey> We stopped taking newer versions of udev intentionally so that upgrades from Hoary to Breezy wouldn't suck.
<Robot101> ahh
* Robot101 upgrades to breezy's udev
<jbailey> There's some clever features in the newer udev that if you've never had, you won't miss. =0
<desrt> clever?
<Robot101> jbailey: Keybuk explained it the other day but I forgot what it was
<jbailey> desrt: Where, there's bits like /dev/by-label and /dev/by-uuid
<Robot101> oh yeah, it deprecates almost all of hotplug because the kernel tells udev enough information to just read modules.foo itself and get the right module
<Robot101> so then you can put coldplug on
<desrt> jbailey; oh.  that's really cute.
<jbailey> I think there's some other bits that can use the new socket interface of getting events from the kernel to react a bit more cleanly.
<Robot101> and be done with hotplug entirely
<jbailey> Right, we do that in the initramfs.
<jbailey> Which is why it requires 2.6.12 =)
<Robot101> do what, coldplugging?
<jbailey> Yeah.
<infinito> hi!
<infinito> does anyone know what signal send gnome session to apps when closing?
<infinito> i need to make some actions on my program before closing session...
<Robot101> so does that mean I can just take hotplug off my system if I have a sufficiently new udev? :)
<jbailey> That's why it was able to detect everything for you, it doe sit all at boot time and just loads up most of the modules to give itself the most choice at bootup.
<desrt> infinito; see the topic
<jbailey> Robot101: No, the ide bus is still not covered.
<jbailey> i think SCSI is now, though.
<Robot101> ah, you need a newer udev to be able to install coldplug
<Robot101> what happens if you coldplug twice? :)
<infinito> desrt: i'm writing an app for ubuntu, is that included on ubuntu-development??
<desrt> infinito; cool.  what app?
<jbailey> Robot101: Nothing bad.  The module is already loaded.
<infinito> desrt: a webcam activity monitor applet
* Robot101 toasts hotplug... pile of crap
<desrt> infinito; i think you're pretty much screwed if you're an applet :(
<Robot101> actually let me test if I get any ptys :)
<desrt> infinito; consider making a note about your desired use case on the AppletsRevisited page of the gnome wiki
<infinito> desrt: well, in fact is not an applet, is a tray icon that notifies when your webcam is on
<Robot101> jbailey: does it do everything, including sound etc?
<Robot101> jbailey: (in the initrd)
<jbailey> Robot101: No, just storage and network.
<jbailey> mm.
<jbailey> And framebuffer and acpi. =)
<desrt> infinito; either way, i don't think applets or tray icons get asked nicely when the session is about to end
<desrt> infinito; the best you can do is probably register a signal on the 'destroyed' event of your eggtrayicon widget
<Robot101> desrt: eh?
<desrt> infinito; btw.  this isn't really related to ubuntu development
<Robot101> desrt: if it's a GnomeProgram you can use the gnome_session_* stuff
<infinito> desrt: ok, sorry, thanks anyway :)
<Robot101> it probably emits signals to tell you gnome is closing down
<desrt> Robot101; can trays that don't have their own main windows be gnome programs?
<Robot101> hrm
<infinito> desrt, Robot101: it's python
<Robot101> sure, but you should still be able to use libgnome...
* Robot101 pokes
<desrt> :)
* desrt gets ready to go out
<desrt> infinito; good luck
<infinito> desrt: thanks 
<mjg59> Evening
<elmo> do we have a trivial tag or equiv in our bugzilla?
<lifeless> 'tag' ?
<elmo> in debbugs, you can assign tags to bugs, 'patch', 'trivial', 'unreproducible' etc.
<lifeless> oh right, that form.
<lifeless> uhm, you could abuse milestones, but thats all that comes to mind
<lifeless> and I do mean ABUSE
<elmo> ah, easyfix keyword
<elmo> (or 'patch', but in this case 'easyfix' is actually better
<Robot101> infinito: libgnomeui gets you session management
<infinito> Robot101: under python as well?
<Robot101> dunno
<Robot101> I don't see why python wouldn't bind session management
<Robot101> infinito: gnomeclient is what you want
<Robot101> http://developer.gnome.org/doc/API/2.0/libgnomeui/GnomeClient.html
<infinito> Robot101: umm thanks, im gonna take a look at it...
<Robot101> infinito: gnome_init or similar establishes a connection to the session manager
<Robot101> infinito: then you can get a gnomeclient object and bind signals on it
<Robot101> infinito: like "die" :)
<infinito> Robot101: that's what i was reading
<ajmitch> afternoon
<Robot101> it's not tied to GnomeProgram (which would make little sense really)
<Robot101> jbailey: yeah, newer udev mounts /dev/pts for me :)
<TerminX> anyone know why permissions on a bunch of device nodes get screwed when the mplayer package upgrades?
<CarlFK> breezy live booting: "no eathernet found, but firewire was"  no eathernet is correct, but there isn't any firewire either.  
<CarlFK> is bugzilla still the place?
<jbailey> Robot101: Right, but it's mountcirtfs that does it...
<Robot101> jbailey: but it didn't when I had udev <060
<jbailey> Add set -x to the top of S02mountvirtfs?
<jbailey> Robot101: Otherwise known as bug reports welcome. =)
<CarlFK> breezy live doesn't put my old P2 laptop into 1024x768 - is this worth bugging?
<hub> will kernel 2.6.12 bring me something in Ubuntu ?
<hub> compared to 2.6.10?
<Robot101> hot chicks
<Robot101> riches beyond your wildest dreams
<hub> I have plenty of that already
<hub> what else?
<bddebian> 2 more
<zul> hi
<daniels> mdz: yes
<daniels> lamont-away: i don't know
<mjg59> daniels: Don't suppose you had any joy poking the X300 stuff any further?
<daniels> mjg59: i haven't had any time, sorry
<mjg59> daniels: Ok, no problem
<mjg59> daniels: I should file a bug about it, really...
<daniels> mjg59: i suspect ati don't care because they submit everything via the cp instead of via mmio, so getting r300 dri support in might neatly skirt the problem ;)
<mjg59> daniels: Haha
<mjg59> Though it would also require PCI express DRI...
<mjg59> But you think it's just a matter of syncing the engine in the right place?
<daniels> mjg59: oh, yeah, duh
<daniels> mjg59: well, idling the engine *works*, but it's usually a workaround for something else (usually an asic bug)
<daniels> it slaughters performance
<daniels> normally ATI are able to let us know what the particular hardware bug is and how they worked around it, but no more, it seems
<mjg59> Hm.
<mjg59> Still better than switching off acceleration completely, right?
<mjg59> Can you make it specific to the X300?
<daniels> yeah, worst-case scenario is that I just have an if block which defaults accel to false on the x300, true otherwise
<mjg59> Ok, cool
<pef> hello
<zyga> hello
<zyga> what are 'Release' files?
<zyga> I'm translating the installer and I've found some messages I cannot really understand: 'Failed getting Release signature file ${SUBST0}.'
<Mithrandir> mjg59: does usplash use double-buffering?
<daniels> you *can't* double-buffer with vga, can you?
<daniels> fill a couple of registers, poke an int, rinse, repest
<Mithrandir> ew, ok.
<Mithrandir> I thought you still had an fB?
<Mithrandir> s/B/b/
<Lathiat> i thought vga had more than 1 screen
<daniels> Mithrandir: well, you do have an fb, but at a fundamental level, the fb still has to draw with poke-poke-int-poke-poke-int-poke-poke-int
<daniels> Mithrandir: you can't just draw offscreen and tell the card to scan out from that buffer now
<daniels> (nice as that would be)
<Mithrandir> daniels: you should be able to map the fb, and then just memcpy onto it. :-)
<daniels> Mithrandir: hah.  not how vga works.
<Mithrandir> daniels: vga sucks, then
<Mithrandir> :-)
<Lathiat> its interesting, mjg59 reckons that in most cases that vesa breaks suspend and that vga16 works, yet in my case vesa works and vga16 always screws my consoles up. :)
<Lathiat> i seem to always get thigns upside down
<daniels> Mithrandir: well, duh
<Mithrandir> daniels: any reason why /dev/input/mice doesn't default to ExplorerPS2, but ImPS2?
<Mithrandir> (changing it makes my MX518's side buttons work correctly)
<daniels> Mithrandir: need to establish whether or not it breaks non-explorers
<Mithrandir> daniels: so if I can verify that it works correctly with a ps2 and usb mouse, it's ok?
<daniels> Mithrandir: go and find the cheapest, shittiest, oldest ps/2 mouse you can see
<daniels> Mithrandir: test it with 50 or those
<Mithrandir> I generally don't have shitty hardware. :-P
<HiddenWolf> shit, I just trew a crate of those out last month. literally.
<daniels> Mithrandir: i noticed those
<Mithrandir> I mean, why would you save old, shitty, cheap hardware? ;-)
<Mithrandir> mvo: the language-selector UI needs some love, I think.
<Mithrandir> mvo: if you don't make any changes, "Ok" is a noop
<Mithrandir> mvo: should it possibly be "apply changes" and "quit" depending on whether you have done any changes or not?
<Mithrandir> s/and/or/
<mvo> Mithrandir: yes, it should probably just set the ok button to insensitiv if nothing changed
<mvo> Mithrandir: did you noticed other problems as well with it?
<Mithrandir> mvo: the norwegian setup is wrong, since there is not a "Norwegian" language, there are two forms of norwegian, which should be treated as two languages for all practical reasons.
<Mithrandir> mvo: I think setting the button to insensitive is wrong; an application should be quittable without using the wm decorations.
<zyga> mvo: morning :)
<zyga> mvo: I'd love to hack language-selector
<mvo> zyga: go for it :)
<zyga> mvo: I hope it runs on hoary though :/
<mvo> zyga: uhh, it depends on a updated python-apt
<mvo> Mithrandir: well, if "ok" is insensitiv, "cancel" is still available :)
<zyga> mvo: installing breezy's .deb will probably pull everythin in
<mvo> zyga: yes :/
<zyga> mvo: how about 'Apply changes' and 'Exit'
<Mithrandir> mvo: language-selector looks like a dialog, "Cancel" should undo the changes, really.
<zyga> apply could become sensitive
<mvo> Mithrandir: so it should just be "Norwegian Bokmal" and "N. Nynorsk" but not "Norwegian" ?
<Mithrandir> mvo: correct.
<Mithrandir> mvo: both should have fallbacks to no_NO
<zyga> mvo: will python-apt work on hoary if I build the deb myself?
<mvo> zyga: yes, it should be
<zyga> mvo: dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
<zyga> (I just tried dpkg-buildpackage)
<zyga> mvo: arghh... it depends on libapt-pgk-dev
<zyga> mvo: It might just work... 
<mvo> zyga: yeah, it should
<hunger> What do I need to do to make xdm install cleanly? Currently it exits postinst with status 1.
<zyga> mvo: http://pastebin.com/353434
<zyga> mvo: tell me if it's okay to override those dependencies
<mvo> zyga: it dosn't build with the old libapt-pkg-dev?
<mvo> from hoary?
<zyga> mvo: when you said it depends on new python-apt I assumed it needs all updated apt stuff
<mvo> zyga: you are right, it does. it needs >= 0.6.40 to build
<Aric> anyone heard from DanielS when the next breezy Xorg packages will go up?
* mvo needs to get some food
<pitti> Hi
<siretart> hi pitti 
<carstenh> hi pitti 
<pitti> Hi guys
<pitti> carstenh: could you sleep a bit? :)
<carstenh> pitti: sure :)
<pitti> doko: thanks for building a mythes shlib :-)
<kronoss> hi
<pitti> Hi kronoss 
<sivang> morning all
<sivang> pitti: aren't you taking a weekend time off? ;-)
<pitti> sivang: yes, just some email reading :-)
<Robot101> jbailey: wow, mkinitramfs is very neat
<sivang> Robot101: what's neat about it ?
<Robot101> how flexible and elegant it is compared to mkinitrd
<Robot101> which is just a hairball of crap that doesn't actually work in any remotely interesting situations
<sivang> Robot101: but it serves different purposes, no?
<Robot101> (*especially* when upgrading from a hand-rolled to a stock kernel)
<sivang> Robot101: eh, so it allows some more corner cases , that's always nice
<Robot101> sivang: it makes an initrd.ing which brings up your hardware and mounts your /
<Robot101> sivang: it's a damn sight better at it than mkinitrd is
<Robot101> s/ing/img/
<sivang> Robot101: does it have anything to do with RAM ? =) (given it's name)
<Robot101> initramfs is just a better replacement for initrds in 2.6 kernels
<sivang> Robot101: ah I see, so what does the ram in its name stands for? is it just its name?
<azeem> sivang: same as in initrd, I guess
<Robot101> the kernel always has a rootfs, which is a RAM-based filesystem, and when given an initramfs image, which is a gzipped cpio thing, unpacks it into the rootfs
<azeem> the r stands for ram
<ompaul> ram as in random access memory or something else?
<sivang> ompaul: yep, I think so
<sivang> azeem: k, thanks
<Robot101> initramfs lets you use as much space as you want, and its writable
<sivang> Robot101: how's that?
<Robot101> and you don't give the kernel a filesystem image, you give it a cpio.gz essentially
<Robot101> initrd sets you up a ramdisk device of a certain size, and unzips the initrd into it, then mounts that filesystem
<Robot101> so you only have as much space as your filesystem image
* ompaul is very upset today }:-) where would I find the person with the authority (say it like they do in south park) or even the interest to figure out why I can't connect to the torrent service to hand away more ubuntu - I have to upload something so  kanotix is winning for the first time in months today
<sivang> Robot101: what was the obsticle in making it variable size that initramfs overcame ?
<Robot101> sivang: tmpfs/ramfs/rootfs lets you store filesystems in the VFS file caches basically
<Robot101> sivang: so it's like a cache of files off disk filesystems, without a disk
<Robot101> sivang: so unless you place a limit on its size, your filesystem is as big as you have free virtual memory
<sivang> Robot101: right. makes sense. And initrd was just plain file that was read from disk in boot time, which entitled the size barrier?
<Robot101> sivang: whereas for an initrd image, the ramdisk is a pretend block device the kernel sets up for you, and they have a fixed size
<Robot101> sivang: the choice of using cramfs for the image makes for smaller initrds, but means that this pre-/ root filesystem can't be written, so the first thing that happens in the initrd is mounting up a load of tmpfs filesystems and copying stuff around
<Robot101> sivang: anyway, the use of initramfs in the kernel instead of initrd isn't the reason that mkinitramfs is better than mkinitrd
<sivang> Robot101: then what is the reason? =)
<siretart> woah. vdk is a beast..
<Robot101> sivang: the reason is that mkinitrd is a crap fragile hack which produces initrds that don't reliably initialise your hardware and mount your / :P
<sivang> Robot101: that's I've seen , that's probably because of all the loosy file copies and the size constraints no?
<Robot101> sivang: no, that's because mkinitrd is just crap
<sivang> Robot101: say, as a side note, are you familiar with PKG_CHECK_MODULES directive in autoconf configure files?
<Robot101> sivang: you could very easily put most of the clue in mkinitramfs's images into an initrd, but there'd be no point
<Robot101> sivang: not really, sorry :-/
<sivang> Robot101: k, np , guess I'm off to the autoconf channle
<Robot101> wow, there is one?
<sivang> Robot101: apparetly, there is only one person in there, so I asked aways in #gnu as well
<shackan> is this a good place do ask where does g-n-m take information about active interfaces ? it's not e-n-i because it shows devices not mentioned in the interfaces file, and it's not hal for the same reason, and it's not ifconfig because it does not show all the interfaces ifconfig shows, so how does it work or where can I ask ?
<hunger> shackan: I guess "all of the above" applies.
<shackan> ugh
<hunger> shackan: It definitly gets static configuration from /e/n/i from what I learned here.
<hunger> shackan: But it does do additional device discovery.
<hunger> shackan: Yeah, I know... it sucks.
<shackan> I hope it could just use hal
<hunger> shackan: Dynamic stuff defined in /e/n/i is ignored...
<shackan> that's what it's meant to do..
<shackan> ok, briefly, I want a particular interface to show up in the manager
<Robot101> shackan: ifupdown stores state on interfaces in /var somewhere
<hunger> shackan: Well, it is meant to configure interfaces. I do not care where it does store its configuration, but I hate it to be in several places.
<Keybuk> Robot101: /etc
<Keybuk> (at least, it used to be)
<Robot101> oh right
<Keybuk> /etc/network/run/ifstate
<Robot101> why on earth is the busybox-cvs package in ubuntu based on the same orig.tar.gz as in debian, but contains a 5MB diff to a new upstream version?
<Robot101> that's obcenely lazy
<hunger> NM is not installable on breezy right now anyway:-(
<shackan> it seems if[up|down]  requires an entry to be added to net/interfaces
<hunger> Looks like j^'s debs are still not in universe.
<Keybuk> because otherwise you'd have to change the upstream version?
<hunger> shackan: Right. ifup/down needs that entry. NM does not use that though afaikt.
* hunger is no expert on NM though... Just played with it and did not like it too much.
<Robot101> Keybuk: I had to use initramfs-tools to render my sid desktop bootable because mkinitrd is so crap :)
<shackan> thanks anyway
<shackan> I'll look for an official site with a faq or something
<Robot101> Kamion: why does busybox-cvs in ubuntu have a 5MB diff? I'd like to merge the relevant changes to make initramfs stuff work into debian's busybox 1.x package
<Robot101> Kamion: but it's a little hard to.. uh... know which changes are relevant
* Robot101 gets incredibly confused
<Robot101> ah
<Robot101> Keybuk: http://people.ubuntu.com/~scott/patches/busybox-cvs/ seems to have rendered the entire package into a patch :)
<HiddenWolf> lol
<Keybuk> it would do
<Robot101> really? the sid one and the breezy one have the same orig.tar.gz
<Keybuk> exactly, so the patch on that URL would be the entire difference of the .diff.gz
<Keybuk> it's 5MB, as you said
<Robot101> Keybuk: no it's not, it's 82k
<Keybuk> the .diff.gz ?
<Robot101> no, the interdiff from busybox-cvs_20040623-1.diff.gz to busybox-cvs_20040623-1ubuntu21.diff.gz
<Robot101> the debian diff.gz is 175445, and the ubuntu diff.gz is 191796, and they share the same orig.tar.gz
<Keybuk> *shrug*
<Robot101> so the output on your page is bogus
<Keybuk> almost certainly
<Robot101> you seem unconcerned :P
<Keybuk> I am
<Keybuk> if it's just that one package, there's probably something odd
<Robot101> given that this page is meant to be the magical oracle for Debian people to come and get their Ubuntu crack, it's not making it easy for me to understand what's been changed :P
<Keybuk> looks like a lot of them have done that though
<Keybuk> probably a bug
<Robot101> you still seem unconcerned :P
<Keybuk> yes, it's Satday
<Keybuk> with an "ur" in there
<Robot101> uuuur
<Keybuk> I'll be concerned on Monday ;)
<Robot101> lol
<Robot101> fair enough
* Robot101 uses interdiff in the meantime
<Keybuk> I'd guess it didn't like me wiping the files cache the other day
<Robot101> why is that not eg patches.ubuntu.com? :)
<Keybuk> because
<Keybuk> it's not an official service, I guess
<Robot101> it comes up very often in arguments against ubuntu being a fork... it probably should be :)
<Keybuk> but we are a fork
<Keybuk> just one that eats the same meatballs ;)
<Robot101> fork/spoon/whatever... against it being an uncooperative fork at any rate
<Keybuk> Debian is an uncooperative parent, in my experience
<Keybuk> weird
<Keybuk> <p>The requested URL /archive/2004/06/30/debian/pool/main/b/busybox-cvs/busybox-cvs_20040623-1.diff.gz was not found on this server.</p>
<Keybuk> there you go
<Keybuk> that's the problem
<Keybuk> snapshot.debian.net has lost most of the archive
<Robot101> Keybuk: there we go, waldi would be happy to see a patch making busybox good for initramfs
<Keybuk> hmm?
<Robot101> Keybuk: I'm trying to spread the mkinitramfs love into Debian :)
<Keybuk> right ...
<Robot101> given it can make my computer boot, and mkinitrd can't
<Robot101> well I was just saying, he doesn't seem to be uncooperative...
<Keybuk> right, it's certainly not all
<Keybuk> but at some point the work to try and get the changes into Debian exceeds the benefit
<azeem> hear, hear
<Robot101> but at some point you have more delta than you have people to maintain it
<Keybuk> the fact he hasn't, despite their being a patch available, is somewhat indicitive
<Keybuk> why doesn't the Debian version support initramfs?
<Keybuk> the patch has been available all the time
<Robot101> was he even aware that ubuntu's version had been modified for supporting it?
<Keybuk> he should have been
<Keybuk> the Debian PTS and QA pages keep track of that these days
<Keybuk> as a maintainer, keeping an eye on what other distributions are doing with the same package is kinda useful -- not just Debian-derivs but what RedHat are doing etc.
* Robot101 nods
<Keybuk> in my experience the complaints are that the patch isn't handed to them on a gilded silver platter, perfectly tailored to their wishes, etc.
<Keybuk> a lot of Debian maintainers just don't seem willing to do _any_ work to merge Ubuntu patches in
<Keybuk> and expect Ubuntu to do all that work, rather than meeting half way
<Keybuk> we've done more than any other distribution to make it easy to find the differences
<Keybuk> I've helped the QA and PTS people find out what's different
<ajmitch> Robot101: it's a big challenge for universe, since we're spread so thin
<ajmitch> we don't have time to tailor things for debian, generally
* Robot101 nods
<Robot101> fair enough
<Robot101> I don't really think you're an uncooperative fork
<Robot101> :)
<Keybuk> I'm finding it slightly amusing that you're the first person to notice NDA hasn't worked for two months <g>
<Keybuk> that really shows how many Debian people are using it :p
<Keybuk> (actually, it's probably only a couple of weeks -- it would have survived the snapshot melt until I deleted the disk cache because it ran out of space)
<Keybuk> Aug 24, in fact, is when it would've failed
<azeem> Keybuk: the snapshot melt concerns only stuff from last year, so if there have been more recent Debian uploads, you wouldn't notice I guess
<Keybuk> azeem: yeah, it'll be just where the Debian version the Ubuntu one is based off is before March 13th
<Robot101> this package is only so old because it's been superseded in debian
<Robot101> debian's not the only people with merging work to do :D
<Keybuk> right, but we're in freeze, so we have to do all the merging work at the start of dapper
<Robot101> hrm, so in a month or two someone will be paid to do what I'm about to do now?
<ajmitch> I think for universe, it'll take a few weeks just for merges at the start of the cycle
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion/ | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | Colony 3 is released: http://cdimage.ubuntu.com/releases/breezy/colony-3/ | PreviewFreeze: no uploads without approval https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs
<Keybuk> Robot101: that's the other bit of the Debian problem <g>
<Keybuk> "I'm not doing that if someone else is going to get paid to do it" :p
<ajmitch> Robot101: some of us do things out of love, still :)
<Robot101> (note that I'm still doing it)
<Robot101> the mergeometer... watch find . -name *rej
<Robot101> :D
<Keybuk> heh, how do you think merge-o-matic works? :p
<Keybuk> rookery files% grep "404 Not Found" *.dsc| wc -l
<Keybuk> 764
<Robot101> Keybuk: something evil with interdiff, grepdiff...? :)
<Keybuk> rookery files% /bin/ls *.dsc~*ubuntu* | wc -l
<Keybuk> 1669
<Keybuk> so about half of our Debian bases are missing :-/
<azeem> Keybuk: you use snapshot.d.n only when the package is not on ftp.d.o?
<Keybuk> azeem: no, always use snapshot
<azeem> Keybuk: hrm, so maybe trying ftp.d.o first might help a bit in this situation?
<Keybuk> maybe a bit
<Keybuk> snapshot never broke before, so there wasn't any reason to do it <g>
<azeem> yeah
<Robot101> Keybuk: where can I get old ubuntu diff.gzs?
<Keybuk> morgue.ubuntu.com
<Robot101> word
<Robot101> I realised that what I was trying to do was break up this patch into its constituents, and given that each change was probably made one at a time I can do a lot of the work for me with interdiff :)
<Robot101> <-- patch n00b
<jdub> GOOD MORNING FREEDOM LOVERS!
<Mitario> um... hi :)
<sebest> good morning!
<Robot101> jdub: moin
<Robot101> hrm
<Robot101> fuck it
<Kamion> Robot101: I was too scared to switch from busybox-cvs to busybox at the point that change happened in Debian ... as the man says, we'll do it for breezy+1
<Kamion> all the initramfs stuff was jbailey's work, anyway
<Robot101> Kamion: fair enough
<Robot101> I think I've already merged enough for the initramfs
<Kamion> jbailey probably ought to have sent waldi a patch for that, if he wanted to merge stuff to Debian
<Kamion> then again, there's a fair amount of busybox stuff I ought to have sent patches for, too
<Robot101> I'm highly keen on seeing it in debian, mkinitrd is just too stupid for words
<Kamion> although I have sent some of it
<Robot101> it's very hard to migrate from a custom kernel to a stock kernel in a fair number of situations
<Robot101> mkinitrd's initrds just aren't robust in the slightest
<Robot101> I wonder what the debian kernel folks think about mkinitramfs
<Kamion> Robot101: they seem to be vacillating between it and yaird
<slomo> hm... do we have daily live cds?
<ajmitch> slomo: yes
<Robot101> Kamion: hm, and yaird postdates ubuntu's mkinitramfs?
<Robot101> Kamion: mkinitramfs looks like it does a lot more automatically (at boot time) than yaird
<Robot101> which makes it more robust
* Robot101 reads a document about yaird
<Robot101> it seems to be about how to boot linux boxes, not about how it works
<Kamion> Robot101: no idea
<Kamion> slomo: http://cdimage.ubuntu.com/daily-live/
<slomo> Kamion: thanks :) ajmitch already gave me an url
<madduck> Diziet: ayt?
<pef> what do you think about debian/rules commented debhelper commands calls ?
<madduck> pef: remove them. :)
<pef> madduck: I don't understand why lot of packages have them
<madduck> pef: dh_make
<ogra> lazyness
<pef> so commented out -> to delete
<madduck> yes
<madduck> there was a debian list post about this sometime in the last few weeks
<madduck> can't find it now.
<madduck> basically, the main objection from the side of people is that they won't know the right commands should they ever need them in the future
<madduck> which is utter b/s. the solution is obviously to 'dh_<TAB>' at the shell. :)
<madduck> and man debhelper.
<siretart> madduck: do you know/have a work-around for non existing baz_load_dirs?
<madduck> sec
<madduck> siretart: workaround for what?
<madduck> siretart: i mean, what problem?
<madduck> i don't have a new baz_load_dirs yet
<siretart> madduck: well, afai understood, tla_load_dirs does not handle loading into bazaar archives
<madduck> oh, it does.
<madduck> you need to get the latest from unstable 
<madduck> -3 i think
<madduck> ah no...
<madduck> http://bugs.debian.org/322622
<siretart> exactly
<madduck> no. i usually just tar the new upstream over and then check status and diff output
<madduck> renames are very infrequent, IME
<madduck> siretart: but it should be *trivial* to patch.
<siretart> hm
<madduck> ah, here's a workaround.
<madduck> echo -e "#!/bin/sh -e\nexec baz $@" > ~/bin/tla
<madduck> :)
<siretart> hm. nasty, but effective :)
<madduck> might not work
<madduck> but you could us a case statement to translate commands back and from. :)
<madduck> better to patch load-dirs-common.
<siretart> jepp
<jbailey> slomo: No.  At this point it likely won't get looked at until after Preview is done.
<jbailey> I have a couple higher priority bugs to chase at the moment.  I don't know where it is in BenC's queue.
<slomo> jbailey: ok... no problem :)
* jbailey wanders off again.
<marcin_ant> hi all - short question - there are 14 Google Soc Projects in breezy bounties
<marcin_ant> release day was 01.09, so, could someone tell me what is the status of these projects?
<marcin_ant> are there any reports etc. what's going on for example with bluetooth support goal?
<ryanthiessen> marcin_ant: a lot of the SoC projects missed Breezy's feature freeze and will be included in breezy+1
<marcin_ant> ryanthiessen, ok but what about the status of these projects?
<marcin_ant> ryanthiessen, 1. personally I would like to know if there is any work on bluetooth support and 2. I'm just curious if these Soc projects were successfull
<marcin_ant> ryanthiessen, (it's pretty strange for me - $2 mln budget and I cannot see any list of accepted projects, any reports what's going on with these projects.... )
<hunger> marcin_ant: I bet there will be a paper by google soon, claiming a huge success...
<hunger> marcin_ant: I have not yet heared of any myself though:-)
<marcin_ant> hunger, well maybe but I'm not so sure... 
<marcin_ant> hunger, for example Chris DiBona announced a web page with list of accepted project at 04.07
<marcin_ant> hunger, and there is no such webpage since today
<slomo> elmo: did you already read my mail regarding ffmpeg?
<marcin_ant> hunger, and another thing is that if ubuntu is mentor and this is ubuntu-devel channel than I thought that someone here should know what's going on with these projects
<desrt> mxpx; pong
<ryanthiessen> marcin_ant: pitti is the bluetooth assessor, ask him when he's around
<marcin_ant> ryanthiessen, ok
<marcin_ant> ryanthiessen, thx
<marcin_ant> .seen pitti
<marcin_ant> ,seen pitti
<marcin_ant> ehh hello bot, are you there?
<marcin_ant> anyway pitti isn't online
<amep> I have a laptop that fails during suspend to RAM (goes down, but oopses on the way up before the screen lights up). The machine is a Compaq R3000z AMD64 system. How should I go about debugging? and is suspend to RAM a target for breezy so should I even bother? Suspend to disk worked.
<amep> I have a laptop that fails during suspend to RAM (goes down, but oopses on the way up before the screen lights up). The machine is a Compaq R3000z AMD64 system. How should I go about debugging? and is suspend to RAM a target for breezy so should I even bother? Suspend to disk worked.
<Lathiat> amep: file a bug
<Lathiat> would be appreciated, thanks :)
<amep> OK, I'll do that. I'll include lsmod output and what else?
<Lathiat> details of your laptop, lsmod, if you have any info i your syslog such as the oops information thatd be good, as would an lspci
<amep> Cool, will do.
<amep> Thanks
<Lathiat> nps
<hunger> amep: A wiki page about the laptop might be nice as well (LaptopTesting
<amep> hunger: There is one at LaptopTestingTeam/CompaqPresarioR3000 should I add to that or should I create a LaptopTesting/CompaqPresarioR3000z page?
<Lathiat> amep: is that laptop the same as yours specification wise?
<amep> It's hard to tell. I'll look.
<hunger> amep: I'd create a new page... even if the specs are similar who knows what hardware compaq built into each one.
<amep> I also wanted to know if you care whether it's under LaptopTesting or LaptopTestingTeam.
<Lathiat> LaptopTestingTeam is the place
<hunger> amep: Listen to Lathiat, he knows things;-)
<Lathiat> i do? *G*
<amep> OK, I'll write that page this while I write the bug report.
<amep> Is there a template page?
<Lathiat> amep: yes, see the LaptopTestingTeam page
<amep> Lathiat: Sorry I should have seen that.
<Lathiat> amep: 'sok
<lamont-away> postgres is pitti, yes?
<tseng> yes
* Lathiat taps his foot at the savant build
<Lathiat> -EWIN
<amep> Lathiat: what package should I file my sleep bug against? acpi or acpi-support?
<Lathiat> amep: uh
<Lathiat> amep: acpi-support
<amep> OK. Thanks.
<lamont-away> https://bugzilla.ubuntu.com/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=UPSTREAM&bug_status=PENDINGUPLOAD&field0-0-0=product&type0-0-0=substring&value0-0-0=FTBFS%20in%20breezy&field0-0-1=component&type0-0-1=substring&value0-0-1=FTBFS%20in%20breezy&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=FTBFS%20in%20breezy&field0-0-3=status_whiteboard&type0-0-3=substring
<lamont-away> &value0-0-3=FTBFS%20in%20breezy
<lamont-away> ^^ for fun
<HiddenWolf> lamont-away, www.tinyurl.com!
<lamont-away> yeah, well..
* lamont-away has to run off for a while, or  he would
<ompaulAFK> http://tinyurl.com/ac3q7
<Lathiat> mjg59: ugh, keyboard shortcut handling is totally bogus
<hunger> Does anyone know how to fix the current xdm?
<djpig> Keybuk: ping
<Keybuk> yo, 'sup?
<djpig> is http://people.ubuntu.com/~scott/patches/ currently broken?
<Keybuk> yes, see topic :p
<Keybuk> actually, it's snapshot.debian.net that's broken
<Keybuk> they lost the drive, so we can't get the old versions of the Debian packages to make the diffs
<djpig> ic
<jbailey> Keybuk: Around?
<Keybuk> jbailey: yes
<Keybuk> I do get aroud
<jbailey> ;)
<jbailey> Keybuk: I think we're going to need a solution of some sort with dpkg for "breaks" or something.
<jbailey> right now if you upgrade glibc and nothing else to breezy, the old initrd-tools makes initrd's that are broken.
<Keybuk> we do need Breaks
<Keybuk> but we need Breaks 6-months ago, if we want it for the hoary->breezy upgrade
<Keybuk> so there ain't bugger all we can do about that now
<jbailey> If you update glibc without updating libterm-redline-gnu-perl and happen to use the terminal mode of debconf, any debconf app breaks.
<jbailey> I suspect we'll see mass breakage if we don't have something. =(
<Keybuk> (because the hoary apt has to calculate the upgrade; and the hoary app doesn't do Breaks)
<jbailey> Ouch
<jbailey> Is there nothing we can do? =(
<Keybuk> other than doing Breaks, and then put "upgrade dpkg and apt first" in the release notes
<Keybuk> which, btw, NOBODY will follow
<Keybuk> nope, nothing
<jbailey> Should I just close these bugs as WONTFIX ?
<Keybuk> make them versioned deps in ubuntu-*
<Keybuk> ask mdz what he wants to do about it
<jbailey> Well, he's the one who prompted me into asking you the first time a few months ago when it came up.
<jbailey> initrd we could ignore, since we don't actually use it anymore.
* lamont looks around for kamion/elmo
<jbailey> But this adds people using readline frontend into the mx, so I figured I'd ask again.
<jbailey> I can put it in the release notes, and I don't know that many people will actually use readline mode on Ubuntu.
<jbailey> libreadline-gnu-perl isn't even in main for us.
<jbailey> I just don't know what to do with the bug reports otherwise.
* lamont unlooks
<Lathiat> what does Breaks: do
<Lathiat> make sure that package upgrades with it?
<jbailey> AIUI, it basically makes it a temporary pre-depend.
<jbailey> Or unpacks it first or something.
<desrt> will preview have 2.12.0?
<Keybuk> lol
<Keybuk> no
<desrt> eek
<Keybuk> Breaks is to Conflicts as Depends is to Pre-Depends
<Keybuk> when foo Conflicts bar, even if it's just bar (<< some-version) it means that bar has to be _removed_ from the system before foo can be unpacked
<Keybuk> apt might decide to remove then install the new version, but it still has to not be on the disk at some point
<jbailey> Ah, hmm.
<Keybuk> Breaks is less so, it simply requires that it be deconfigured -- so a normal upgrade can take place
<Keybuk> foo Breaks bar (<< some-version) means bar has to be upgraded, basically
<Lathiat> ah ok
<lamont> malloc: ../bash/jobs.c:737: assertion botched
<lamont> free: underflow detected; mh_nbytes out of range
<lamont> Aborting.../bin/sh: line 1: 19261 Aborted                 CC="cc" CXX="g++"
<lamont> Go, bash!!!
<Keybuk> sweet
<lamont> and that's just running configure. (for vino)
<Keybuk> we could stick dpkg and apt into hoary-updates ... <G>
<lamont> Keybuk: or hoary-security... :)
<lamont> but that doesn't help the off-net user
<Keybuk> *giggle*
<Keybuk> are you joining us in Montreal, btw?
<lamont> gonna ask next week if they'll send me... if I do come, it'll just be for a couple of days
<Keybuk> aww :-/  but it'll good to see ya
<lamont> it'll be good to be seen.
<lamont> er, or something like that
<jbailey> lamont: We'll have you over for a drink. =)
<lamont> heh
<pef> is it possible to build a custom ubuntu cd for installing something like a configured samba network ?
<Keybuk> yes.
<lamont> pef: it's easiest to start from a built CD though
<pef> for example: I have an ubuntu server, with samba configured and postfix working as an mx backup. is it possible to build a custom cd which install theses services like there were ? disk cloning is great, but if you change hardware ?
<lamont> most certainly
<lamont> if it was me, I'd add a package that Depends: postfix, samba, and configures them like you want.
<lamont> then do a server install, and then install your pacakge.
<lamont> sadly, the Release file is signed on the CD, so you also have to upgrade ubuntu-keyring to include your (newly generated and held sacred) key, and re-sign the new Releases file with that key
<lamont> alternatively, you just include a new subdirectory on the CD that contains your self-contained tree with your package.
<lamont> that's considerably easier, and gives a clear history of the CD
<lamont> but it does require adding the key, or dealing with it being unauthenticated, etc.
<pef> ok, nice idea
<lamont> cc -O2 -I../include -g -Wall -DGCC_WARN   -c -o end.o end.c
<lamont> end.c:1190: warning: 'list_vanquished' defined but not used
<lamont> that just sounds like a serious nethack bug.
<lamont> Kamion: fix that.  kthxbye. :-)
* lamont goes shopping
<mxpxpod> desrt: you have a pbook, right?
<desrt> mxpxpod; i do.
<desrt> mxpxpod; i'm on that laptop testing thingy
<mxpxpod> desrt: can you come to #ubuntu-laptop and discuss some ppc laptop stuff?
<desrt> sure
<Lathiat> ogra: hrm, the password circles are off center
<Lathiat> mjg59: another bug, lid down -> lid up -> lid down -> lid up -- doesnt auto dpms back on like it does the first time
<wasabi> darn ibook still won't wake up
<slomo> jbailey: i found two other people with an ibook g4... everything works for them :(
<slomo> fabbione: can we update linux-wlan-ng (kernel modules and userland tools) to 0.2.2 after preview freeze? between 0.2.1-final and our version (-pre26) were many important bugfixes and between 0.2.2 and 0.2.1-final was exactly one change: a bugfix ;)
<Kamion> lamont-away: odd, list_vanquished is a function
#ubuntu-devel 2005-09-09
<TheMuso> .c
<pef> bye !
<mxpxpod> zul: you're the wlan guy, right?
<mxpxpod> kernel wlan guy, rather
<zul> kind of...its on my list to update this weekend..
<mxpxpod> awesome!
<mxpxpod> I posted a patch to my bug in bugzilla
<zul> yeah...i saw...wrong kernel version though :)
<mxpxpod> ah suck
<mxpxpod> can't you just change those numbers ;)
<zul> i have to look at it
<zul> mxpxpod, which version did you use?
<mxpxpod> zul: kernel version?
<zul> no wlan-ng
<mxpxpod> 0.2.2
<zul> k thanks
<mxpxpod> zul: I gotta get going... I don't think you should have any problems with that patch
<wasab1> Hey I don't suppose anybody is into computer robotic stuff? I'm looking for some resources. :0
<lamont-away> Kamion: really odd.
<lamont-away> mind you, that was just a warning in passing...
<lamont> elmo: please sync tmview_1:01.03-12 (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294375)
* lamont wonders if Kamion /mdz/elmo is around to pester for a couple minutes
<bddebian> lamont: I think everyone is dead/asleep :-)
<GoIrish> hey bddebian :)
<bddebian> Tritium?
<GoIrish> yep
<bddebian> Heh
<bddebian> Howdy
<GoIrish> how's it going?
<bddebian> Slowly as always. You?
<lamont> bddebian: well, it is a 3-day weekend in the US, and it is 0-dark-30 in the UK
* bddebian is in the US
<lamont> right... mdz is US, elmo/kamion are UK
<lamont> elmo: please put csh down on the list of packages to just sync-instead-of-merge post-breezy.  (or pre-breezy, for that matter.... :-)
<lamont> gda-freetds-provider.h:67: error: syntax error before 'TDSCONNECTINFO'
<lamont> gda-freetds-provider.h:67: warning: no semicolon at end of struct or union
<lamont> re
<lamont> ew, even
<lamont>  /build/buildd/qt-x11-free-3.3.4/bin/uic -L /build/buildd/qt-x11-free-3.3.4/plugins pixmapfunction.ui -o pixmapfunction.h
<lamont> make[4] : *** [pixmapfunction.h]  Bus error
<lamont> who made uic do unaligned load/stores, I wonder...
<Lathiat> mdz: bah as if its major, it makes half the worlds touchpads unbearable ;p
<pef> hi
<lamont> hrm... when I enable unaligned loads, then uic segv's.
<jdub> GOOD MORNING FREEDOM LOVERS!
<siretart> morning jdub!
<ivoks> :/
<siretart> hi ivoks 
<ivoks> hi siretart 
<zyga> jordi: ping
<ogra> jbailey, you broke the CD builds ! any reason that you changed the binary names of ubuntu-docs ? 
<sivang> morning all
<sivang> jdub: ping, any news on your side for ubuntu on the pseries ?
<blackmoon> hi, how can i compile grub under amd64? when i run ./configure, i've got this error: "configure: error: C compiler cannot create executables"
<pef> hi
<snoogert> hi, when i try to compile grub under amd64, i've got this error: "configure: error: C compiler cannot create executables"....
<pef> snoogert: please join #ubuntu and install gcc ;)
<Lathiat> and don't come whingign when grub broke because your compiling it instead of using the package
<Lathiat> ... please :)
<snoogert> i've already installed gcc... now i try to join #ubuntu... thanks
<pirroh> hello, is there in breezy a known bug about xchat Xlib SHAPE extension?
<mxpxpod> is there a reason why I wouldn't have /dev/inotify in breezy?
<ajmitch> yes, it's not a device node anymore, iirc
<mxpxpod> really...
<Lathiat> yeh
<Lathiat> it changed
<Lathiat> so it could be imoprted into the kernel
<mxpxpod> does beagle know this?
<Lathiat> mine does
<ajmitch> works for me
<mxpxpod> ok... I just saw a beagle message about not finding /dev/inotify
<Lathiat> might have support for both or something
<tseng> mxpxpod: there is no /dev/inotify
<mxpxpod> ah, probably
<ajmitch> mxpxpod: 0.0.12-0ubuntu6 ?
<tseng> 0.0.13 will be fine
<mxpxpod> yup
<tseng> if it ever gets here
<mxpxpod> tseng: hopefully it will have fixed some issues with the FileSystem backend... it seems to like to get stuck on certain files for me
<tseng> meh
<Lathiat> bleh beagle didnt even find a pdf i wanted today it sucks :)
<mxpxpod> it'll say "what do I do with this file?", "doing nothing", and then it starts the process over again for that same file
<mxpxpod> Lathiat: I've had that problem as well
<mxpxpod> anyway, thanks for the help
<Lathiat> i hate it when people take stupdi things i say seriously
<bddebian> Lathiat: :-)
<jbailey> ogra: Changed how, sorry?
<ogra> jbailey, it built ubuntu-quickguide before, which is a dependency of ubuntu-desktop and edubuntu-desktop now it doesnt
<jbailey> Oh, hmm.
<jbailey> I don't remember seeing that in the old source package.
<jbailey> I can correct it if it hasn't been already.
<jbailey> Hmm.
<ogra> i dont think someone hs yet
<jbailey> Is quickguide still included?
<jbailey> I think that might be one of the docs that the docteam dropped for Breezy.
<jbailey> There's something called a 'quicktour' now.
<ogra> hmm, probably.... anastacia wants to move ubuntu-doc to universe.... i guess you should change the seeds then
<jbailey> ogra: I need to finish sorting out some initramfs/usplash integration bits first.
<ogra> ok, i dropped the dependency in edubuntu for now, dont worry
<jbailey> I have the stuff mostly written, so it shouldn't be long.  The kernel integration will be amusing.
<ogra> i'll add it back after preview
<mpt> ubuntu-doc in universe! *boggle*
<pitti> Hi
<kronoss> hi pirroh 
<kronoss> sorry, hi pitti 
<carstenh> hi pitti
<zyga> pitti: hey
<zyga> hello mvo
<mirak> Xine on ubuntu breezy crash when you do a right click
<hrvoje> any ubuntu developers available ?
<CarlFK> durring a hoary install on a compaq armada 1700 P2-266.  dmesg shows "Critical temp reached. shuttind down" and sure enough, shuts down.
<CarlFK> I have a bunch of fans around it now, and pulled the keyboard out, so I think I will be able to get by
<CarlFK> years ago there was a kernel patch for this problem, but I thought it was part of the kernel now.  anyone want me to reasearch it?
<elvirolo> hi all
<elvirolo> are, by any chance, python-wxgtk2.6 and gstreamer0.8-musepack broken?
<CarlFK> how can I see what options were used to compile the kernel ubuntu uses?
<CarlFK> namly I need CONFIG_ACPI_COMPAQ_ARMADA_1700=y
<elvirolo> please anyone?
<ivoks> huh?
<ivoks> CarlFK: /proc/config.gz or /boot/config-`uname -r`
<ivoks> CarlFK: but this is wrong channel for that question
<CarlFK> kiinda.  if it isn't set I was going to file a bug report
<CarlFK> but thanks for the anwer
<elvirolo> iideas anyone?
<zyga> pitti: ping
<zyga> pitti: is http://l10n-status.gnome.org/gnome-2.12/pl/desktop/index.html automatically imported here https://launchpad.net/distros/ubuntu/breezy/+lang/pl
<zyga> anybody here?
<pitti> zyga: not automatically I think
<pitti> zyga: that needs to find its way through source packages
<pitti> but that usually happens fast
<zyga> pitti: someone at translators@gnomepl.org (the translation team) mentioned that the deadline is tomorrow
<zyga> pitti: is that the gnome deadline?
<pitti> yes, I think so
<pitti> we will update langpacks later
<zyga> great
<zyga> pitti: so once upstream closes you pull the translations again?
<pitti> yes
<pitti> well, I guess the translations will already be in the final gnome 2.12 packages
<ivoks> i have one idea for breezy+1
<ivoks> it's shouldn't be hard to implement, if you guys like it
<ivoks> it's great to have this big repository
<ivoks> but there are still apps that aren't in it, and will never be (due licenses)
<zyga> pitti: k, so no need for me to manually pull all of those .po files 
<zyga> pitti: I could just make sure that once rosetta gets updated stuff I can translate ubuntu-only things
<pitti> zyga: no, certainly not
<pitti> zyga: I have a script to pull gnome translations in bulk, in case we need it
<ivoks> nah... i'll write that down and propose one day...
<zyga> pitti: one last thing, what are the chances of rosetta export working till breezy ships (so that say... for 2.12.1 we can update translations again)
<zyga> ivoks: what packages for example?
<ivoks> for example, skype...
<ivoks> but that's not important
<zyga> ivoks: well..... 
<pitti> zyga: no percentage here, but it looks not too bad
<zyga> ivoks: kind of a good point
<ivoks> i tought, maybe we could have local repository after installation
<zyga> ivoks: did you try to contact the dev team?
<pitti> zyga: in any case, even if it works two months after the breezy release, we can still update the breezy langpacks at that time
<pitti> zyga: in fact we will do that anyway
<zyga> pitti: right
<ivoks> and user would, clicking on deb on internet, copy that deb to that repository
<HiddenWolf> ivoks, there is a very good reason not to allow that. Security
<ivoks> that crossed my mind
<HiddenWolf> ivoks, you'd have to pull in new dependencies too. It'd be a nightmare.
<ivoks> but...
<HiddenWolf> Think about it.
<zyga> ivoks: what would a local repo be good for?
<ivoks> that's the idea!
<ivoks> this way user wouldn't have to deal with dependency
<zyga> ivoks: is this mainly for skype?
<ivoks> it would be done automaticly
<HiddenWolf> Someone uses warty, and wants to use evince by clicking on the deb on packages.u.c. That'd be a nightmare. :P
<ivoks> zyga: no, for any other deb that's not in main/restricted/universe/multiverse
<zyga> ivoks: if so I'm sure skype management would love to have a .deb in multiverse or anything 
<HiddenWolf> ivoks, autopackage is there for that kind of problem.
<ivoks> hm...
* zyga just recalled that he had to upload a .po file for autopackage :)
* ivoks goes to bed too
<ivoks> HiddenWolf: thans for reminding me on those problems
<ivoks> thanks
<ivoks> ah... i'm tierd
<ivoks> tired
<ivoks> whatever :)
<HiddenWolf> ivoks, no problem. :)
<xTina> I haven't found anything in bugzilla related to this, and no mailing list discussion: Is it on purpose that "Open Terminal" is missing from the menu that appears when right-clicking the Gnome desktop in breezy, or is that a bug that should be reported?
<jgorski> apt-get install nautilus-open-terminal
<jgorski> seems to be intentional behaviour
<HrdwrBoB> so the only place to open a terminal is buried in the system menu ?
* xTina <- don't like it either ... anyway, gotta run, last train home
#ubuntu-devel 2005-09-10
<jordi> zyga: pong
<zyga> jordi: pitti helped me already, thanks :)
<zyga> jordi: I needed info on automatic .po importing from upstream
<jordi> zyga: I don't know many deatails about how that works currently.
<jordi> Let's ask carlos tomorrow.
<zyga> jordi: it seems to be invoked manually but as far as gnome is concenrned it's automated
<dholbach> hi
<jordi> zyga: nod
<slomo> elmo: did you already read my mail regarding ffmpeg?
<dholbach> ok guys  -  i'm off to bed
<dholbach> see you
<lamont-away> gda-freetds-provider.h:67: error: syntax error before 'TDSCONNECTINFO'
<lamont-away> libgda2 needs love
<lamont-away> dpkg-gencontrol: error: package mac-fdisk-cross not in control info
<lamont-away> dh_gencontrol: command returned error code 65280
<lamont-away> ditto for mac-fdisk
<dieman> hey, does anyone read mirrors@ubuntu.com?
<dieman> ack
<dieman> canonical.com, rather
<CarlFK> found 2 problems with Hoarys xconf setup on my 1700: Section "Monitor" is mostly empty and DefaultDepth is 24, but there isn't enough memory to do 1024x768x24 (i think)
<CarlFK> I think breezy live has the same problem.  is this worth reporting?
<crimsun> yes with the appropriate hw detail
<CarlFK> ill give it a shot
<mjg59> ndiswrapper-utils is i386 and amd64 - why's there only an i386 package?
<elmo> the kernel support errors out if you try and compile on amd64
<mjg59> Nnngh.
<elmo> which doesn't answer your question, but fyi
<elmo> as in #error we're 32-bit only, you lose
<mjg59> How odd
<mjg59> It's supposed to support it
* mjg59 is about to give up on the nx6125
<mjg59> The thermal trip values become correct if you pass acpi_skip_timer_override
<crimsun> elmo: please sync gnomebaker (0.4.2-1) from sid
<ajmitch> elmo: could you sync anjuta 1.2.4 from debian, please?
<mjg59> The BIOS is utterly fucked
<elmo> mjg59: :(
<mjg59> elmo: There's no buildd log for amd64 ndiswrapper-utils
<elmo> mjg59: it's probably P-a-s overriden
<mjg59> elmo: I'm in touch with an HP BIOS guy - with luck we'll get it sorted
<mjg59> elmo: Hm
<mjg59> elmo: Well, it build shappily here
<mjg59> I'll look into the kernel stuff
<elmo> mjg59: if you want it de-P-a-s'ed, just whine at me or lamont
<elmo> one day, someone should run through the list of things that say 'i386' in P-a-s as most of them (in main atleast) probably work fine on amd64
<mjg59> elmo: Ok, give me a minute and then I'll consider whining
<CarlFK> mjg59 - does that have anyting to do with my compaq fan problem that is fixed by the patch here: https://kilobyte.dyndns.info/linux/ (near the bottem of that page)
<elmo> crimsun: done
<elmo> ajmitch: done
<ajmitch> thanks
<crimsun> elmo: thanks!
<mjg59> CarlFK: Doubt i
<mjg59> t
<CarlFK> rats.
<mjg59> But I'll take a look - from the description they sound quite different, though
<CarlFK> cuz haveing an AC powered fann stuck to the back of the laptop is goofy
<mjg59> CarlFK: Grah.
<mjg59> CarlFK: That patch is basically impossible to read
<mjg59> It includes a new DSDT, rather than being a diff against the original DSDT
<CarlFK> swell
<CarlFK> crimsun - what package should I bug about the xorg.conf thing?
* Nafallo was about to answer "daniels" ;-)
<CarlFK> heh
<mjg59> elmo: Hm. ndiswrapper-source appeared to build
<elmo> mjg59: well, I don't know about that; I was just compiling a custom kernel for the nx6125, and got that #error when I enabled kernel support for ndis in ubuntu kernel source
<elmo> divdi3.c:#error This is for 32-bit targets only
<elmo> ^--
<mjg59> elmo: Hm. The driver in the kernel source may be old.
<mjg59> I'll chase that.
<elmo> ah
<mjg59> elmo: I've got ndiswrapper built!
<mjg59> And it's utterly failing to work
<elmo> I'm shocked ;-)
<elmo> using 64-bit windows driver?
<mjg59> Because I can't find a driver that (a) supports the hardware and (b) doesn't give unresolved NT kernel symbol errors
<jdub> Nafallo: how reliable is apt-proxy 1 these days?
<Nafallo> jdub: works fine on my laptop :-). cronjob doing apt-get update, and several pbuilder runs a day without troubles :-).
<Nafallo> cronjob doing apt-get update _every half hour_
<Nafallo> why do you always forget the important parts when you're hacking to 5AM? ;-)
<ajmitch> jdub: 1?
<ajmitch> I've been using 2, with some issues
<womble> jdub: I've had apt-proxy 2 do some slightly bongful stuff on suspend/resume, but nothing a quick restart doesn't cure
<womble> Apart from that it's True Love.
* jdub had lots of problems a while back with v2
<jdub> ajmitch: Nafallo just did an upload
<Nafallo> hmm, that's right. apt-proxy 1.9.31 is v2 :-P
<jdub> Nafallo: oh!
<jdub> in that case, i will try it again :-)
<Nafallo> that wasn't exactly obvious, no ;-)
<ajmitch> heh
* ajmitch has been getting frequent md5sum errors with it, quite frustrating
<Nafallo> ajmitch: oh?
<ajmitch> yeah
* jdub does his best shocked impression
<jdub> it depends on python-bsddb3?
<ajmitch> often fixed by rm Packages* & Release*, and restarting apt-proxy so it refetches them properly
<jdub> WARNING! WARNING!
<jdub> CONFIDENCE SLUMP!
<Nafallo> the only troubles I had is when I sync the Package files and end up with diffrent Releases and Release.gpgs ;-)
<jdub> has anyone taken over 'upstream' maintenance of apt-proxy?
<ajmitch> Nafallo: that's probably what I see, except that it caches the mismatched file & causes anger to rise :)
<Nafallo> ajmitch: that's why I tweaked my cronjob times to a "safe-zone" ;-)
<Nafallo> :25 :55
<ajmitch> I had pbuilder doing an update in the pre-build hook
<Nafallo> ajmitch: hehe. I know ;-)
<jdub> Nafallo: apt-proxy is a strong candidate for shifting to main in breezy+1, if it works well ;)
<mpt> fabbione: ping
<Nafallo> jdub: I know ;-)
<Chipzz> jdub: a friend of mine used to run it, and it caused quite a bit of trouble
<Chipzz> buggy etc
<ajmitch> jdub: 'works well' is the issue here
<Chipzz> not sure if it's actually worth the trouble
<jdub> mm, i'll test it this week 
<Chipzz> jdub: it has major issues with resuming downloads iirc
<jdub> if it ends up being as annoying as it used to be, i'll be sad
<Nafallo> hmm
<ajmitch> Chipzz: you mean, it doesn't :)
<Nafallo> is it supposed to resume things? :-)
<jdub> and then i will bounty some fixage!
<Chipzz> it just sees the partially downloaded file, and doesn't see it's only partial, and then apt gets upset because it has the wrong checksum etc...
<Chipzz> ajmitch: sth like that :)
<mpt> jdub: Is "gnome-panel --version" the canonical API for getting the running version of gnome?
<jdub> mpt: gnome-about --version is closer
<mpt> ta
<jdub> but /usr/share/gnome-about/gnome-version.xml is meant to be most useful
<Chipzz> jdub: btw, I just noticed hal-device-manager has a missing dependency. not sure who maintains it
<mpt> Gnome gnome-about 1.0
<mpt> em
<jdub> oh, not gnome-about;
<jdub> anyway, use the xml file
<mjg59> elmo: Ok, got it working
<jdub> Chipzz: file bug :)
<Chipzz> yea :)
<Chipzz> now I just need to recall what package was missing :P
<mjg59> elmo: 4 line patch to ndiswrapper
<mpt> thanks jdub
<elmo> mjg59: I guess I should un-P-a-s it then?
<mjg59> elmo: Yeah, I'll get this stuff into the kernel
<elmo> k, done
<mjg59> elmo: Ah, interesting. That error exists, but the file it's in isn't supposed to be build on 64-bit targets
<elmo> mjg59: well it was a custom compile, I suppose I could have SNAFUed the .config
<mjg59> elmo: Nah, the makefile is broken
<elmo> oh, ok
<mjg59> elmo: It's being unconditionally built
<CarlFK> mjg59 - any idea how I can fix my cpu fan problem?  (forcing the fan on all the time is fine)
<mjg59> CarlFK: Get your vendor to fix your DSDT, by the looks of it
<CarlFK> swell.  thanks
<Nafallo> baah, bed. laters :-)
<mjg59> CarlFK: I'm afraid that the information you've given is enough to say "The problem can be fixed in the DSDT", but not what the problem actually is
<mjg59> If it can only be fixed in the DSDT, your options are either to get a fixed BIOS or to generate a fixed DSDT and put it in the right place for mkinitramfs to pick it up
<CarlFK> woa.. check this out: http://acpi.sourceforge.net/dsdt/view.php?id=168  
<CarlFK> Last Modified       2005-08-28 - how handy
<mjg59> elmo: Ok, the kernel stuff should be fixed soon
<jtan325> ohh i was undert the impression you could move existing open channels
<jtan325> it works if i do /j in the new split window
<jtan325> oh whoops, sorry, wrong channel everyone
<daniels> h/win 30
<benplaut> anyone here with slow system willing to test something for me (just see how low-resource something is)
<daniels> In parallel, once Xorg 7.0 is released, we will start using the individual module sources to replace existing components of the main Solaris X11 tree, which is currently a mix of X11R6.0, X11R6.4, X11R6.6, XFree86 4.3, X11R6.8, Sun enhancements and 3rd-party code.
<daniels> sounds like even more fun to manage than ubuntu's xorg
<jdub> daniels: the solaris post from alanc?
<daniels> yeah
<CarlFK> benplaut - is P2-333 slow enough?
<benplaut> yeah, sure
<CarlFK> what cha wants me to do?
<benplaut> pretty much, could you test how low resource it is to have Openbox WM, Perlpanel, and rox-pinboard as a minimal DE?
<benplaut> i don't need any benchmarks, just to see if it's fast enough for regular use
<CarlFK> are they all in main?
<benplaut> i think universe...
<CarlFK> k
<ivoks> hm....
<ivoks> gnome-media has version 2.6.12-O
<ivoks> pardon, 2.6.12.O
<ivoks> not number, letter... is that on purpose?
<crimsun> (seems like a mistake)
<ivoks> i know :)
<ajmitch> well it'll at least be < 2.6.12.0
<ivoks> :)
<ivoks> will it?
<ivoks> i'm not sure... isn't O > 0?
<ivoks> and we use 0ubuntu1 just because nothing is lower then 0
<benplaut> -1?
<mpt> O for Oarsome
<ajmitch> "all the letters sort earlier than all the non-letters."
<ivoks> ok
<ivoks> then it isn't a problem
<ajmitch> yep
<daniels> daniels@ephemera:~% dpkg --compare-versions 2.6.12.0 lt 2.6.12.O && echo zero is less than oh
<daniels> zero is less than oh
<ivoks> hm
<ivoks> houston, we have a problem
<daniels> 2.6.12.O.1?
<daniels> or .O.0
<ivoks> that would look... hm... :)
<daniels> eh, I've done 1.0 and 1.0.0 as different upstream versions before :P
<ivoks> time to go...
<ivoks> bye
<Mithrandir> daniels: you can trick the archive by packaging a version as native, then waiting until it's dropped from the archive, then readding it, but I think it makes elmo and baby jesus cry.
<daniels> Mithrandir: oh, *dude*
* Mithrandir whistles
<daniels> (but I'll remember that one for next time)
<Mithrandir> I'm sure elmo and not to mention launchpad is going to love that one.
<daniels> pschaw
<ajmitch> Mithrandir: that just sounds a little dirty
<Mithrandir> ajmitch: no shit
<daniels> ajmitch: no more dirty than 1.0 and 1.0.0 being different upstream versions :P
<daniels> luckily I didn't have to go to 1.0.0.0
<bob2> at least you didn't do 1.O
<daniels> haha
<daniels> 1.P
<bob2> I wonder how many unicde characters look like O
<bob2> mako!
<daniels> 1.
<bob2> if only I had a compose key right now
<daniels> setxkbmap -option compose:ralt
<bob2> wm
<bob2> hm
<bob2> that broke my terminal
<daniels> heh, that looks more like a deadkey than a compose key
<daniels>  dv   mxd  p
<mpt> http://lists.w3.org/Archives/Public/www-style/2003Apr/0012.html
<bob2> you need a big baseball bat
<pitti> Good morning
<benplaut> 'mornin
<jdub> mjg59: oh man, this laptop-mode related freeze is ROOOLY annoying
<daniels> not X's fault
<jsgotangco> heh
* jdub comments out all the hdparm -B lines to see if that helps
<desrt> http://lists.w3.org/Archives/Public/www-style/2003Apr/0017.html <- best reply
<pitti> Hi seb128 
<pef> hi
* seb__ kicks the dsl
<Vaske_Car> does Ubuntu using same commands for shell as Fedira?
<seb__> hey pitti
<pitti> Kamion: why did the CD building stop? the last CD is from Friday, so jigdo fails...
<Vaske_Car> Fedora*
<pitti> Vaske_Car: if you are talking about basic shell commands, they are the same in every Linux
<jdub> Vaske_Car: yes - you're probably better off asking questions like this in #ubuntu
<Vaske_Car> there is no channel with that name :(
<daniels> Vaske_Car: i can assure you that there is, but you may have to register to join it
<Vaske_Car> I think I found... thanks!
<seb__> pitti: they rolled g-v-m 1.4.0 if you want to package it
<jdub> SEBERINO!
<seb__> hey hey jdub
<pitti> seb__: hm, there is already 1.5.1 or so
<pitti> seb__: but last time I rather used the 1.3 microrelease to not break everything again
<seb__> pitti: but you were packaging 1.3 not 1.5, no?
<seb__> pitti: 1.4 is the 1.3 tarball for GNOME 2.12
<pitti> seb__: do you want the new version? I can package it 
<pitti> ah, ok
<jdub> fejj has not been uploading tarballs or telling anyone he was rolling them (!!!)
<seb__> pitti: we want GNOME 2.12 yep
<pitti> seb__: ok, I do it
<seb__> thanks
<seb__> jdub: right
<pitti> jdub: yes, I asked him to announce his tarballs on the Utopia list
<jdub> he has upload love now
<dholbach> good morning
<pitti> Hey dholbach 
<dholbach> hey pitti :)
<ajmitch> hi pitti 
<pitti> Hi ajmitch 
<pitti> jdub: Jeff, the new g-v-m uses totem as default CD player instead of gnome-cd. Shall I change this back or is that ok?
<pitti> jdub: (gnome-cd is much nicer IMHO, it supports CDDB and has a more cd-player like interface)
<dholbach> elmo: could you please sync phpgroupware, zsync, affix, proftpd from sid - security related fixed, thank you
<jdub> pitti: it should use sound-juicer
<pitti> jdub: for audio CD playback?
<kagou> there is no more daily iso releases. I can't see on https://wiki.ubuntu.com/BreezyReleaseSchedule?highlight=%28release%29%7C%28breezy%29 a date for a previewfreeze iso or previewrelease iso 
<ivoks> eh, goobox is even better solution, but it's in universe
<kagou> any scheduled ?
<pitti> kagou: I already asked Kamion
<pitti> kagou: probably just a glitch, we certainly did not disable it deliberatley
<kagou> ok thanks pitti , i'm waiting for a new breezy daily for my notebook testing
<jdub> pitti: absolutely
<jdub> pitti: that should be the default upstream too (in the latest releases)
<pitti> jdub: it does not even allow me to specify a device on the command line
<pitti> jdub: default is totem %h
<pitti> Hi mvo
<jdub> pitti: in which release?
<pitti> jdub: 1.4.0
<jdub> probably fixed in 1.5
<pitti> yes, maybe
<pitti> anyway, I can change it easily
<pitti> but I cannot call it with a particular device
<pitti> I don't want to start sound-juicer with the default CD drive, but for the particular drive where g-v-m just detected a new CD
<jdub> pitti: interesting one. maybe talk to ross about it.
<pitti> ok
<mvo> hey pitti, good morning all
<pitti> jdub: in 1.5.1 it is still totem %d
<pitti> Hi carstenh 
<carstenh> hi pitti 
<jdub> pitti: i'll ping a few people about it tonight too
<pitti> jdub: ok, I leave totem for now, switching is easy (just a gconf schema change)
<jdub> yeah
<jdub> if the s-j stuff doesn't work out, we should stick with gnome-cd though
<pitti> ack
<pitti> totem behaves weird when playing a CD
<pitti> the main window (where videos appear) is empty and resizing the window destroys it
<pitti> and no cdda
<pitti> gosh, all these apps shuold be unified
<pitti> gnome-cd, totem, sound-juicer, whatnot
<pitti> serpentine
<Lathiat> well sound-juicer is supposed to get rid of gnome-cd
<pitti> yes
<Lathiat> its not 100% obvious however
<jdub> Lathiat: it will be when gnome-cd disappears in 2.14
* Lathiat nods
<pitti> jdub: will sound-juicer and serpentine merge, too?
<pitti> or, even better, s-j and serpentine be merged into rhythmbox?
<jdub> pitti: dosn't seem sensible to merge everything
<jdub> rb uses s-j to do ripping
<jdub> rb will get cd burning functionality
<pitti> that's already a step forward
<jdub> serpentine supports other functionality too
<pitti> but a single separate app to burn audio CDs seems too much
<jdub> yeah
<jdub> however, including a k3b like application for advanced burning requirements that includes that feature is not silly
<pitti> well, yes
<pitti> but it would be nice to burn CDs directly from rb
<jdub> but i wouldn't put it in the default install ;)
<jdub> yeah, that's going in
<pitti> cool
<sivang> morning all
<sivang> jdub: are you going to IBM today?
<jdub> sivang: tomorrow
<infinity> Ever since the battery applet was updated to use HAL, rather that use /proc directly, it's decided I don't have a battery.
<infinity>  /proc/acpi/* looks fine, but the "Device manager" application tells me I have a battery bay, but no battery.
<daniels> hmm, me too.
<infinity> Note that I probably booted without a battery, which may or may not make a difference.  I haven't tested.
<Mithrandir> infinity: ACPI doesn't appear to do hotplug.
<infinity> So, if I boot WITH a battery, so that mean I'll always have one, even when I take it out?
<infinity> And vice versa when I boot without one?
<infinity> PROGRESS!
<pitti> infinity: humm, no idea - does restarting hal help? (this will break your gnome session, though)
<daniels> yeah, I just checked here, and restarting hald fixes
<mvo> Kamion: permission to upload a new coreutils with documentation fix (http://paste.ubuntulinux.nl/1924)?
<pitti> infinity: I don't have an ACPI battery, and on my powerpc, hotplugging the battery works perfectly with hal
<daniels> pitti: hotplugging the battery just doesn't work here, you have to restart hald
<daniels> pitti: (acpi, x40)
<infinity> Great, so does that mean we get ACPI to generate hotplug events, or roll back the battery applet change?
<daniels> DOES NOT WORK ON X40.  SEVERITY: BLOCKER.
<infinity> Or, T40 in my case.
<infinity> (T43, but same thing)
<pitti> infinity: but I heard so many complaints about the hal acpi backend, maybe the applet should be switched back to proc for now...
<pitti> Mithrandir: teaching ACPI hotplug is not something we could possibly do for breezy, is it?
<infinity> s/maybe/definitely/ if we can't afford to time to make ACPI DTRT.
<infinity> s/to time/the time/
<Mithrandir> pitti: quoting mjg59 from memory: "Adding hotplug to the ACPI subsystem is quite a bit of work".
<pitti> I guess so
<daniels> just re-read from /proc/acpi every five seconds
<pitti> hm, now that you mention it, hal is supposed to do exactly that
<pitti> infinity: does running hald in debug mode reveal anything interesting?
<pitti> infinity: sudo killall hald; sudo hald --verbose=yes --daemon=no
<daniels> 11612: 17:59:41.888: addon-acpi.c:139: ACPI event battery BAT0 00000080 00000000
<infinity> What's the point of all our inotify crack if we're going to poll /proc?
<daniels> 11612: 17:59:41.888: addon-acpi.c:145: event is 'battery BAT0 00000080 00000000'
<daniels> 11612: 17:59:41.888: addon-acpi.c:167: battery event
<daniels> 17:59:41.889 [I]  hald_dbus.c:2693: local_server_message_handler: destination=org.freedesktop.Hal obj_path=/org/freedesktop/Hal/devices/acpi_BAT0 interface=org.freedesktop.Hal.Device method=Rescan
<daniels> [...] 
<daniels> 17:59:42.105 [D]  hald_dbus.c:2096: udi=/org/freedesktop/Hal/devices/acpi_BAT0
<daniels> gar.  it seems to work now.
<pitti> daniels: do you see anything periodic?
<pitti> which looks like polling?
<pitti> hmm
<pitti> daniels, infinity: how long is your session running already?
<daniels> gar, bloody heisenbug.
<daniels> pitti: a week? more?
<pitti> daniels, infinity: or, rather, when did you boot the last time?
<infinity> A day or two?.. I crash almost daily, so it can't have been long.
<daniels> oh wait, I accidentally pulled the power cord out a couple of days ago
<daniels> yeah, a day ago
<pitti> daniels: we don't restart hal on upgrades any more, so you might have missed the recent fixes
<pitti> hm, ok
<infinity> How recent?
<pitti> then you have the latest version already
* infinity checks the changelog.
<pitti> infinity: one, two weeks
<infinity> Oh, yeah, that was ages ago.
<infinity> I'm definitely running that version.
<dholbach> oh a new testbuild of the archive is running... good :)
<ogra> Kamion, around already ? 
<dholbach> hey ogra 
<ogra> hi
<sivang> hey again dholbach , ogra 
<Mithrandir> uhm, where did libxaw8-dev go?
<infinity> Far, far away.
<infinity> daniels : What's the final word on the 8000 versions of Xaw?
<ogra> doko_, ping re openoffice in edubuntu
<sivang> btw, nice to see all those 8200 inspiron buttons working, however when used to higher and lower the volume, the mouse input and the keyboard input sometimes stucks
<daniels> infinity: xaw7 is good, xaw6 is dead, xaw8 was stillborn
<ogra> doko_, openoffice1 isnt and wasnt in edubuntu since weeks... i wonder why anastacia thinks it is
<infinity> daniels : Any chance of convincing gravity to drop Xaw8 form Debian as well, to avoid confusion?
<daniels> infinity: doubt it.  xprint isn't going to die in debian.
<infinity> Ahh, xprint needs xaw8?
<Lathiat> daniels: any idea whats up with gl stuff?
<Mithrandir> infinity: so stuff needs to build-dep on libxaw7, or?
<infinity> Mithrandir : Please.
<ogra> doko_, what is mozilla-openoffice.org ? there is no reference in the archive
<infinity> daniels : Erm, Xaw8 and XP don't seem to relate much at all.  Were those two disconnected thoughts?
<ogra> err... heh, not on amd64 indeed
<Mithrandir> infinity: I'm looking at nas now, so you can take that off your radar, if you want.
<daniels> infinity: no, not at all.  the only difference between xaw7 and xaw8 is that the latter has the xawprintshell* widgets, which all use xprint.
<daniels> infinity: so xaw8 needs xprint.
<doko_> ogra: mozilla-openoffice.org is a plugin
<daniels> infinity: similarly, the bump from 6 to 7 was to add the tooltip widgets, which iirc introduced a dep on render.
<infinity> daniels : Ahh, the relation is the other way around.  Check.
<ogra> doko_, but it cant be the cause for openoffice1 staying in edubuntu i guess ?
<siretart> btw
<Mithrandir> ogra: m-ooo isn't in ooo1, iirc
<doko_> no, it's built from ooo2
<ogra> hmm, then i wonder why anastacia blames edubuntu-desktop
<siretart> could an xorg guru have a look at xfig? it builds and starts fine, but it complains about the app-defaults file and freezes as soon as you want to draw something
<siretart> and I have really no clue what that could be :(
<ogra> doko_, does that look sane to you ? 
<ogra> ogra@honk:~/seeds--breezy--0--base-0 $ grep openoffice *
<ogra> desktop: * openoffice.org2 [i386 powerpc amd64] 
<ogra> desktop: * openoffice.org2-gnome [i386 powerpc amd64] 
<ogra> desktop: * openoffice.org2-evolution [i386 powerpc] 
<ogra> desktop: * mozilla-openoffice.org [i386 powerpc]         # built from openoffice.org2
<ogra> supported: * openoffice.org2-dev
<ogra> supported: * openoffice.org2-dev-doc
<ogra> supported: * openoffice.org2-officebean
<ogra> its like that since more then 2 weeks...
<bob2> mozilla-openoffice.org: two great tastes that taste great together!
<ogra> haha
<jdub> i'm actually kinda concerned about that package
<jdub> it is very badly described
<jdub> but it suggests to me that it's designed to host OOo in mozilla/firefox windows
<jdub> if that is the case, i would like it removed from the desktop seed
<jdub> http://gemal.dk/blog/2004/09/22/openofficeorg_mozilla_plugin/
<jdub> bugger
<pitti> elmo: please sync python2.3
<jdub> mdz: around?
<jdub> however unlikely
<infinity> wasabi : ping.
<Kamion> 08:17 < pitti> kagou: probably just a glitch, we certainly did not disable it deliberatley
<Kamion> pitti: er, we did :)
<pitti> Kamion: hm? why?
<Kamion> pitti: I turned them off so that Colony 4 pre-release testing wasn't a moving target
<pitti> Kamion: Good morning, ntw
<Kamion> it'll go back on today
<pitti> ah, ok
<Kamion> ogra: yes?
<pitti> Kamion: would be nice to download the current CDs for testing
<ogra> Kamion, base-config/_late_command still doesnt work :(
<Kamion> mvo: yes
<mvo> Kamion: thanks
<Kamion> ogra: /var/log/base-config*.log should help
<ogra> Kamion, additionally is there a base-config commad i can use to force the user to put in the CD and mount it ? i'd like to run ltsp-build-client with the CD as archive...
<ogra> Kamion, similar to apt-cdrom, just not with apt-cdrom ;)
<ogra> hmm, /var/log/base-config-pkgsel.log only shows a lot of documentation registration (xml) errors ... 
<doko_> ogra: it looks sane, but I still don't know, why the OOo1 versions are in the anastacia output
<ogra> doko_, me neither... either it grabs an very old version of my seeds or there is a bug in the script
<ogra> Kamion, could it be that if there is an error at the end of the normal installation process, base-config/late_command isnt run ? there are only xml registration errors at the end of the log
<ogra> Kamion, no hint that ltsp-build-client is even attempted to get run
<doko_> pitti: if you do have time, could you review the zope* packages, including schooltool?
<ogra> that'd be great :)
<Kamion> ogra: there's nothing like that in base-config; you'd have to write it yourself, but it would be a very poor UI
<Kamion> ogra: can it be done in the first stage instead?
<pitti> doko_: ALL zope packages?
<pitti> is that really a good idea two days before the preview?
<pitti> *sigh*
<Kamion> ogra: scrollkeeper errors wouldn't prevent the late_command from running, I wouldn't think
<mdz> jdub: ?
<Kamion> we ignore errors from scrollkeeper-update
<ogra> Kamion, i need ltsp-server-standalone installed for ltsp-build-client.... if its possible to run it in the frist stage i'm open for everything... i just dont know if stacking chroots is a good idea ;)
<Kamion> there's no issue with stacking chroots
<ogra> oki
<Kamion> how much does ltsp-server-standalone depend on?
<pitti> doko_: why do we need both zope 2 and 3?
<doko_> pitti: come on, not that much ...
<ogra> err, it only needs to be ltsp-server, sorry
<ogra> Depends: debootstrap, nfs-kernel-server, tftpd-hpa, netkit-inetd, syslinux | mknbi | mkvmlinuz
<doko_> pitti: these are two different things. you need zope3 for schooltool/schoolbell, and zope2 for plone
<pitti> doko_: 17 packages? that will take some hours, I regard it as "much" :-)
<ogra> Kamion, and the CD contents for debootstrap
<Kamion> one could write an ltsp-client-installer udeb that installs that and does ltsp-build-client
<ogra> hmm...
<Kamion> (before the CD's umounted)
<ogra> so it seems i have to learn about udebs ? 
<Kamion> it's not that hard :)
<Kamion> apt-install ltsp-server; chroot /target ltsp-build-client
<ogra> since tey work like normal debs, is it only a dependency issue anda postinst that calls ltsp-build-client ?
<Kamion> with some progress bar stuff around that, probably
<Kamion> they don't quite work like normal debs in that udebs cannot depend on debs
<ogra> ah
<jdub> mdz: can we please remove mozilla-openoffice.org from the desktop seed? it is an undesireable feature to have by default.
<ogra> mdz, while youre here, any idea why anastacia thinks edubuntu-desktop wants ooo1 ? its dropped from the desktop seed since more then two weeks...
<ogra> (and yes, i mergerd several times since)
<mdz> jdub: doko recommended it
<jdub> mdz: embedding file views in browsers is completely bongtastic
<mdz> ogra: probably an out-of-date architecture
<jdub> cool feature for people who want it
<jdub> but not by default
<ogra> ah, ports :) i forgot about them :)
* Mithrandir looks at the memprof package an falls over.
<Kamion> ogra: you're not building edubuntu-meta for hppa and sparc any more, but they're still in the archive ...
<Kamion> old versions thereof
<ogra> Kamion, just fixing ;)
<\sh> morning gentlemen
<ogra> there was a connectivity prob with ports.ubuntu.com from here that always broke my metapackage geeration...
<Kamion> mdz: do you have a summary of live CD changes since Colony 3?
<Kamion> other than "many fixes" :-)
<ogra> Kamion, are you aware that ubuntu-quickguide disappeared on friday ? 
<Kamion> ogra: see the bug I filed
<ogra> (broke my CD)
<ogra> youre too fast ;)
<Kamion> also, anyone else got anything they want mentioned in Colony 4 release notes (major stuff changed since Colony 3)?
<Mithrandir> is memprof completely broken for everybody else?
<ogra> its not installable here (amd64)
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion/ | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | Colony 4 is released: http://cdimage.ubuntu.com/releases/breezy/colony-4/ | PreviewFreeze: no uploads without approval https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs
<Kamion> (topicdiff: Colony 4 released)
<daniels> Kamion: congratulations
<Lathiat> woo :)
<Lathiat> good timing too i can test it on my enw laptop
<Kamion> if you've tested CDs over the weekend, they're the same :)
<Lathiat> nah
<jsgotangco> wooo
<pitti> Kamion: yay, thanks
<jsgotangco> Colony 4 is sept 2?
<pitti> Kamion: will you also enable the building of today's dailies?
<Kamion> pitti: already have; cron.daily is running
<Kamion> jsgotangco: colony-4 == daily/20050902.3 + daily-live/20050903
<jsgotangco> right thanks
* mvo waves to zyga 
<Lathiat> ok question... is the hoary installer supposed to let you resize ntfs?
<zyga> mvo: hello :)
<zyga> mvo: I've got breezy on my other box so I can easily work now :)
<mvo> zyga: great!
<pitti> doko: is there any reason why the zope3 package is not arch:all?
<Kamion> Lathiat: yes
<Kamion> modulo bugs
<doko> pitti: no, if we included the python-zopeinterface stuff, then it's arch any, else it's all. we will sort that out for the final release
<Lathiat> Kamion: hrm, how do i get to that option?
<pitti> doko: ok; it's not a biggie anyway, just asking
<pitti> doko: same for zope3-lib?
<doko> pitti: zope3-lib isn't built anymore
<pitti> ah, I see; that was still the old version
<Mithrandir> Kamion: ok to upload memprof with http://err.no/patches/memprof_0.5.1-9_0.5.1-9ubuntu1.FTBFS.diff ?
<Kamion> Lathiat: find the "Size" field in the screen for the partition in question, press enter, type new size
<Lathiat> Kamion: oh ok
<Lathiat> has that been made more obvious in breezy? i seem to remember seeing a resize option on a breezy cd
<Kamion> Mithrandir: yes
<Kamion> Lathiat: no
<Lathiat> hmm
<Kamion> Lathiat: the auto-resize thing is different; if you don't need fine control, you can use it, but the normal resize option is the same
<zyga> is upgrade from warty to breezy supposed to be seemless?
<Lathiat> zyga: ergh, that sounds nasty, im not even sure hoary works at the moment? :)
<Kamion> zyga: it would be nice, but not much effort has gone into it; I'd suggest going via hoary
<zyga> Kamion, Lathiat: I've just done that upgrade w->b and the only issue I've found is x-related
<zyga> a file rgb.txt is both in xfree86-common and xorg-common 
<zyga> manual --force was needed (I guess one package does not replace the other in the specs file)
<zyga> other than that it was really automatic :)
<infinity> zyga : xorg-common conflict with xfree86-common..
<infinity> zyga : Which should take care of that.
<zyga> infinity: maybe it was in other xorg-* stuff than, because it borked
<zyga> mvo: who can I annoy about i18n bug in synaptic?
<infinity> zyga : Ah-ha.  It was xrgb, which ships /etc/X11/rgb.txt
<zyga> :-)
<zyga> infinity: another squashed bug :-) ?
<infinity> daniels : xrgb needs to Replaces: xfree86-common, for /etc/X11/rgb.txt
<Lathiat> ugh i dont think that worked
<mvo> zyga: me most likely
<zyga> infinity: gret, I'll install warty again in 24 hours
<Lathiat> considering it took practically no time to resize if it did
<zyga> mvo: I'd like to have 'translations' substituted to 'Translations' (consistency) and marked as translatable
<zyga> mvo: If that's okay with you I'll prepare and test a patch
<infinity> zyga : It won't be terribly high priority to fix.  There are still plenty of more pressing things than warty->breezy updates, but I'll make sure daniel gets the fix in his local tree, and uploaded "sometime before release".
<zyga> infinity: great, thank
<mvo> zyga: I would be happy if you would do this, thanks
<infinity> zyga : If you want to test more esoteric warty->breezy upgrades (and hoary->breezy upgrades, which we probably care more about), bug reports would be appreciated.
<Diziet> So if I want to pick some random bug off ubuntu-bugs and fix it, is there a lightweight way to check that no-one else is on it already ?  Should I assign it to me in the bugzilla ?
<infinity> zyga : Minor severity for warty->breezy, probably, Important for hoary->breezy.
<zyga> infinity: is there any way to get a .iso of latest hoary with all the upgrades applied?
<infinity> zyga : The best way to get an up-to-date installation is by using a netinst, so it installs the newest packages by default...
<infinity> zyga : Local mirrors are nice for that.
<zyga> infinity: I thought you'll say that :/
<daniels> infinity: blah
<Diziet> Well, I'll do that and see if it works.
<Diziet> No, the bugzilla won't let me assign the bug to myself.
<Kamion> !
<Kamion> ogra: I thought you gave Diziet editbugs
<Kamion> Diziet: generally anything assigned to debzilla@ubuntu.com is fair game
<Kamion> that's a sort of "nobody" address
<Diziet> It says in Permissions that I have editbugs.
<Diziet> k: Right.
<Kamion> I have bz_canusewhines, canconfirm, editbugs, editcomponents; I doubt the others are relevant
<Kamion> what does it say when you try to reassign?
<Diziet> It doesn't appear to offer such an interface.
<ogra> hmm, i gave Diziet editbugs... 
<Kamion> I have a "Reassign bug to ..." radio button in the block of stuff just above the "Commit" button.
<Diziet> If I look at one of my own bugs I have a list of radiobuttons below the comment box.
<Diziet> If I look at (say) http://bugzilla.ubuntu.com/show_bug.cgi?id=12604, I have only  [*]  Leave as NEW
<Kamion> Maybe it requires the use of cookies to remember who you are when using HTTP rather than HTTPS?
<pitti> ogra: it is ok that schooltool deb is almost empty?
<Diziet> https makes no difference.
<Kamion> no, even wget on the URL you gave gives me a reassign option
<Diziet> And I've accepted its cookies.
<zyga> mvo: any reason for POTFILES.skip in synaptic?
<ogra> pitti, it runs, so i think its ok :)
<mvo> zyga: IIRC someone of the translators requested it to make it's life easier
<zyga> mvo: it contains just two or three really meaningfull messages
<zyga> I'll ignore that for now
<ogra> pitti, erm, the source package is 35M here
<ogra> (unpacked)
<Diziet> Kamion: what permissions do you have listed ?  I have bz_canusewhines, canconfirm, editbugs.
<Kamion> Diziet: 11:31 < Kamion> I have bz_canusewhines, canconfirm, editbugs, editcomponents; I doubt the others are relevant
<pitti> ogra: yes, but the deb is tiny
<zyga> mvo: patch for synaptict is ready, I'll test it, fetch fresh pl.po, sync and mail you
<ogra> pitti, hmm, probably because its not running all the zope stuff ? 
<Diziet> Maybe editcomponents is what's needed.
<ogra> pitti, it runs standalone
<Kamion> no, editcomponents lets me add new packages, remove packages, change default assignees, etc.
<Kamion> it's an administrative privilege
<Kamion> and, as I say, a completely unauthenticated wget gives me the reassign option
<mvo> Kamion: permission for uploading http://paste.ubuntulinux.nl/1925 please?
<Kamion> mvo: yes please
<Mithrandir> ew: ./libdv.h:#define u_int64_t unsigned long long
<Diziet> kamion: Yes, a wget gets the right thing for me too.  View Source in my Mozilla shows the lack of the relevant bits in the source.
<zyga> mvo: synaptic + rosetta = b0rked https://launchpad.net/products/synaptic/+translations
<Diziet> Ahhh.  I asked to log out and it said `Your login has been forgotten. The cookie that was remembering your login is now gone. You will be prompted for a login the next time it is required.'
<mvo> zyga: yes, I was told some days ago. rosetta is not able to handle a package that contains more than one pot file per directory. synaptic has one for it's messages and one for the documentation
<zyga> mvo: k, noted
<Diziet> Oh, I see, that message was `has _now_ been'.  But anyway, logging out and in again didn't help.
<Diziet> But when I'm logged out I can see all the extra options.
<Diziet> Did I mention how lame I think bugzilla is ?
<Kamion> well, I'd tend to agree
<Kamion> (obviously)
<mvo> zyga: I need to split it into po and help-po or something, but I hate fiddling around with the poxml makefiles
<Diziet> I asked to reassign, and it told me to log in, and when I did, it said:  ` You tried to change the Assignee field from 2 to ian@davenant.greenend.org.uk, but only the owner or submitter of the bug, or a sufficiently empowered user, may change that field.'
<Kamion> "from 2"?!
<Kamion> hmm, I still have a login on the bugzilla box; let's see where that lives
<Diziet> Cripes.  I asked it to change my email address and that requires confirmation from the new address and mere inactivity from the old.
<Diziet> Although you do need the password.
<Mithrandir> Diziet: well, then it's safe, given that people will try to change it _after_ their old mail address has stopped working.
<Kamion> the only place I can find that message is in a CVS backup file
<zyga> mvo: what are PreDepends?
<Kamion> oh, right, I don't have read access to everything
<Keybuk> zyga: dependencies requires to unpack a package
<Keybuk> usually programs the package runs in its "preinst" file
<Keybuk> as opposed to Depends, which are only required once the package is to be configured
<zyga> Keybuk: k, understood
<Kamion> anyone with editbugs certainly ought to be able to change anything, per the code
<doko> Kamion: you did comment on bash_completion to be too slow to be enabled as a default. Looking at our target audience, does it matter for them?
<ogra> except the default asignee etc
<Kamion> ogra: right, anything that's part of an individual bug I mean
<ogra> yup
<Kamion> doko: *shrug* it was just my opinion, if you want to override it that's your prerogative as a maintainer
<ogra> i have heard no complaintments so far...
<Kamion> our audience includes a lot of people on slow machines in my experience
<doko> sure, it's a tradeoff. otoh, you have the option to disable it.
<doko> but you don't know, that you have it, if it's disabled
<pitti> doko: it might confuse people who don't know about it
<pitti> doko: on my shell, pressing tab-tab sometimes causes 10 seconds of 100% cpu usage and blocks the input
<doko> really 10secs?
<zyga> mvo: tested, works great - do you want the whole diff (with lots of .po changes due to make update-po) or just the small one + pl.po?
<mvo> zyga: please just the small one
<pitti> Kamion: hm, jigdo is still busted; it wants to download debian-installer-manual_20050317ubuntu15.0.20050902_amd64.deb for the 20050905 image, but that doesn't exist in the archive
<mvo> zyga: it may take a bit until I can apply it, the svn server had problems this morning
<zyga> mvo: that's okay - as long as it makes for breezy
<zyga> when one can translate launchpad-integration stuff?
* doko will enable bash_completion by default for breezy+1 and look at the complaints ...
<zyga> s/when/where/
<mvo> zyga: you may need to ask in #launchpad :)
* ajmitch has had bash completion on for awhile ,and notices the slowdown at times
<ogra> Kamion, is there a way to jump around in scriptreplay ? 
<spayne> what is going on with clearlooks in breezy
<spayne> there is only one theme
<spayne> which is a weird blue - not the normal one
<ogra> Kamion, i think i saw the error, but the following stuff vanished to fast
<zyga> mvo: mail sent
<zyga> mvo: will you commit patches to launchpad-integration? (i18n as usual)
<mvo> zyga: thanks! if the launchpad-integration patches are good, I'll apply them
<zyga> mvo: ignore my last mail, syntax error in pl.po
<mvo> zyga: ok
<spayne> orga: you seem to have reported a clearlooks bug, do you know anything about this problem?
<spayne> ogra: it seems that many of the clearlooks themes are missing
<ogra> spayne, i didnt file a bug about clearlooks... 
<spayne> ogra: sorry
<ogra> spayne, and i see all four variants in the package
<spayne> do you?
<spayne> weird
<spayne> i only have one variant in mine
<ogra> Clearlooks, Clearlooks-Olive, Clearlooks-DeepSky, Clearlooks-Quicksilver
<spayne> i have Clearlooks
<spayne> just Clearlooks
<spayne> what package version do you have?
<ogra> 2.6.5-0ubuntu1
<spayne> so do i
<spayne> gtk2-engines-clearlooks
<spayne> wierd
<spayne> weird i mean
<spayne> ogra: what could it be?
<TheMuso> .c
<spayne> ?
<ogra> spayne, hmm, looking into the package it actually only contains Clearlooks
<spayne> which is incorrect
<spayne> as there should be the four themes
<jdub> spayne: clearlooks was included with gtk-engines, and the additional clearlooks (gnome) themes didn't go with it (or into gnome-themes)
<spayne> jdub: so there should only be one theme?
<Mithrandir> infinity: btw, I'm hacking at libquicktime now (for 13728)
<spayne> jdub: but i don't see where that one theme comes from as the blue style is darker than standard clearlooks
<Keybuk> is there any way in Bugzilla to see which components I'm "owner" of ?
<infinity> Mithrandir : You're a machine.  Thanks.
<jdub> pitti: ross is going to do --device support in s-j for gnome 2.12.1
<spayne> jdub: how many clearlooks themes should there be?
<jdub> spayne: one
<ogra> Kamion, found the error, is it possible that $ROOT is set in base-config ? ltsp-build-client calls mkdir $ROOT/... and i find "mkdir: `/dev/sda1' exists but is not a directory" at the end of the log
<spayne> jdub: is there any way to get the other three?
<jdub> get the clearlooks tarball and put them in your own .themes :)
<spayne> but who designed the ONE theme>
<spayne> as it ain't the standard one
<jdub> it was the original clearloks theme but with minor tweaks
<spayne> why was it done?
<jdub> why was what done?
<spayne> getting rid of the other three themes
<spayne> and making a customised one
<jdub> because gnome didn't want to ship 57 themes
<jdub> in gnome-themes
<spayne> oh! it is an upstreamer decision?
<spayne> got it! no other :-)
<tseng> gnome-look.org
<spayne> the corners aren't rounded off properley in ClearLooks either :-)
<spayne> tseng: I am aware of that site
<jdub> spayne: if you reaload metacity, they will be
<spayne> killall metacity doesn't solve it
<spayne> you mean reinstall?
<spayne> shall i report it in the bugzilla?
<zyga> mvo: ping
<zyga> mvo: I'm having problems with build/make magic - I've patched what I needed but pl.po is not being built (I'm talking about l-i)
<mvo> zyga: pong
<zyga> mvo: I've added it to po/LINGUAS
<zyga> could you shed some light?
<spayne> bye
<spayne> thanks jdub
<spayne> and ogra
<spayne> jdub: i will put in a bugzilla report for the corners of the metacity windows
<zyga> dpkg-buildpackage creatates a deb with no .mo files :/
<mvo> zyga: please send me your current diff and I'll have a look. it seems like this hasn't been tested yet and pl.po is the first translation :)
<zyga> mvo: k, one moment
<mvo> terminal server client applet has no icon on a colony4 install. is this a known issue?
<jordi> does anyone know how difficult would be to internationalise a pygtk app like PythonCAD?
<mvo> jordi: does it has any support for i18n already?
<jordi> mvo: doesn't look like it
<jordi> mvo: it doesn't seem to import gettext at all
<zyga> mvo: let's postpone this - I've got to go out for an hour
<mvo> jordi: right. does it use distutils (setup.py)?
<jordi> mvo: yup
<mvo> zyga: please send me the diff/po file and I'll have a look
<zyga> mvo: ok 
<mvo> jordi: than it's going to be a bit tricky because distutils does not nativly support po files. smart or language-selector has example setup.pys that adds support 
<jordi> mvo: in a typical pygtk app, do you need to modify many things besides the needed imports & so?
<jordi> and the _() marks
<mvo> jordi: no, once setup.py is updated it should be straightforward
<mvo> jordi: the language-selector package should be a good example as it's fairly small 
<zyga> mvo: sent
<jordi> mvo: ok
<mvo> zyga: thanks
<zyga> mvo: synaptic stuff resent, I'm away for an hour
<mvo> zyga: thanks
<dholbach> bbiab
<Kamion> ogra: doesn't appear to be
<Kamion> ogra: no, to my knowledge there's no way to rewind/fast-forward in scriptreplay
<ogra> Kamion, i just saw it creates $ROOT based on $MIRROR
<Kamion> aside from specifying a time divisor to start with
<Kamion> MIRROR is only set during apt-setup, which does not enclose late_command
<ogra> thats strange...
<ogra> i have this in ltsp-build-client:
<ogra>   if [ -n "$mirror" ] ; then
<ogra>     echo "deb $mirror" >> $ROOT/etc/apt/sources.list
<ogra>     case $mirror in
<ogra>       file:///*) dir="$(echo $mirror | awk '{print $1}' | sed -e 's,^file://,,g')"
<ogra>         mkdir -p $ROOT/$dir
<ogra>         mount --bind $dir $ROOT/$dir
<ogra>         umounts="$umounts $ROOT/$dir"
<ogra>         ;;
<ogra>     esac
<ogra>   fi
<ogra> obviously $ROOT is /dev/sda1 at this point....
<ogra> its the only mkdir that occurs...
<Kamion> you need to be precise about whether you mean $MIRROR or $mirror
<Kamion> anyhow, mirror isn't set either
<ogra> its not my script...
<Kamion> I mean when talking about it
<ogra> ok...
<ogra> Kamion, can we try this change? : base-config     base-config/late_command        string /usr/sbin/ltsp-build-client --root /opt/ltsp/$(dpkg --print-architecture)
<ogra> just for a testbuild...
<Kamion> can you try testing that locally first?
<ogra> Kamion, it works...
<ogra> i used it several times already...
<Kamion> oh, you've tested it in late_command?
<ogra> nope
<Kamion> that's what I want
<Kamion> before reboot, switch to tty2 and run:
* infinity gets irritated by his inability to debootstrap a woody system.
<Kamion> ogra: sorry, my firefox went insane and I couldn't type anything. while the base system is installing, switch to tty2 and edit /var/log/debconf-seed so that the base-config/late_command line reads as above.
<ogra> ah, ok, thanks... i'll try :)
<Kamion> it's much faster if you can run a test through first that way, than tying up cdimage with test builds
<Kamion> (faster for you as well as for me, probably)
<ogra> yup :)
<ogra> i didnt know that method
<zyga> mvo: re
<Diziet> k: So what should I do about my bugzilla weirdness ?  I can do some other things in the meantime but I'd like to be able to do some of the juicy-looking ubuntu-bugs bugs (and what a lot of them there are!) and it seems wrong to just go around uploading stuff and not updating the bugs.
<mjg59> Diziet: Unfortunately, without being privileged, there's no way to do that
<mjg59> Your user needs to be granted the necessary authority
<Diziet> I've supposedly got the relevant privilege.
<mjg59> H. Odd.
<mvo> hey zyga 
<Diziet> Kamion's views of the interface shows the relevant options, but mine can't manipulate bugs that aren't assigned to me - and the only difference between our permissions is that he has editcomponents.
<mjg59> Diziet: Hrm. 
<Kamion> Diziet: I'd be inclined to mail james.troup@ and see if there's anything useful he can dig out of logs ...
<Diziet> OK, willdo.  I can chase him about that email alias too ...
<ogra> Diziet, did you chage your mailadress since i granted you editbugs ? 
<Kamion> Diziet: which IP address would your mozilla be coming from? Your wget came from xenophobe, but nothing else.
<ogra> change even
<zyga> mvo: any progress? I'm sorry I'm bothering you with this, I reall want to get it going though
<Diziet> kamion: Oh, obviously that wget didn't have the right proxy.  Everything else should look like it came from chiark.
<Diziet> ogra: I'm in the process of changing my address, yes, to an alias which doesn't exist yet.  Is that relevant ?
<mvo> zyga: not yet, I'm busy with bureaucratic stuff 
<ogra> hmm...
<zyga> mvo: okay - I'll play with it some more and see what I can do
<ogra> Diziet, hmm
<ogra> Diziet, iirc bugzilla sends you a confirmation to the new account you need to answer
<Kamion> Diziet: is it worth trying without the proxy?
<Diziet> ogra: Yes.  That's probably lost and I will have to do it again.
<Diziet> kamion: I could give that a go.
<Kamion> that said I'm using chiark as a proxy as well
<mvo> zyga: I'm ready with the other stuff in a couple of minutes
<Kamion> although not for HTTPS
<tepsipakki> hmm, there are still both live and install cd's?
<Diziet> I'm using chiark as a proxy indirectly via davenant, the house proxy.
<Kamion> tepsipakki: yes
<Diziet> That makes it work (!)
<Diziet> Using chiark's proxy directly breaks it again.
<ogra> Kamion, the command worked... do you think it would be appropriate to run apt-ftparchive for /var/cache/apt/archives and use that instead of the cd as installation mirror ? or is it to evil to abuse that dir as archive ? 
<ogra> (deleting Packages and Release files afterwards indeed) 
<Kamion> ogra: I'd much rather have it done in the first stage as I outlined earlier
<ogra> ok
<Kamion> that will also mean you can install stuff all at once rather than worrying about whether packages are installed before or after LTSP
<ogra> true ...
<Kamion> running apt-ftparchive in /var/cache/apt/archives is definitely inappropriate
<ogra> oki, thats what i wanted to know
<Diziet> Oh, no, I was wrong.  It's just that changing my proxy made the bugzilla forget who I was.
<Mithrandir> Diziet: so it was probably set in your session
<Kamion> ogra: I'll apply your suggested preseed change for now
<ogra> Kamion, no... 
<Kamion> no?
<ogra> Kamion, that will need a network connection, i prefer to leave it as manual step post install for the user to be able to install without net
<Kamion> would you rather I removed the late_command altogether then?
<ogra> i.e. mount cdrom && sudo ltsp-build-client --mirror file///cdrom
<ogra> comment it for now
<ogra> if i dont manage to get the udeb ready for preview, its a good fallback
<Kamion> ok, done
<mpt> fabbione: ping
<elmo> pitti: python2.3 is in main
<pitti> elmo: yes; please see http://changelogs.debian.net/python2.3, we did the security patch via Debian for breezy
<elmo> pitti: please confirm with either kamion or mdz
<elmo> as we're in preview freeze
<pitti> Kamion: can you please ack the python2.3 sync? http://changelogs.debian.net/python2.3, only most recent changelog
<elmo> dholbach: done
<dholbach> elmo: thank you
<Kamion> pitti: python2.3 isn't on the CD, so that should be safe enough
<pitti> Kamion: ok, thanks; elmo, can you please sync it? ^
<hunger> pitti: So you still did not look into my cryptodisk script?
<hunger> pitti: Just saw a new version of the deb.
<elmo> pitti: done
<pitti> hunger: oh, I didn't upload it; I think this needs to wait for breezy+1, we are in freezes for weeks
<pitti> elmo: merci
<hunger> pitti: that is somewhat annoying... having to override the changes all the time.
<pitti> humm, this is a conffile, so dpkg shouldn't overwrite it
<hunger> pitti: It creates .dpkg-olds and I end up renaming them back.
<pitti> hunger: only if you say "y" to the dpkg prompt; default is to keep your version
<hunger> pitti: True... but I have to clean up /etc/init.d anyway;-)
<mvo> zyga: looking at the l-p-i patches now
<zyga> mvo: k
<mvo> zyga: not sure that we need patch-2, the launchpadintegration program is pretty much used internaly only
<zyga> mvo: ok, then drop it
<zyga> mvo: I just assumed that --help stuff could be localized but you're right - users won't run this
<Kamion> mjg59: usplash will get installed by base-installer along with initramfs-tools now
<Diziet> elmo: Did you get my mail just now ?
<Kamion> mjg59: I'm just doing a minor base-config fixup to switch to the right VT after disposing of the splash screen, but otherwise it looks fine
<tepsipakki> kamion: are the live&install cd's going to be merged for breezy or is it deferred?
<elmo> Diziet: yes, but I don't even have admin priviledges on bugzilla; you'll need someone who does
<elmo> which use to be in the topic, but isn't any more hmm
<Kamion> tepsipakki: deferred
<Kamion> Matt Zimmerman / Jeff Waugh / Oliver Grawert
<ogra> Kamion, was there a final decision for express ? 
<Kamion> (admins on bugzilla)
<ogra> Kamion, dont forget kiko ;)
<Kamion> ogra: it's too late to replace the install CD for breezy at any rate
<ogra> Kamion, for sure.... i just wanted to know if the spanish express made it in or not ...
<Kamion> see ubuntu-devel@
<mjg59> Kamion: Rock!
<ogra> Kamion, i just see random mails pointing at random packages... no official statement
<Kamion> ogra: alternatively see the line for UbuntuExpress in https://wiki.ubuntu.com/BreezyGoals
<Kamion> "(2005-08-19) deferred, not completed in time"
<Diziet> elmo, ogra: What do you need from me to fix it ?#
<Diziet> s/\#/
<ogra> Kamion, ah, ok... thanks
<doko> ogra: Airport Dornbirn: "Piste-630mGras"
<Diziet> And, elmo, what about my mail alias ?  I want mdz's mails to me to stop bouncing :-).
<doko> better go by train ...
<ogra> doko, vienna?
<Kamion> mjg59: so the install I just did does not display the bare Linux console at any point except right at the start of d-i
<Kamion> oh, and in early userspace at first boot
<mjg59> Kamion: Hurrah!
<Kamion> now just need to work out why the live CD didn't show usplash when I tried it
<doko> ogra: no, not at all ...
<mvo> zyga: l-p-i has your pl.po file now (in my branch that is)
* Kamion laughs at "SIGBOING" in https://wiki.ubuntu.com/USplash
<zyga> mvo: k, does it work?
<zyga> mvo: I wanted to know what else needed patching for the deb to actually work
<mvo> zyga: the debian/liblaunchpad-integration0.install files needs to be updated to include the locale information. I need to ask seb128 if that is the right package for the locales data though
<mjg59> Some day we'll need to figure out what to do with fsck
<zyga> mvo: WaterSevenUb has a po file for you :)
<Kamion> some day == pre-breezy I hope
<mjg59> Kamion: Mm.
<WaterSevenUb> mvo: not yet not yet:D
<mvo> WaterSevenUb: send it to me when it's ready :)
<zyga> mvo: is it apt-get source'able now?
<mvo> zyga: the update l-p-i package? no, not yet. I want to talk to seb128 before the upload and I need to ask for approval
<elmo> Diziet: done
<zyga> mvo: okay great
<Diziet> elmo: Thanks.
<Kamion> mjg59: oh, hang on, usplash disappears at the moment when fsck happens, doesn't it?
<mjg59> Kamion: Yeah, it times out
<Kamion> mjg59: oh, right, that should be fine for breezy then; what other approach were you thinking of?
<mjg59> Kamion: Drawing fsck progress bars in usplash
<Kamion> ah, I see
<Xof> are people interested in xserver-xorg/installer bug reports for PowerPC/G5?  We've managed to hit a screen with "please file a bug report"
<Xof> (breezy colony 4)
<mjg59> Xof: daniels is quite possibly in bed by now, so filing a bug is probably the best plan
<Xof> I was afraid you'd say that.  That means I have to interact with bugzilla again, right?
<mjg59> Yes
<mjg59> I'm sorry
<tepsipakki> d'oh, colony4 dowload stalled
<tepsipakki> at 460MB
<Lathiat> what about usplash on shutdown?
<mjg59> Not yet
<Lathiat> and the scrollbar going backwards? :)
<Xof> is there a way of changing virtual terminals on a ppc?
<Kamion> Diziet: do you have a workaround involving avoiding the proxy, or do you need somebody to assign the bugs to you in the meantime?
<Kamion> Xof: do you have an Fn key on the keyboard?
<Kamion> Xof: if not, it should be either Ctrl-Alt-F<x> or Ctrl-Cmd-F<x>; you might need to press the keys in that order
<Kamion> if so, you may need to use Fn with the F<whatever> key
<Diziet> kamion: Avoiding the proxy didn't help.  I could ask someone to reassign the bugs to me in the meantime but that's going to get tedious quite quickly.
<Diziet> But we could start with 12604.  Assign it to iwj@ubuntu.com - I've changed my bugzilla login.
<Xof> thanks
<pitti> mjg59: here?
<mjg59> pitti: Hi
<pitti> mjg59: I just tried to increase the usplash timeout for module-init-tools, but it does not make any difference
<pitti> mjg59: [ -x /sbin/usplash_write ]  && usplash_write "TIMEOUT 120" || true
<mjg59> pitti: Right. And you have latest usplash installed, and have generated an initramfs with that?
<pitti> mjg59: I even commented out the second line that switches it back to 15
<pitti> mjg59: 0.1-8
<pitti> mjg59: initramfs> not manually
* pitti reconfigures kernel
<Kamion> Diziet: tedious> agreed; 12604> done
<Diziet> Thanks.
<Diziet> I've sent a mail to jdub CC ogra.  Maybe they can fix it ...
<pitti> mjg59: ok, trying again
<ogra> Diziet, see the other channel
<Kamion> mjg59: don't you need to fill in tv again after timeout is updated?
<mjg59> Kamion: Uhm. It is, isn't it?
<Kamion> you only set up tv at the start of event_loop(), so changes to timeout will have no effect
<Kamion> oh, no, sorry
<Kamion> misread
<mjg59> it's reset at every event
<zyga> what has happened to libdps1?
<Kamion> that code would be clearer if the tv setup, FD_ZERO, and FD_SET were just at the start of the loop body instead of outside the loop and at the end of the loop body
<zyga> it was in main in hoary but it's gone in breezy
<zyga> is there any page that tracks such changes?
<Kamion> xorg (6.8.2-17) breezy; urgency=low
<mjg59> Kamion: Ah - I figured it wasn't worth doing if the code is going to exit anyway
<Kamion>   * Disable DPS/psres from building, and remove its packages entirely.
<Kamion>     + This mirrors a change made to upstream, with no objections.
<Kamion> mjg59: those cases all just return;
<mjg59> Kamion: Yeah, which exits
<Kamion> if you used continue;, then I could see the duplication having value
<zyga> Kamion: :/ maya 7.0 needs libdps1 
<Kamion> zyga: -> daniels, I don't know anything more about it myself
<mjg59> Kamion: Oh, I see what you mean. Yeah, that would be clearer.
<zyga> Kamion: okay thanks
<ogra> Kamion, so now do a quick rewrite to use base-config *in* usplash after first boot *G* ?
<pitti> mjg59: yep, initramfs regeneration did the trick, thanks
<Kamion> "quick"
<ogra> heh
<pitti> mjg59: btw, the only thing that fails is "setting console font" (quite understandable)
<mjg59> pitti: Yeah. I need to figure out how to do that.
<pablof> i need change the image of usplash. what the specs of this image ?
<zyga> daniels: ping
<pitti> Kamion: permission to upload https://bugzilla.ubuntu.com/attachment.cgi?id=3554 ?
<mjg59> pablof: 16 colour PNG, colour 0 must be black, colour 1 will be the progress bar, colour 2 will be text, colour 13 must be red
<mjg59> 640x480
<pablof> ok, thanks !!
<Lathiat> mjg59: the colours arent set?
<mjg59> Lathiat: In what way?
<mjg59> The palette is derived from the picture
<Lathiat> like, i would ahve thought 16 colours woudl be like.. 16 colours? 
<Lathiat> but its a set colorset isnt it?
<Lathiat> or are yoru 16 colours a choice from 256 or something?
<mjg59> No, I think it's a fairly arbitrary 16 colours
<mjg59> At least, it seems to work fairly well...
<Lathiat> ah ok
<Lathiat> didnt knwo that
<Diziet> Grrr, I hate dpatch and its ilk.
<Diziet> What should I do about a bug which is in hoary but not in breezy ?  It was introduced in a security patch.
<ogra> Diziet, and it wasnt fixed in hoary if its a sec. patch, that should have gone in there as well
<ogra> s/hoary/hoary ?/
<Diziet> The hoary version of wget has this bug.  breezy's doesn't.  The bug is due to an inaccurate security patch.
<Diziet> Should I just upload with distribution hoary to fix it ?
<ogra> cant we revert it in a security update then ? 
<Diziet> I haven't figured out yet whether the broken bugfix is itself a vulnerability.
<pitti> Diziet: I would like to see the debdiff, then please upload to hoary-security
<ogra> nope, that doesnt work
<Diziet> We don't want to revert it, because then the old vuln comes back.
<Diziet> pitti: OK.
<pitti> Diziet: regressions from security patches are generally fixed by security uploads, too
<pitti> Diziet: but can you please email me the debdiff before?
<pitti> Diziet: I tested the package quite thoroughly, what broke?
<Diziet> http://bugzilla.ubuntu.com/show_bug.cgi?id=12604
<Diziet> The reporter is correct - the code is wrong.  I haven't reproduced the problem, but the fix is straightforward.
<Diziet> I don't seem to have debdiff (the tool) installed anywhere.
<Diziet> Oh, it's in `devscripts'.
<pitti> Diziet: thanks; can you please attach the debdiff right to the bug report?
<Diziet> Willdo.
<Diziet> When you say you want the debdiff, do you mean the difference between the .deb of my test build and that in hoary ?  Because obviously my test build won't be the one going into the actual archive since uploads are just source ...
<elmo> Diziet: debdiff works on .dsc's too
<elmo> I suspect he means that
* Diziet RTFM's.  So it does.
<Diziet> That would make sense.
<pitti> Diziet: oh, yes; debdiff of source packges (between .dsc)
<CarlFK> lol - The "Oh crap, what did I get myself into?" Release.
<lifeless> mdz: can we please update bzr to 0.0.7, it make merge usable. 
<lifeless> mdz: no need to reply, sorted
<CarlFK> what would I do if I wanted a patch considered?  
<CarlFK> http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.7d-2.6.12.patch
<CarlFK> description: http://gaugusch.at/kernel.shtml
<CarlFK> it doesn't actualy do anything unless you pass a kernel parm
<mjg59> CarlFK: Uh, we have that
<pitti> Kamion: os-prober is frozen at 50% on powerpc with a Debian unstable and MacOS installed already; known bug? or is there something I could do right now while it is running (or rather not running)
<CarlFK> awesome
<mjg59> CarlFK: Put a DSDT in /etc/mkinitramfs/DSDT.aml
<Diziet> pitti: Just uploaded that.  The debdiff is in the bugzilla.  Did you want a copy by email too ?
<mjg59> CarlFK: Then regenerate your initramfs
<pitti> Diziet: no, I just look in bz
<Diziet> OK.
<pitti> Diziet: looks straightforward; thanks for fixing!
<Diziet> NP.
<pitti> Diziet: does that also affect warty?
<elmo> Riddell: ?
<pitti> Hi kronoss 
<slomo> elmo: ping?
<CarlFK> mjg59 - if that patch is used, shouldnt ACPI_CUSTOM_DSDT_INITRD be in /boot/config-2.6.12-8-386 ?
<mjg59> CarlFK: No
<mjg59> It's not actually that patch, because we don't use initrds
<CarlFK> ah  - that explains why your instuctions didn't match the patch's
<mjg59> Kamion: Did you see my pointer to dmraid?
<Kamion> pitti: that module-init-tools change is fine except that I'd prefer it if you used something like 'type usplash_write >/dev/null 2>&1' instead of '[ -x /sbin/usplash_write ] ' to avoid the hardcoded path
<pitti> Kamion: ok, no problem
<Kamion> pitti: os-prober> not a bug I know about; I'd try running os-prober under 'sh -x'
<ajmitch> pitti: is there a replacement for libpgtcl?
<bddebian> Doh, you beat me to it. :-)
<Kamion> mjg59: either "no" or "I forgot where I put it"
<pitti> Kamion: I'm just at filing a bug for that, thanks for the hint
<pitti> Kamion: I need to reinstall though since calling it manually blocked my only available shell :-(
<Kamion> pitti: ctrl-c doesn't work?
<mjg59> Kamion: Ok. To support software SATA RAID stuff, we need dmraid
<Kamion> http://people.redhat.com/~heinzm/sw/dmraid/readme ?
<pitti> Kamion: nope
<mjg59> Kamion: Yup
<Kamion> er ... hmm
<CarlFK> mjg59 - hopfully last user Q: is this what you were telling me to do? https://wiki.ubuntu.com/ACPIBattery
<pitti> Kamion: I followup to the bug later, I need some biking while it is still sunny outside :-)
<pitti> cu later, guys
<dholbach> bye pitti
<Kamion> mjg59: is it possible to use that to basically hide the underlying devices and only show the assembled devices?
<Kamion> 'cos otherwise you get into the hard UI path through partman
<mjg59> Kamion: That's the idea, I believe
<mjg59> Kamion: Although based on what Aaron is saying, it looks like the installer may not be finding the SATA device at all
<pawdro> hello, which colony is actulally the latest?
<mjg59> pawdro: 4
<mjg59> Kamion: (#13506)
<Kamion> mjg59: I don't know of a reason that would happen; but that stuff is mostly the responsibility of hotplug these days, not of the installer itself
<mjg59> Kamion: Ok
<mjg59> Kamion: I've no idea what the right debugging steps are there
<Kamion> my inclination would be to boot the install CD with init=/bin/sh, 'nano /etc/hotplug/hotplug.functions', uncomment the DEBUG= line near the top, 'exec /sbin/init'
<Kamion> then look at /var/log/syslog after it fails
<mjg59> Kamion: Any chance you can stick that on the bug?
* mjg59 has to go out and grab some food
<Kamion> mjg59: done
<doko> elmo: please sync wxglade  0.3.5.cvs20050824-0.2 from unstable, throwing away the ubuntu changes
<spayne> has anyone seen the problem with ClearLooks where the corners aren't rounded off properly
<Riddell> elmo: pong
<ogra> spayne, you mean metacity  ?
<mdz> Kamion: only visible live CB
<mdz> Kamion: CD change really is usplash
<Keybuk> I thought that Human didn't have the Clearlooks corners
<ogra> mdz, dont you think ltsp-server should restart nfs-kernel-server in postrm too, after removing the line from exports ? 
<ogra> Keybuk, thats right
<ogra> Keybuk, but the clearlooks metacity theme is still installed... so you can use it... its just that rounded metaciy corners look like crap at low resolutions
<Riddell> Kamion: would it be possible to get a kubuntu colony CD?
<Kamion> mdz: ok, good
<Kamion> Riddell: I need to be getting test reports from you guys
<Riddell> Kamion: I've been testing the daily build from today and it's all good
<Riddell> (there's a long list of things to fix but good enough for a colony CD)
<Kamion> language-support-en is not installable on today's kubuntu daily
<Diziet> ubuntu-bugs is very high-traffic.  Is there a sensible way to pick things that need work other than just browsing subject lines and hoping to spot things you can fix ?
<Kamion> the Kubuntu daily CD was oversized and arbitrarily truncated; I can't release it like that
<Kamion> 35MB over on amd64, 29MB over on i386
<Kamion> I suspect removing some language packs will be the right answer
<Riddell> language-support-en installs OK here (from the internet)
<Kamion> if you want to trim things down by some appropriate amount, ping me afterwards and I'll do a rebuild for you
<Kamion> http://cdimage.ubuntu.com/kubuntu/daily/20050905/report.html
<mdz> ogra: yes, probably
<mdz> apparently ubuntu-desktop is uninstallable due to ubuntu-quickguide going away?
<ogra> mdz, i'll add it to my patch then...
<ogra> mdz, yup
<Kamion> I never do releases if some of (*-desktop, language-pack-*, language-support-*) are uninstallable from the CD
<mdz> ogra: you updated edubuntu-meta for this
<ogra> mdz, the binary was renamed
<mdz> but not ubuntu-meta?
<Kamion> mdz: #14709
<Kamion> it's not clear whether it was meant to disappear
<ogra> mdz, i talked to jbailey about it he wanted to care for it
<mdz> ah, the new doc upload dropped it
<mdz> jbailey: ?
<mdz> Kamion: how about upping the CD size limits as we discussed?
<Kamion> mdz: yeah, I'm going to - I would still consider oversizedness to be a release blocker though
<mdz> Kamion: for preview or final, yes; not necessarily for a milestone
<Kamion> depends how much it's oversized
<ogra> i still think 700MB media is common nowadays
<Kamion> and we need to keep things reasonable throughout the development cycle or else we get a nasty surprise come preview
<mvo> mdz: permission to upload http://paste.ubuntulinux.nl/1930? (patches are attached to the bugreport)
<mdz> mvo: ok
<Kamion> 700MB media may be common, but 650MB media is also common, and there is generally not a terribly visible difference in labelling, so you can very easily buy 650MB media without intending to
<spayne> ogra: yeh, metaity
<mdz> I was thinking the other day about the possibility of building the livefs through incremental upgrades rather than starting from scratch every time
<ogra> spayne, at what resolution ? it simply looks bad at small res.
<mdz> it would speed up the update cycle when we need  to make a change close to release
<ogra> spayne, thats was never different...
<spayne> ogra: 1280x1024
<spayne> ogra: it is now
<spayne> ogra: on hoary, it looked basically rounded but on breezy, you can see it looks square
<ogra> spayne, i always see stairstepping ... a bit less with 1600 pixels screenwidth
<spayne> ogra: look at this screenie - http://www.evolutioncolt.com/~spayne/shots/metacity-050905.png
<spayne> ogra: since the change in the theme colour, this has happened
<ogra> spayne, oh, i thought you mean the stairstepping in the rounded corner.... thats a bit different...
<ogra> but definately doesnt happen here
* ogra goes tryng on another pc
<ogra> spayne, it also doesnt happen on a newly installed daily
<spayne> why does it happen on three machines then?
<ogra> spayne, no idea, did you tweak the themes somehow... 
<dholbach> bbl
<spayne> ogra: not at all
<spayne> can you see in the Metacity bar
<spayne> that the corners are not round?
<ogra> yup, i see your screenie... but it doesnt happen on any machine here... and especially it doesnt happen on a new install from this morning, which is my reference...
<spayne> could it now be a graphics problem
<ogra> probably... i have no idea what might cause it... 
<ogra> are all your machines fresh installs? or are they upgraded older systems ? 
<spayne> one fresh from 30/09/05 Daily Build
<spayne> rest from Colony 3
<spayne> and another from Hoary
<spayne> also, how many clearlooks themes do you have? you said you had three before but jdub said there should only be one
<ogra> spayne, i have manual installed ones on my laptop... 
<spayne> oh right
<ogra> but removing them and reinstalling clearlooks didnt change it...
<spayne> which makes me think is it graphics problem
<spayne> ogra: who shall i speak to? who maintains clearlooks?
<ogra> i or jdub or seb128 are people who might touch it, but its definately not a problem of the package... the root cause must be soemwhere else
<pitti> hi
<seb128> spayne: what about it?
<seb128> hey hey pitti
<pitti> Hi seb128, got your net back?
<seb128> yep
<seb128> ready for a GNOME 2.12 upload semi-marathon
<seb128> semi, thanks to dholbach :)
<dholbach> seb128: de rien :)
<ogra> seb128, http://www.evolutioncolt.com/~spayne/shots/metacity-050905.png see the corners of spayne's metacity clearlooks theme
<mvo> hey seb128!
<ogra> seb128, any idea what could cause that ?
<spayne> seb128: the corners aren't being drawn properly on four machines
<seb128> hello mvo
<seb128> weird
<dholbach> see you later
<ogra> seb128, i cant reproduce it anywhere here
<spayne> i have it everyone
<spayne> one dist-upgrade from Hoary
<spayne> two installed from Colony 3
<spayne> and one from a daily build
<mvo> seb128: I added some l-p-i po-files, would you mind to have a look? (michael.vogt@ubuntu.com--2005/launchpad-integration--mvo--0)? should we install the po files into the liblaunchpad-integration0 package?
<seb128> mvo: by example, doesn't really matter since they will get stripped for language-packs :)
<seb128> mvo: I'll have a look, just let me catch with mails first
<spayne> seb128: any ideas?
<Kamion> mdz: done
<spayne> oh wait - doesn't happen on my iBook
<spayne> which is a upgrade from hoary
<seb128> spayne: no
<mdz> Kamion: how is the installer looking now?
<Kamion> mdz: anything else urgent you want me to look at, other than Kubuntu Colony 4? I've run off the end of my list of preview blockers
<seb128> spayne: is that a custom theme?
<Kamion> mdz: looks fine to me - I just did usplash integration today
<spayne> no standard Clearlooks
<seb128> it's supposed to have round corners?
<spayne> yes
<mvo> seb128: right, and no rush, I just wanted to tell you. now I leave to play a bit hockey :)
<Kamion> hmm, live CD shutdown is still hosed for me even when I try an explicit 'chvt 1'
<seb128> mvo: thanks, enjoy it :)
<mdz> Kamion: the only remaining preview blocker from my list is the gdm vt switching bug on the live CD
<Kamion> which bug is that?
<mdz> Kamion: yes, that
<Kamion> ok
<mdz> I am teh slow with this keyboard
<mdz> Kamion: I don't know that there is a bug open yet
<mdz> there ought to 
<mdz> be
<spayne> seb128: it happened on both machines which has fresh installs but not the dist-upgraded one
<tseng> mdz: alot of people have the alps issue.
<mjg59> mdz: So you don't want usplash on shutdown/reboot for Breezy?
<Kamion> I assume something is locking up the VT subsystem, since even 'chvt 1' doesn't help
<mdz> tseng: has daniels responded yet?
<tseng> mdz: no.
<mdz> tseng: it should be easy enough to back out the changes which introduced that regression
<tseng> mdz: but we get a few more every day in #ubuntu-laptop
* mvo is away for a bit
<mdz> tseng: I thought alps touchpads were much less common than plain synaptics
<tseng> mdz: they seem to be pretty common in dells (both of mine)
<mjg59> mdz: Alps are used on Dells
<Kamion> mdz: do you even know what it is that's locking?
<[SemTeX] >  /whois mdz
<ogra> heh
<Kamion> it's difficult to know where to start when I can't do anything to the machine after the bug
<[SemTeX] > doh ;)
<mdz> Kamion: no; this broke sometime between colony 2 and 3 I think
<Kamion> well, that narrows it down ;)
* Kamion -> dinner
<spayne> seb128: what do you suggest i do?
<mdz> fabbione: ping?
<mjg59> seb128: Hi - have you had a chance to look at the hibernate key shortcut thing?
<jbailey> Kamion, mdz: I hadn't noticed the dependancy before the bug was filed.  It's not one of the documents that the doc-team is producing for this release.  Should I resurrect the previous one, or drop the dependancy?  There's also now something called a 'quicktour'
<mdz> Kamion: I don't know what's causing it, only that it was broken before usplash
<mdz> Kamion: curious that it only seems to affect the live CD
<mdz> jbailey: which dependency?
<mdz> jbailey: if the document is obsolete, we should drop it, especially if the quicktour replaces it
<mdz> seb128: how much of 2.12 has landed so far?
<thrice`> anyone here work on fglrx ?
<seb128> mdz: 1/3, should be 80% within 2-3 hours from now
<spayne> seb128: what do you suggest i do?
<seb128> mjg59: nop, I've got like 350 bug mails during the 4 days I was away and the focus is GNOME 2.12 for now
<seb128> spayne: debug it, sorry but it works fine here and there is no other bug about it, and I'm not a theme hacker
<thrice`> the fglrx in breezy appears to be that of hoary; which, to my understanding, will not function on the 2.6.12 kernel
<desrt> damn people jumping the gun on releases :P
<thrice`> is this the right channel for that ?
<Kamion> jbailey: there's a quickguide in the source package?
<Kamion> jbailey: is it obsolete?
<desrt> thrice`; i wouldn't be suprised if it just hasn't been taken care of yet
<desrt> thrice`; ie: it's probably on the TODO list for later on in the release
<thrice`> desrt, i was browsing packages.ubuntu.com, and found it
<mjg59> seb128: Ok. Shall I send you a patch?
<thrice`> desrt, but, if people are updating to preview, X will crash for sure with the old drivers
<seb128> mjg59: bugzilla it please
<thrice`> s/crash/fail to start :
<desrt> thrice`; for me, it just fails to be 3d accelerated
<desrt> thrice`; the drivers detect the condition and handle it gracefully
<thrice`> desrt, but, ATI put out new drivers that will handle 2.6.12 perfectly
<desrt> thrice`; maybe mention it in #ubuntu-kernel, then?
<desrt> or RFE it on the bugzilla
<thrice`> desrt, in my experience, X (gdm even) wouldn't initialize
<thrice`> desrt, ok, I'm not sure where to bring this =] 
<desrt> the worst that can happen is that you get shut down :)
<desrt> thrice`; i imagine, BenC in context of linux-restricted-modules
<Kamion> mdz: can we have an "Ubuntu 5.10 preview" milestone in Bugzilla?
<ogra> mdz, and while youre at it, probably Edubuntu too.... ?
<pitti> Kamion: ok, I debugged the os-prober hang, mouting the OS X hfsplus partition causes a kernel oops
<desrt> thrice`; but as you know... there's the two halves... so probably have to talk to daniels too
<pitti> Kamion: so I will reassign and bother BenC 
<Kamion> pitti: I just reassigned
<Kamion> ogra: the previews are all coordinated
<thrice`> desrt, daniels ?
<desrt> pitti; more hal goodness for you this fine day :P
<Kamion> we only need one milestone
<desrt> thrice`; the ubuntu X guy
<thrice`> desrt, where would he be at ?
<ogra> Kamion, i mean generally a Edubuntu section in bugzilla...
<thrice`> oh, in here =] 
<Kamion> ogra: ah, right
<ivoks> thrice`: bugzilla :)
<pitti> desrt: we have severe problems with ACPI batteries
<desrt> pitti; please please please tell me about them
<pitti> desrt: however, I doubt that a new upstream version will be allowed...
<thrice`> ivoks, just post something on bugzilla.ubuntu.com ?
<desrt> pitti; i'm willing to fix anything that's reported
<pitti> desrt: daniels and jdub can both reproduce it
<desrt> pitti; jdub's problems are in the kernel, eh? :/
<pitti> desrt: oh, that's a great promise :-)
<seb128> hum, time for dinner, brb
<ogra> pitti, depends... if you get the battries to explode due to the bug it might be considered ;)
<tseng> ogra: haha
<ivoks> thrice`: if you think there is a bug, bugzilla is right place
<pitti> desrt: both guys are in .au and probably asleep, do you think you can catch them on IRC tomorrow?
<pitti> desrt: I would love to see hal fixed, otherwise we have to revert battery applet to reading /proc
<desrt> pitti; i've talked to jdub a lot about his problems
<pitti> desrt: restarting hald helped, but of course trashes your desktop sessions
<ogra> pitti, why cant it read the same data that g-p-m reads from hal ? 
<pitti> desrt: it seems that the polling didn't work for some reason
<desrt> see http://bugzilla.ubuntu.com/show_bug.cgi?id=13446
<pitti> ogra: it certainly does
<desrt> pitti; or was he having other problems?
<zyga> pitti: do you have a moment?
<pitti> desrt: yes, he didn't get any update
<pitti> desrt: the polling was broken somehow (same for daniels)
<ogra> pitti, it works in g-p-m
<jdahlin> jbailey: ping
<desrt> hal does poll..... (at least in theory)
<desrt> ogra; it's broken depending on laptops
<pitti> desrt: right, I know, but there seems to be a bug
<desrt> ogra; various laptops have various different levels of severely broken ACPI
<desrt> pitti; does richard know?
<ogra> desrt, i know... sorry for the noise
<thrice`> daniels, around ?
<desrt> thrice`; lives in .au -- probably sleeping
<pitti> desrt: I just got to know this this morning and didn't have time for that so far
<thrice`> desrt, aah...sorry =] 
<thrice`> i'll try bugzilla
<desrt> pitti; ok.  i'll talk to those guys when they wake up
<pitti> desrt: thanks a lot
<desrt> pitti; please cc: me on any bugs vaguely related to hald/acpi stuff
<pitti> desrt: I will
<desrt> thanks
<desrt> i really want to see breezy ship battstat using the hal backend
<pitti> me too
<desrt> (plus, we need to make sure hal works in order for g-p-m to not go insane, too)
<pitti> desrt: I already extracted many ACPI patches from 0.5.4
<desrt> ya... you've been doing a pretty good job of keeping ubuntu synced
<desrt> i cc:'d you another patch today
<pitti> desrt: have there been more fixes recently?
<desrt> it turns out that some ACPI implementations report 'current charge' to be vastly higher than 'full capacity'
<sabdfl> mdz: does ubuntu-desktop require xserver-xorg?
<desrt> pitti; pretty retarded stuff....
<Kamion> sabdfl: yes, indirectly
<mjg59> When the device is no longer charging, hal should just report it as 100%
<Kamion> (via x-window-system-core)
<sabdfl> doesn't seem to at the moment
<desrt> mjg59; no.
<desrt> mjg59; powerbooks for example, when you just plug them in, will only charge if < 95%
<desrt> also, it takes them a few moments to start charging
<Kamion> the dependencies seem right in the archive; ubuntu-desktop -> x-window-system-core -> xserver-xorg
<mjg59> desrt: Yes, but you basically don't care about that difference
<desrt> mjg59; well.... it'd be weird if you unplug your laptop and instantly drop from 100 to 95%
<desrt> and even more weird that when you plug your laptop in it goes 50% and discharging -> 100% steady -> 50% and charging
<mjg59> desrt: Well, I think there's a strong argument for not showing the percentage when it's not charging
<mjg59> Since there's absolutely nothing you can do about it
<mjg59> Just change "100%" to "Fully charged"
<desrt> mjg59; if my battery is 95% sometimes i unplug my laptop to let it drop down and then charge it up to 100% again
<pitti> desrt: I CC'ed you on #14050 and #14246, I can't handle them anyway
<desrt> mjg59; just for the extra 15 minutes it gives
<thrice`>  in bugzila, what would my source package name by called for fglrx stuff ?
<desrt> pitti; thanks
<pitti> desrt: would rock if you could debug this, it just works fine on my iBook (PMU)
<mjg59> thrice`: linux-restricted-modules
<desrt> mjg59; plus... the majority of laptops do work.... negatively impacting the UI for the sake of odd laptops (that we can otherwise fix in more sane ways) is never good
<desrt> pitti; PMU laptops always work properly :)
<pitti> hehe
<desrt> pitti; (powerbook g4 here)
* pitti loves his iBook
<mjg59> desrt: Mm? It's entirely valid for current capacity to be larger than last full capacity
<pitti> k, cu later
<desrt> mjg59; not by 204%
<thrice`> mjg59, thank you
<sabdfl> Kamion: blush. helps if i install ubuntu-desktop, dunnit
<desrt> mjg59; his charge goes 96 97 98 99 100 204
<mjg59> desrt: Not by that much, no
<desrt> so flattening 204 downto 100 is definitely the right thing to do
<desrt> and in the event that you slightly overcharge, then that should reasonably be flattened down to 100 too
<desrt> i don't think the user cares to know that their battery is at 102% as compared to their last charge
<mjg59> Yeah. Anything above above 100 should certainly go down to 100
<mjg59> Which is what the /proc/acpi code did, AFAIK
<desrt> yup
<desrt> there is a CLAMP( value, 0, 100 ) in there somewhere
<desrt> i just wrote a similar patch for HAL so that's being fixed for breezy
* desrt looks into martin's bugs
<jbailey> jdahlin: pong
<Nafallo> pitti: ping
<jbailey> Kamion: There's a quicktour in the sourcepackage.  I need to ask the doc folks (who all live on the opposite side of the world from me)
<Nafallo> morning \sh 
<jbailey> Kamion: But in svn it's different than the quickguide.  They didn't list the quickguide as one of the documents they were doing up for Breezy.
<jdahlin> jbailey: hey there, I understand kiko talked to you about the glibc monetary pt_BR bug fix?
<\sh> hey Nafallo thx for gajim :)
<jbailey> jdahlin: Yup!
<Nafallo> \sh: hehe, it's about time someone starts showing that MOTUIM is two people ;-)
<Nafallo> \sh: and I think I did actually :-P
<jbailey> Kamion: Oh, hmm, I did include it there, I didn't think I had included that directory in the copy from svn.
<\sh> Nafallo: yeah :)
<jdahlin> jbailey: I filed a bug upstream (not yet committed), http://sources.redhat.com/bugzilla/show_bug.cgi?id=1294
<jdahlin> jbailey: is that good enough or do you want me to file one in ubuntus bugzilla as well?
<Nafallo> pitti: (till you're back) do you know if I broke cryptsetup? ;-)
<jbailey> jdahlin: Cool.  Locales are a bitch to get into upstream.  Your best bet is to send it to the bellochs package in debian
<jdahlin> jbailey: Sigh, I could sense that from reading other bug reports
<jbailey> Mm, yeah.
<jdahlin> jbailey: do you have a policy against not adding patches on top of debians? do I need to get into debian before it can go into ubuntu?
<jbailey> jdahlin: Nothing that crazy.  I generally have to be quite confident that the report for locales is accurate.
<jbailey> The problem being that colation ordering can silently break scripts and whatnot that might be dependant on ordering.
<jbailey> So I usually try to find a few sources to verify.
<jdahlin> jbailey: understandable. In this case I found some references to brazilian laws which says how currencies should be written
<jbailey> Those are helpful.
<jbailey> =)
<jdahlin> :-)
* Mithrandir tickles Nafallo
<Nafallo> Mithrandir: hi Tollef :-)
<Nafallo> Mithrandir: you don't happens to run an encrypted LUKS system somewhere? :-P
<jbailey> jdahlin: It's helpful if you could list it in Ubuntu's bugzilla too.  I work off of that as my master list of bugs to care about.
<Mithrandir> Nafallo: no, but I have the spec on my hard drive, so I'll hopefully find the time to fix mount properly in a while.
<jbailey> And occasionally I misplace the little slips of paper that I otherwise write for myself.
<jbailey> =)
<Mithrandir> Nafallo: how so?
<jdahlin> jbailey: sure, I'll file a bug referencing to the other
<ajmitch> jbailey: morning :)
<jbailey> jdahlin: Thanks.
<Nafallo> Mithrandir: I've LSB-ised the init.d, so it should run in usplash. but I believe that script asks for passphrase and such :-P.
<Nafallo> Mithrandir: I've never seen something like that in usplash yet ;-)
<jbailey> ajmitch: g'm.  This is early for you, what's the occasion? =)
<ajmitch> jbailey: s/early/late/
<jbailey> ajmitch: You're still up?
<ajmitch> more or less
<ajmitch> got a few hours sleep earlier in the evening
<ajmitch> been MOTUing for a little while since
<desrt> pitti; if your two bugs, i fixed one this morning and we have a good handle on the second one
<desrt> s/if/of/
<jdahlin> jbailey: filed as bug 14750
<jbailey> jdahlin: Thanks!  I'll try to get that shortly after preview.
<Mithrandir> Nafallo: uhm, yeah, that probably breaks usplash
<Nafallo> Mithrandir: I think it's okey if usplash bails out, but I'm not sure it will do that? ;-)
<Nafallo> Mithrandir: if it does bail out there is a timeout where the user do not know why everything stopped :-P
<Mithrandir> Nafallo: yeah, but cryptroot is so special, at least for now.
<Kamion> sabdfl: ah, yes :)
<Kamion> jbailey: ok
<ogra> Kamion, can we add some default values to the network config of edubuntu ? 
<mdz> Kamion: I've no objection to another milestone, but I don't find them very useful
<mdz> ogra: why would edubuntu be a milestone?
<ogra> mdz, nope ... i hope i'm ready for preview with a valuable preview release...
<mdz> <Kamion> mdz: can we have an "Ubuntu 5.10 preview" milestone in Bugzilla?
<mdz> * mae (n=mae@dpc674653178.direcpc.com) has joined #ubuntu-devel
<mdz> <ogra> mdz, and while youre at it, probably Edubuntu too.... ?
<mdz> ogra: ^^
<ogra> mdz, <ogra> Kamion, i mean generally a Edubuntu section in bugzilla...
<mdz> ogra: you mean a keyword?
<mdz> ogra: you mean a keyword?
<ogra> mdz, yup
<desrt> seb128; poke
<seb128> desrt: pong
<desrt> seb128; if i send you gnome-applets-2.12.0.tar.gz could you test it out and make sure it's ok?
<desrt> it's my first major release and i want to make sure it doesn't suck before tagging it off in cvs
<seb128> k
<desrt> k.  uploading
<seb128> pitti: around?
<\sh> seb128: popups are making my desktop jump around 
<seb128> window manager crashers
<seb128> known and fixed upstream
<desrt> 6bb3b187cb3ffc7d628c2f07a34330af  http://manic.desrt.ca/gnome-applets-2.12.0.tar.gz
<\sh> looks like
<desrt> seb128; 14:29 <pitti> k, cu later
<desrt> seb128; that's 90mins ago
<seb128> desrt: thanks
<desrt> seb128; and thanks for testing :)
<seb128> np
<marcin_ant> hi developers - no one on #ubuntu knows so - sorry but I'll try here
<marcin_ant> question is - are ati fglrx drivers installable and workable on ubuntu breezy?
<desrt> no.
<desrt> the kernel half and the xorg half are out of sync
<marcin_ant> desrt, ok - thanks
<carlos> pitti, hi, around?
<desrt> carlos; no :P
<carlos> desrt, :-(
<desrt> seb128; btw... you are legally obliged to start making blog posts
<seb128> I'm on planet gnome now?
<desrt> ya
<desrt> i made you a hacker head and everything
<seb128> bah
<desrt> http://planet.gnome.org/heads/seb128.png
<desrt> look... it's you :p
<\sh> seb128: wow such a nice face..and he's working on gnome *lol*
<seb128> desrt: yeah, it's me :)
<seb128> ah ah
* desrt watches \sh become seb's groupie
<ogra> desrt, lol
<pitti> seb128, carlos: pong
<\sh> desrt: hehehe ,-)
<ogra> desrt, \sh is our KDE MOTU ;)
<pitti> Nafallo: pong
<\sh> desrt: I'm one of the kde dudes ,-)
<Nafallo> pitti: hi! you saw the other message aswell? :-)
<desrt> oh.  i see.
<pitti> Nafallo: I didn't test it since your upload
<seb128> pitti: you uploaded the gnome-panel changes?
<desrt> maybe sebastien's good looks with persuade you to change teams and work on the gnome side of things
<Nafallo> pitti: oh! you're running the interactive cryptostuff? :-)
<desrt> will, that is
<Nafallo> pitti: you know who to assign the bugs anyway ;-)
<pitti> seb128: erm, no?
<carlos> pitti, nothing, I wanted a way to get a language pack to compare with, but I got it from the ubuntu's archive
<pitti> carlos: yes, the obvious way :)
<pitti> carlos: you can also get the daily generated archive
<carlos> pitti, URL?
<pitti> carlos: http://people.ubuntu.com/~pitti/langpacks/breezy-current.zip
<seb128> pitti: somebody uploaded sivang's lpi patch ... do you know who?
<carlos> pitti, thank you
<pitti> carlos: it's not that current any more since I still need to sort out the changed import with lamont
<pitti> seb128: ah, that one; yes, that was me
<pitti> seb128: but that was over a week ago, I thought you meant something recent
<carlos> pitti, don't worry, I just want to be able to get a diff with the language pack from Rosetta
<seb128> pitti: why the heck you guys have put a 14_autoconf after the 12_autotools ?
<carlos> so that's good enough
<seb128> pitti: i had some days of VAC and just spend some days catching up with mails/bugs ... now I catch up with packages for 2.12 :)
<pitti> seb128: uh, that looks broken; sorry, that didn't spring into my eyes (I just saw the debdiff and assumed that he changed the right patch)
<pitti> seb128: shall I fix it?
<seb128> pitti: the package has some changes, a 12_autotools then 13_lpi then 14_autoconf
<seb128> pitti: no, that's fine, I'm doing 2.12 upload ... it doesn't hurt, I was just curious to know if there is a reason for it
<pitti> seb128: nope, I just looked at the debdiff :-/
<seb128> don't worry, that's fine
<seb128> the package build with both patches
<seb128> it's just weird :p
<pitti> yes :-)
<pitti> lamont-away: ping
<seb128> desrt: tarball works fine
<desrt> :D
<desrt> seb128; can you please upload it for me?
<seb128> sure
<desrt> seb128; does the machinary on the ftp server build all the .news/.changes/etc stuff automagically?
<seb128> yep
<desrt> nice
* desrt tags off and goes for dinner
<desrt> seb128; thanks again
<WaterSevenUb> mvo, what does it mean in synaptic, Preferences, Package upgrade behavior, the parentesis (default distribution) . What is this? Default distribution?
<seb128> desrt: you're welcome
<mvo> WaterSevenUb: you can have more than one distribution in your sources.list (e.g. hoary and breezy at the same time). this option let you choose which one should be picked by default for upgrades etc
<WaterSevenUb> mvo, thx. Still don't understand. "Package upgrade behavior (default distribution)". If one had only "Package upgrade behavior" wouldn't that make more sense?
<\sh> doko: ping
<doko> pong
<\sh> doko: libmagick++6 cxx transition...
<\sh> I only find 6:6.0.6.2-2.1ubuntu1.1 in the archives
<\sh> but regarding cxxlibrarylist we shoud have  6:6.0.6.2-2.3ubuntu1
<mvo> WaterSevenUb: the "default distribution" is in there to make it easier for people who already know apt (the config option in it has that name)
<\sh> doko: or did I miss something? :)
<WaterSevenUb> mvo, so it should be left in english that parentesis..... ?
<doko> well, it's transitioned, but not in sync. is something wrong with the current package?
<mvo> WaterSevenUb: yes, that sounds reasonable to me
<\sh> doko: I'm working on bddebians unmet dep list..and found this
<papyrus2> Hi
<papyrus2> sorry to bother you
<papyrus2> I have compiled my own alsa driver
<\sh> doko: let me see if it compiles ;)
<papyrus2> because I have an intel 915chipset
<crimsun> papyrus2: this is not the proper channel for support
<papyrus2> crimsun : know just want to have last news
<\sh> papyrus2: i915 is working in breezy out of the box 
<\sh> papyrus2: my r200 has this chipset as well..and it's working
<papyrus2> sh : arf I have to wait breezy :(
<papyrus2> sh : the module launchs fine
<ogra> papyrus2, just 4 weeks
<ogra> err 5
<papyrus2> sh : but no sound 
<\sh> papyrus2: what do u  expect for a new intel chipset
<papyrus2> sh : it's not my laptop 
<crimsun> the problem is that if you compile 1.0.10rc1 from upstream, you end up clobbering what Ubuntu has configured. The incorrect state file is loaded and saved. The lib definitions aren't synced. But hey, we give people enough rope to hang themselves, no?
<papyrus2> sh : I do it for a friend
<\sh> papyrus2: try breezy colony cd 4 the live cd
<\sh> and check it out
<papyrus2> arf ok
<papyrus2> I will do that so
<papyrus2> because some hoary user have this problem
<Nafallo> papyrus2: let him take a walk on the wild side then ;-)
<papyrus2> module are ok , mixer are ok but not sound :(
<Nafallo> my girlfriend switches to breezy this weekend :-)
<papyrus2> http://ubuntuforums.org/showthread.php?t=22696&highlight=Intel+915g
<papyrus2> and no problem ?
<Nafallo> nope
<papyrus2> with the upgrade ?
<Nafallo> no problem anywhere
<papyrus2> ok
<papyrus2> I will do it so ;-)
<Nafallo> hehe
<\sh> papyrus2: check first with the latest live cd
<papyrus2> ok
<papyrus2> I gonna try ;-)
<papyrus2> thanks for the tips
<papyrus2> and sorry for the inconvenience
<papyrus2> I know I'm on *-devel ;-)
* ogra wonders if seb128 and bddebian have a contest on -changes
* Lathiat laughs
<Nafallo> gnome vs. universe ;-)
<\sh> ogra: it's me who is uploading ,-)
<\sh> sweating ,-)
<ogra> \sh, but your name doesnt appear ;)
<Lathiat> so it doesnt count, hah :)
<papyrus2> I will come back for breezy's news
<Lathiat> man ipac-ng is ugly
<Lathiat> theres a patch to make it work
<Lathiat> btu it breaks working with older iptables
<\sh> ogra: but I have to test it all ,-)
<Lathiat> but right not its useless with a default install.. so i guess workign with breezy packages is better 
<rtcm> network-manager isn't really working is it? is there anyone puting some love into it? :-)
<ogra> \sh, nope, thats something bddebian should already have done :)
<Lathiat> If a package needs a new version from debian & a patch applied, should i just grab the debian version and apply it or should it be synced first then sourced and patched?
<\sh> ogra: I double check :) one build-dep he missed..and this is where my name appears ,-)
<ogra> ah
<\sh> and I hate native packages
<ogra> \sh, i love them :p (if i'm upstream ;) )
<Burgundavia> ogra, so no hope of g-p-m 0.2.1, eh?
<ogra> Burgundavia, its in universe... why not... if i find the time
<Burgundavia> ogra, where there changes from HAL 0.5.3 and 0.5.4?
<mvo> seb128: hey! did you had a chance to look at my launchpad-integration branch? can I ask for approval tomorrow morning?
<\sh> ok...last package of only rebuilds
<ogra> Burgundavia, yup...
<seb128> mvo: nop, I'm catching if with GNOME 2.12 atm, will look before sleeping though
<Burgundavia> ogra, hmm, that might scupper gpm. We only have .3 and it needs .4
<ogra> Burgundavia, we have patches from .4
<Burgundavia> ogra, ah, ok
<ogra> especially for acpi... even if they might not be enough yet
<hughsie> ogra: 0.5.3 -> 0.5.4 hal changes are pretty massive
<hughsie> ogra: lots of new stuff to audit
<ogra> hughsie, i know.... pitti is crying for 0.5.4
<Burgundavia> hughsie, that is what I had feared
<hughsie> ogra: 0.5.4 does rock btw
<ogra> hughsie, but a lot of fixes as well :=
<pitti> ogra: well, I backported all acpi fixes already, but there are more bug fixes; but I don't actually cry for it
<hughsie> but then cvs rocks harder
<ogra> :)
<pitti> ogra: it's time for backporting now, not new upstream versions
<hughsie> pitti: what about the methos stuff?
<ogra> pitti, yup
<pitti> hughsie: methos?
<hughsie> *method, sorry
<pitti> hughsie: no idea what you mean
<hughsie> PowerManagement.Suspend and hibernate
<hughsie> hal-system-power-hibernate and the such
<ogra> hughsie, mjg59 adjusted g-p-m for ubuntu
<hughsie> ogra: i know, it's no problem
<ogra> wrt current methods
<pitti> hughsie: we must stabilize now, no time for breaking new stuff
<hughsie> pitti, n/p, i'll keep churning out the new releases :-)
<pitti> hughsie: we import the hal cvs into an arch branch, so I have something sane to pull from :-)
<hughsie> putti, okay.
<ogra> hughsie, in 6 weeks we are allowed to play with new toys again ;)
<hughsie> ogra: roll on new toys :-)
<hughsie> ogra: the new (cvs) LCD stuff is pretty sweet
<Burgundavia> hughsie, are we looking at g-p-m by default for Gnome 2.14? (are you going to propose it?)
<pitti> hughsie: I look forward to see proper luks integration, too (the current breezy support for LUKS devices is pretty hackish)
<hughsie> pitti: LUKS is *sweet*
<hughsie> Burgundavia: not sure. don;t see why not.
<pitti> hughsie: I know, in Breezy I h4ck3d g-v-m to support it without hal
<hughsie> pitti: that's a-morale. :-)
<pitti> hughsie: hey, I *wanted* it in Breezy :-)
<hughsie> pitti: heh :-)
<hughsie> Anyone going to LinuxWorld in London? I'll be there.
<hughsie> Burgundavia: who would propose g-p-m for gnome? doesn;t it have to be someone high up?
<Burgundavia> hughsie, hmm, no idea. Best to talk to seb128 and jdub about that sort of thng
<hughsie> Burgundavia: okay, will do
<ogra> hughsie, the chances are good if jdub uses g-p-m on his breezy laptop ;)
<seb128> hughsie: upstream does
<hughsie> ogra: does he ?
<ogra> hughsie, dunno, but its there, so he might, i havent asked him
<hughsie> seb128: what say you: is g-p-m wanted in core?
<hughsie> seb128: or are the hal and dbus deps too agressive
* ogra guesses we will see more agressive deps on them in the future
<hughsie> ogra: hughsie hopes dbus 1.0 will be released soon :-)
<ogra> heh
* ogra hopes dbus 1.0 will be released in time to enter a ubuntu release easily
<hughsie> ogra: here's wishing :-)
<seb128> hughsie: read the desktop list for example for other components
<Burgundavia> hughsie, you might want to also push the gnome-screensaver person into proposing it as well
* Burgundavia suspects that g-s is already being thought of
<ogra> seb128, not the ubuntu desktop list though :p
<hughsie> Burgundavia: year, g-p-m relies on g-s to do the screen locking
<hughsie> seb128: yes, will do. Upstream is happy for inclusion bbtw. :-)
<ogra> Burgundavia, both will be in breezy+1 in main
<hughsie> ogra: what is breezy+1?
<Burgundavia> ogra, I figured as much
<ogra> hughsie, the new release cycle that starts in 6 weeks....
<hughsie> ogra: year, but what name?
<hughsie> anyone decided yet?
<\sh> breezy+1 ,-)
<hughsie> \sh: thanks...
<ogra> secret :)
<hughsie> secret, that rubbish. all the others ended in "y"
<hughsie> secrety makes more sense
<ogra> i didnt hear anything official yet so i'll shut up about that topic
<\sh> hmmm....
<\sh> \shY ,->
<\sh> ogray ?
<hughsie> hughsay?
<hughsie> ogray has a ring
<hughsie> if you pardon the expression
<Nafallo> ogray ogre :-)
<ogra> hughsay hacker ? \shy shark ?
<tseng> shy shark would be elite
<ogra> hehe
<Nafallo> :-)
<\sh> tststs
<\sh> shy shark
* Nafallo wants perky penguin ;-)
<\sh> sounds like a paradoxon
<HrdwrBoB> randy rhino
<ogra> but i doubt our marketing dept. likes shark in the name :)
<tseng> perky pengiun, the return of the pr0n release
<Nafallo> tseng: LOL
<Mithrandir> ogra: we have a marketing department?
<ogra> Mithrandir, well, we have silbs
<ogra> itsnt that one... ?
<Lathiat> tseng: haha
<Mithrandir> ogra: she's not big enough that you can call her a department all alone
<desrt> hughsie; word!
<hughsie> desrt: any word?
<ogra> Mithrandir, at least she has the impact of a whole dept :)
<desrt> hughsie; did you get my email or are the mailinglist monsters holding it?
<hughsie> desrt: which email?
<desrt> i see the mailing list monsters are still holding it :)
<desrt> i sent it to the hal list
<\sh> what about Ubuntu Inkululeko
<desrt> i cc'd martin so he's probably taking care of it... but it obviously needs to go upstream too
<hughsie> desrt: nothing yet, hal normally takes a few hours tho
<desrt> fwiw, i attached a copy of the patch to http://bugzilla.ubuntu.com/show_bug.cgi?id=14246
<hughsie> desrt: okay, thanks
<Nafallo> \sh: I can't spell that ;-)
<desrt> i'll fwd the email to you since it contains justification
<desrt> what's your address?
<pitti> desrt: just saw your mail on the hal list
<desrt> pitti; i cc:'d you directly so you don't have to wait for it to clear the list :P
<\sh> Ubuntu Inkululeko Inkemba ,-) Humanity Freedom Sword in Zulu
<pitti> desrt: oh, it might also be my personal copy, I can't tell :)
<hughsie> desrt: since freedesktop went screwy hal takes *forever* to update
<desrt> pitti; are you on hal list?
<pitti> desrt: oh, I can tell, it is :-)
<pitti> desrt: sure
<desrt> pitti; ah.  i'll keep that in mind for the future
<pitti> desrt: in any way, I won't apply it for the preview
<pitti> desrt: but directly after it
<desrt> pitti; that's absolutely reasonable
<\sh> Nafallo: http://isizulu.net/ <- zulu <-> english <-> zulu :)
<desrt> pitti; the other bug is a kernelism
<desrt> pitti; the kernel is reporting the battery as 'discharging' when it's not
<pitti> yes, I saw the bug followup; thanks for triaging
<desrt> np.
<desrt> we might want to deal with it in hal, though :/
<desrt> since i don't know how comfortable ben is about hacking kernel acpi code
<hughsie> desrt: can you correct for the discharging-when-not case?
* Nafallo hides from \sh
<Nafallo> \sh: you're scaring me ;-)
<desrt> hughsie; that's what i'm presently contemplating :P
<hughsie> desrt: why the change from _mwh o _normalised?
<desrt> hughsie; that was in the email.  it's not always mwh.
<desrt> in the event that we have mAh systems, it's actually Wh
<\sh> and ogras shark name: we change it to Ubuntu Jikile Ushaka -> Ubuntu Gone Crazy ,-)
<desrt> and in the event that we have mAh systems without known voltage then it's mAh
<hughsie> desrt: whats wrong with just converting to mWh?
<hughsie> i.e * 1000?
<desrt> hughsie; / 1000, actually
<desrt> hughsie; and we can't always do it
<desrt> plus... there's no sense in discarding precision just for the sake of doing so
<desrt> the normalised values were never meant to be mwh or any other specific unit.... just a single unit that was uniform across the entire machine
<hughsie> desrt: okay, just reviewing patch now
<desrt> nod.  thanks
<hughsie> desrt: looks good to me - is it worth renaming int voltage; to int present_voltage; while you are there?
<hughsie> desrt: i'll ack that :-)
<desrt> hughsie; i had called it present_voltage and you renamed it back to voltage yourself :P
<desrt> in my previous patch :P
<hughsie> desrt: ahhh, but i cahnged the function.
<desrt> http://bugzilla.gnome.org/show_bug.cgi?id=314182#c6
<desrt> i think your logic at the time still applies
<hughsie> desrt: i was using it then as the generic voltage - you've shown you need to keep then seporate.
<desrt> design voltage will always be the design voltage
<desrt> 'voltage' could be either
<desrt> as per:
<desrt> +		if (voltage <= 0 || voltage > design_voltage)
<desrt> +			voltage = design_voltage;
<hughsie> but in your patch voltage is just battery.voltage.current, so should be voltage_current curely?
<desrt> voltage starts out as battery.voltage.current ... but might change
<desrt> same as how it used to be
<hughsie> desrt: heh
<hughsie> okay, i'll ack that. :-)
<desrt> as soon as you get the email :P
* desrt waits for daniels to wake up
<hughsie> desrt: whats the status of the hal-backend for battstat-monitor?
<desrt> hughsie; i just uploaded/tagged-off gnome-applets 2.12.0
<desrt> hal backend is enabled per default
<hughsie> desrt: thats good.
<desrt> nod
<hughsie> desrt: i was keep for that to happen, but i thin kdavyd has his worries
<desrt> ya... he believes in hal, though
<desrt> i think everyone has worries... and they're warranted
<desrt> but we're not going to find the million corner cases out there until we throw hal into wide public use
<desrt> and we have to do it eventually..... so i want to do it
<hughsie> desrt: i can't believe that a) battstat hasn't more bugzillas (with the state of the raw acpi stuff) and b) windows xp compes with all the buggy bios's
<desrt> hughsie; windows xp doesn't cope with the buggy bioses
<desrt> hughsie; the buggy bioses cope with win xp
<desrt> they boot their laptops up, install windows xp and check if everything works
<hughsie> desrt: heh
<desrt> if it works, they ship it
<desrt> no testing for linux
<sjoerd> daniels: why is dbus moving from S20 to S12 on ubuntu ?
<hughsie> desrt: why do I believe you
<desrt> hughsie; because it's probably true for 90% of vendors?
#ubuntu-devel 2005-09-11
<hughsie> desrt: it's unbelievable, really. ACPI was meant to put an end to all this hackyness
<desrt> ya.  kinda funny that apm actually works better, eh? :)
<hughsie> desrt: but apm doesn;t do half the stuff :-)
<desrt> but at least it bloody well does half of the stuff _properly_ :P
<hughsie> mental note, must test cvs g-p-m with apm again
<Burgundavia> hughsie, do you need people with old laptops to help test that?
<desrt> anyway... we're probably gonna get a lot of people screaming at us in the next few months
<pitti> good night 
<desrt> but things have been flowing fairly well between the two of us and the ubuntu guys so i think that after that we'll probably have most of it fixed up
<hughsie> Burgundavia: yes!
<desrt> night martin
<hughsie> desrt: bring it on :-)
<desrt> hah
* desrt doesn't temp fate unnecessarily :)
<desrt> *tempt
<hughsie> desrt: heh
* mvo goes to bed
<\sh> night mvo :)
<hughsie> desrt: night - thanks for the patch
<desrt> hughsie; thanks for the prompt review.  cheers mate.
<hughsie> :-)
<javi> hi, people, I'm having trouble with xrgb and xutils packages on breezy, /usr/bin/showrgb conflict
<javi> on aptitude says me to remove xbase-clients , but gdm depends on xbase-clients, so I can't remove it
<javi> nobody can help me ?
<carstenh> javi: this is the wrong channel, try #ubuntu
<ogra> javi, thats an #ubuntu question 
<javi> oh sorry, before ubuntu chanel wasn't on my channel list, I'll ask there now, thank you
<ogra> :)
<lamont> pitti: I was told you were importing directly from the buildd's....
<infinity> lamont : s/were/were going to be/
<infinity> lamont : I think he still had some code to sort out to do that.
<lamont> File: chroot-breezy/build/buildd/coreutils_5.2.1-2ubuntu2_powerpc_translations.tar.gz
* lamont bitchslaps infinity
<lamont> File: rhythmbox_0.8.8cvs20050710-0ubuntu1_translations.tar.gz
<lamont> see the difference?
<lamont> wanna send me a patch for sbuild?
<lamont> (File: in translations.txt is the $CWD relative location of the file...)
<lamont> infinity: once that's done, I'll push the new sbuild, fix the existing files, and turn the script on rookery back on
<jdub> GOOD MORNING FREEDOM LOVERS!
<ogra> good morning jdub
<seb128> mdz: ~90% of GNOME 2.12.0 uploaded. There will probably be 4-5 uploads tomorrow morning and then we are ok
<tseng> yay, jdub 
<seb128> 'night jdub, it's just time to sleep here :p
<ogra> seb128, awesome
<jdub> seb128: woohoo! :)
<Nafallo> morning jdub :-)
* jdub is sitting in the ozlabs office in canberra
<Nafallo> seb128: wow! :-)
<seb128> anyway time to sleep for now, see you tomorrow guys, 'night
<jbailey> I really want coreutils' sort to grow a "sort --dpkg" and have it use dpkg --compare-versions for sorting.
<ogra> cool idea !
<jbailey> ogra: Yeah, except that I do this stuff all in shell so that initramfs-tools doesn't depend on a newer glibc ever.  So I couldn't use it here anyway.
<jbailey> But it's tempting to convince the coreutils maintainers that it would be worth having.
<ogra> yup
<jbailey> That way in 4 or 5 years I could use it and feel okay about it. =)
<ogra> :)
<jbailey> Ah, well, it's only 15 lines of shell to do it by hand.
<infinity> lamont : Ahh, didn't notice that ${translations} was a full path.  Feh.
<lamont> yeah - that's the source of the borkage
<lamont> anyway, I'll check back in a bit and merge your patch and push...
<infinity> lamont : Have you branch/swap the archives yet?
<infinity> lamont : lamont.jones\@canonical.com--2005-master?
<infinity> lamont : Committed to -master
<infinity> lamont : Ergh, sec.  neuro had a custom basename function in here.
* infinity checks to see what that does.
<infinity> Oh, exactly the same thing as File::Basename.  Yay.
<infinity> lamont : Okay, that should be good to go.
<daniels> sjoerd: because we start gdm at S13, so we have to start the session bus before that
<daniels> Kamion: libdps1> it's orphaned upstream, it won't be shipping with 6.9/7.0.  it didn't actually *work* anyway, in the sense that there was no freely-licensed server implementation anywhere in the world.
<elmo> daniels: libxp is obsolete, right?
<elmo>  o x11proto-panoramix: x11proto-panoramix-dev
<elmo>  o x11proto-xf86dri: x11proto-xf86dri-dev
<elmo> daniels: and do they need to be in main?
<ogra> elmo, libxp is needed by blackdown java
<elmo> ogra: I don't care - I'm talking about main vs. not
<ogra> elmo, as long as youre not talking about morgue ... :)
<daniels> elmo: xp> yes, panoramix> no, remove from archive, xf86dri> yes
<desrt> daniels; can you set me up for write access to the hal cvs on gabe?
<elmo> daniels: c) can you arrange for xf86dri to be seeded then, pls?, b) reason, or just "obsolete"?, a) ok.  d) what about libxfont*? need to be in main still?
<daniels> desrt: please file a bug on bugs.fd.o, product freedesktop.org, component account modifications, and get davidz to put a note in there saying he approves
<desrt> daniels; interesting process.  will do.
<daniels> elmo: c) sure, b) -panoramix- turned into -xinerama- upstream, so just a rename, d) yeah
<daniels> desrt: well, it beats the 'ask daniels on IRC while he's eating breakfast' process, which usually leads to things being forgotten
<desrt> daniels; point taken :)
<elmo> daniels: d) see c) ;-)
<elmo> b) done
<\sh> listing to trance and reading daniels+elmo == smoking some weed ,-)
<\sh> but it works...wow
<lamont> infinity: cool
<lamont> infinity: and yes, that's the master
<daniels> elmo: heh, sure.  just need to update the seeds in arch?
<elmo> daniels: that'll do for a start; I think you're meant to file a maininclusionreport thing too these days
<elmo> but even having them in the seeds would help disambiguate it from the cruft
<lamont> infinity: btw, -ubuntu27 never released yet... fixed.
<daniels> elmo: oh, okay
<infinity> lamont : Ahh, yeah, I suppose that header should be a giveaway. :)
<daniels> elmo: i doubt i'll need a MIR, since it's all really just moving, but yeah
<lamont> bad part is that I already tagged -28, so we'll just skip 27
<daniels> mdz: x11proto-xinerama-dev is a rename from -panoramix-, and libxfont is simply moved over from the monolith.  do I need to file an MIR for each, or can I just seed it?
<infinity> lamont : Somehow, I doubt anyone will really care. :)
<lamont> heh
<lamont> infinity: you feel like dealing with stopping all the buildd's, apt-get install sbuild buildd; and restart?
<lamont> or shall I?
* lamont is trying to spend family time, you se...
<lamont> see, even
<lamont> actually... update-chroots should be running now...
* lamont fixors
<\sh> hmm...I should work during the night...more people are awake ;)
<infinity> lamont : You're on it, then, or doe sthat request still stand?
<lamont> done
<lamont> well, 8 done, 4 with some serious typeahead action.,..
<lamont> pls check on royal, king, terranova, hooker sometime in a bit.,..
<lamont> actually, it's just one longish command
<infinity> Alright, I'll poke at them and make sure they're happy.
<lamont> sigh... terranova, weddell, ross, king.
<lamont> must learn to be precise... :-(
<lamont> and the magic to clean the translation filenames is queued.
<lamont> I'll turn the script back on after backdating things later tonight or first thing in the morning
<lamont> king is done
* lamont wanders for a coupl ehours
* \sh goes to bed just now
<jay> If anybody here has a centrino, please cat your /proc/cpuinfo to me in /msg.  Trying to fix a bug in cpufreq-detect.sh but don't have a cent. laptop myself.
<infinity> lamont : Later.  Thanks for the manual hoary-cat action.
* infinity stares at elmo.
<Burgundavia> jay, the best place to look for that is https://wiki.ubuntu.com/LaptopTestingTeam
<slomo> elmo: ping?
<jay> Burgundavia: good idea :P  thanks
<Burgundavia> jay, np
<slomo> jbailey: ping?
<bddebian> elmo: pingeage
<slomo> infinity: what happenend to the gstreamer-plugins-multiverse0.8 upload some minutes ago? ;)
<\sh> ok...good night gentlemen
<infinity> slomo : a) How many "minutes ago", b) was it a new source package?
<infinity> slomo : c) Did you mean s/gstreamer/gst/?
<ajmitch> infinity: I also lost quake2, uploaded a few hours ago
<infinity> ajmitch : 1:0.3-1.1ubuntu1?
<Nafallo> infinity: a) somewhere around 3, b) new upstream version, c) yes, d) I was the uploader :-).
<ajmitch> infinity: yes, I don't see build logs for it
<Nafallo> ehm... s/3/1\ UTC/
<infinity> ajmitch : Looks held up on a (bogus?) dep-wait.  I'll clear it for you and see what happens.
<ajmitch> infinity: alright, thanks
<infinity> Nafallo : As for gst-plugins-multiverse, it doesn't look like it was ever ACCEPTED, so you don't want me, you want elmo (or you want to comb your inbox for a REJECTED message, telling you why)
<Nafallo> infinity: slomo didn't get a mail before he went to bed, I'll tell him to check tomorrow then :-)
<Nafallo> infinity: thanx anyway :-)
<bddebian> Hmm, how about wiliki (other than i386), and spiralsynthmodular?
<infinity> Nafallo : He'll only get one if he's whitelisted in katie.
<Nafallo> infinity: I know. He is.
<infinity> Nafallo : At a guess, if it's a new upstream, I'd bet it wasn't built with -sa, and the .orig.tar.gz wasn't included in the .changes.
<infinity> Nafallo : Either that, or it wasn't properly signed.  Pick one.  Those are the two most common.
<Nafallo> infinity: -S -sa -knafallo@magicalforest.se
<Nafallo> so I pick neither ;-)
<ajmitch> infinity: how soon after an upload is the queue cleared, and a package with an .orig.tar.gz can be uploaded?
<infinity> ajmitch : You should be able to bang uploads up as fast as you want, modulo bugs in the queue handling.
<ajmitch> alright
<infinity> ajmitch : Unlike the Debian queue, ours treats each upload set atomically and (is supposed to) process them as a FIFO.
<mpt> fabbione: ping
<infinity> ajmitch : So, in theory, you should be able to upload the same source 4 times in a cycle, get 3 REJECTs and an ACCEPT when queue/unchecked is processed.  In theory.
<ajmitch> good, because I missed -sa on a NEW upload of avahi first time round :)
<infinity> ajmitch : But, if stuff seems to mysteriously disappear, reuploading a little later never killed anyone. :)
<bddebian> ajmitch: How do you check the queue?
<ajmitch> bddebian: blind guessing
<bddebian> ajmitch: Because a bunch of stuff \sh did, don't seem to be building??
<ajmitch> bddebian: ask infinity, not me
<Nafallo> infinity: you can't see that package now right? should I rebuild the changes and reupload?
<bddebian> infinity: Anything wrong with sffview?
<infinity> Nafallo : It you're positive it had nothing that would get it caught up in NEW, and it's more than an hour old, then it probably got REJECTED.  I don't see it in wanna-build, no.
<infinity> Nafallo : I don't have access to the actual ftp queue, so that's the best I can offer.
<Nafallo> infinity: oki, I'll upload it when this :33 is done :-)
<Nafallo> and then go to bed ;-)
<infinity> ajmitch : Q2 looks good./me raises his eyebrow at sffview.
<infinity> Erm.
<infinity> bddebian : sffview is dep-wait on libwxgtk2.5-dev
<bddebian> Hmm
<infinity> Could be an old dep-wait based on a previously-broken package.
* infinity clears it.
<bddebian> infinity: How about spiralsynthmodular?  (Sorry to keep bugging you)
<[Chameleon] > quick question... is Colony 4 much different from the 20050903 nightly ISO w/current updates?
<infinity> bddebian : Ugh. dep-wait on xlibmesa-glu-dev.  I assume it was uploaded to fix gl/glu deps?
<bddebian> Hmm, no, I don't recall it depending on xlibmesa.  Hang on
<infinity> bddebian : And sffview has moved form being dep-wait on libwxgtk2.5 to libwxgtk2.6... PROGRESS.
<infinity> Oh, nevermind, that's an apt bug.
<infinity> Ignore it. ;)
<bddebian> The problem or PROGRESS? :-)
<infinity> The wxgtk dep-wait.
<infinity> It'll autoclear.
<infinity> The xlibmesa thing isn't an apt bug, though.
<bddebian> I'm checking
<infinity> [Chameleon]  : No, but we'd like testing of the installer and livecd.
<[Chameleon] > infinity: OK...
<[Chameleon] > infinity: thx
<[Chameleon] > I'll use some CD-RWs :)
* Nafallo uploads gst-plugins-multiverse again
<infinity> bddebian : Looks like spiralsynthmodular has the correct gl/glu build-deps now.  If you didn't change it, someone (maybe me?) did. :)
<bddebian> infinity: That's a build-dep??
<infinity> bddebian : It's building fine, after clearing the old dep-wait.
<bddebian> infinity: Thx
<Nafallo> wow
<Nafallo> breezy-changes have 6200 messages :-P
<ajmitch> Nafallo: is that all? my breezy-changes folder has > 10000
<Nafallo> infinity: yay! dunno what was wrong before, but it works now ;-)
<ajmitch> a lot of those were from the autosync, before that was redirected to another list
<Nafallo> ajmitch: I moved the debian syncs to ubuntu-changes-auto when that list was created ;-)
* ajmitch didn't care, using gmail for it :)
<Nafallo> :-)
<Nafallo> 6201 uploads to date in breezy ;-)
<Nafallo> hehe
<Nafallo> 5842 for ubuntu-changes-auto ;-)
<lamont> pitti: translations rolling again
<lamont> pitti: and I reimported from july 20 or so... :-)
* lamont wonders if vte is due to be uploaded anytime soon, figures not.
<jbailey> slomo: pong
<fabbione> morning
<bddebian> Hello fabbione 
<fabbione> bddebian: hi, why did you move all my bazzar bugs from malone to bugzilla?
<fabbione> most of them were marked as upstream
<fabbione> and not ubuntu specific
<fabbione> they were supposed to stay there
<bddebian> I know, I was told that after the fact.  My severest of apologies.
<bddebian> Can I fix them for you somehow?
<fabbione> move them back as they are supposed to be?
<fabbione> bddebian: close the bugzilla ones, reopen the malone ones and be sure they are assigned to upstream
<bddebian> fabbione: How do I re-open the Malone ones?
<fabbione> bddebian: edit the bug and mark it as new.. i think :)
<fabbione> bddebian: anyway don't worry too much..
<fabbione> these bugs have been opened for ages with minimal response from upstream
<fabbione> i almost forgot about them until 2/3 people have started playing ping pong with them
<fabbione> ;)
* ajmitch checks the re-opening
<ajmitch> ok, marking as new again works fine
<bddebian> 269 is re-opened
<ajmitch> 318 marked upstream, re-opened
<bddebian> OK, bugzilla bugs closed too
<fabbione> danek
<fabbione> danke
<bddebian> NP, sorry again
<fabbione> jbailey: still around?
<mpt> fabbione: Is there a reliable way of getting the maximum speed of a machine's CPU even on a machine that doesn't support cpufreq?
<fabbione> mpt: /proc/cpuinfo ?
<fabbione> but i don't recall if that is affected by speedstep or not
<ajmitch> it shows the full speed on my laptop
<fabbione> ajmitch: even if the real speed is lower?
<fabbione> ajmitch: what if you boot in slow speed?
<mpt> fabbione: This laptop has a 1.5 GHz CPU but /proc/cpuinfo says 598.630
<ajmitch> fabbione: I haven't found a way to lower the speed, but it's part of the model name as well here
<mpt> fabbione: Unless I can assume that the speed is always going to be in "model name", which seems unlikely
<fabbione> mpt: did you try dmidecode?
<mpt> no
* mpt looks
<fabbione>                 Max Speed: 3200 MHz
<fabbione>                 Current Speed: 2800 MHz
<mpt> oh, brilliant
<mpt> the machine make and model is in here too
<fabbione> mpt: i think the Max speed is referred to the max speed of the processor socket
<fabbione> because this is a 2.8Ghz
<ajmitch> yes, as mine is reported as 1.8GHz
<ajmitch> CPU itself is 1.3
<fabbione> ajmitch: can you try to step down in speed and see if that changes?
<mpt> fabbione: So the problem with dmidecode is that it requires sudo
<fabbione> Current Speed: is sort of a tricky name
<fabbione> mpt: yes. it parses /dev/mem
<ajmitch> fabbione: I can try when I get home, currently looking via ssh
<fabbione> and you truely don't want users to do that
<fabbione> ajmitch: you can force it via /proc, but i don't recall how
<fabbione> ajmitch: anyway just tell to mpt ;)
<mpt> fabbione: Fair enough, but afaik, other popular OSes let anyone see what speed the computer is, whether they're admin or not
<fabbione> mpt: so can you via /proc/cpuinfo. Probably there is an errata on your cpu that's not in the kernel code
<mpt> You mean the kernel needs to be patched to return the correct results for individual models?
<fabbione> mpt: in some cases yes.
<fabbione> that'
<fabbione> that's required when for example there is an error in the cpu (errata)
<fabbione> hw is not bug free ;)
<mpt> ah, and it would be really handy to get that "Product Name:" field from dmidecode too, but it's sudo-only
<fabbione> mpt: why is sudo a problem?
<fabbione> what are you trying to achieve?
<mpt> fabbione: On Windows and OS X, whether you're an admin or not, you can bring up an About box that tells you basics not just about the OS, but also about the computer it's running on
<mpt> I was just trying to achieve something similar
<fabbione> mpt: you should ask ogra..
<mpt> ah, the hwdb guru
<mpt> of course
<fabbione> he wrote the hwdb-client
<fabbione> oh hold on
<fabbione> lshw <-
<fabbione> it doesn't need sudo
<fabbione> and it uses info from hald (iirc)
<mpt> Teh Aewsome!
<mpt> hmmm
<mpt> Doesn't mention the word "Toshiba" once, though
<fabbione> mpt: hold on a sec...
<mpt> It has a "Product Name:" for the processor, that's a start
<mpt> but no "1500 MHz" or equivalent outside of that
<fabbione> fabbione@cerberus:/sys$ find . -name "*cpu*"
<fabbione> mpt: you can poke sysfs...
<fabbione> not sure how much you can gain...
<fabbione> but it's another path
<mpt> ok, thanks very much for your time fabbione
<fabbione> np
* fabbione goes offline to test an install CD
<fabbione> bbl
<mdz> daniels: rename -> just change the seed
<mdz> daniels: my rule of thumb is that if the code is already in main, it doesn't need another review
<pitti> Good morning
* infinity heads out to mail some stuff to jbailey and maybe get a haircut.
<ajmitch> morning pitti 
<pitti> Hi ajmitch 
<carlospc> Hello
<carlospc> Could any body have a look at #14572?
<carlospc> Colin has thinked that is a duplicate of #668
<carlospc> But #668 refers to the users name (the login)
<carlospc> and #14572 refers to the full name of the user
<carlospc> may i send a new bug?
<TheGodFather> is netinstall busted???
<TheGodFather> or is it an archive problem?
<TheGodFather> <- fabbione
<infinity> carlospc : If you don't believe they're duplicates, send a followup to the bug explaning why, don't just keep filing new ones, please.
<carlospc> infinity, thanks
<infinity> carlospc : If you follow the discussion on 14572, howwver, it's already been unlinked and relinked as a dupe, as they are both the same fundamental issue.
<carlospc> a friend talk me about that (the reporter),i've just read all the comments of 14572, as you said is a duplicate 
<carlospc> Ok, now i know what to do in this cases, thanks infinity
<daniels> mdz: kay, cool -- thanks
<pitti> desrt: ping
<desrt> arf.
<pitti> Hi
<pitti> desrt: any luck with daniels and jdub?
<desrt> haven't seen jdub.  haven't talked to daniels about it
<pitti> ah, ok
<desrt> daniels; 'sup? :)
<desrt> i hear of acpi badness?
<infinity> pitti : Had a chance to figure out why hald isn't polling /proc/acpi like you say it should?
<desrt> pitti; btw... you're out of sync with HEAD
<infinity> Oh, hey, wait.  It just did.
<infinity> WTF.
* infinity frowns.
<desrt> pitti; so my patch utterly fails to apply to breezy's hal
<infinity> Oh sure, NOW it works.
<pitti> desrt: right, we still have 0.5.3
<desrt> nod
<pitti> desrt: right, infinity was the other person who could reproduce it (not now any more, as it seems)
<desrt> i figured you had mostly kept up to date with the latest and greatest, though
<desrt> (which you mostly have... but not entirely)
<pitti> desrt: any additional patches I should throw in?
<daniels> desrt: yeah, seems to be heisenbugish though
<desrt> pitti; i tried to throw in acpi.c from HEAD.  it didn't go so well :)
<desrt> daniels; :/
<desrt> pitti; you reasonably could use HEAD's acpi.c if you added a utility function to another file.... i don't know if you want to though
<infinity> Yergh.  What a pain.  Can't reproduce it at all now.
<desrt> RESOLVED FIXED
<desrt> :)
<desrt> infinity; please keep your eye out
<desrt> infinity; the problem is that hal stops getting updates from acpid, right?
<daniels> gar why does metacity keep segfaulting
<desrt> daniels; see gnome bug #315000
<desrt> daniels; patch provided
<pitti> desrt: I think that approach would be fine, if it helps to fix more bugs
<desrt> fixed x86 binary is also here if you're feeling funky: http://manic.desrt.ca/metacity :)
<desrt> pitti; ok.  i'll look into having a patch for you tomorrow
<pitti> desrt: so all these bugs are confined to acpi.c?
<desrt> pitti; ya.  ACPI SUCKS
<desrt> all the other backends are simple and just work
<pitti> desrt: ok, then I just edit-patch the big acpi-fixes patch and throw in acpi.c from head
<desrt> acpi has to deal with a million broken cases
<pitti> desrt: I can do it myself, but I need to wait until tomorrow
<pitti> (after preview)
<desrt> pitti; if you use HEAD's acpi you'll have to modify another file
<pitti> desrt: just add a function?
<desrt> pitti; HEAD's acpi uses a new calculate_percent function
<desrt> (some name like that)
<pitti> that should be easy to find
<desrt> you might want to just patch that part out, though, since i don't think your other backends will provide the same %age info
<desrt> & that way you don't need to patch the other file either
<desrt> i think i just found daniels/infinity's problem
<desrt> -rw-r--r--  1 root root 2580 2005-09-02 12:47 acpi-support/changelog.gz
<desrt> when you guys upgraded this package acpid got restarted
<desrt> it seems that hal can't survive an acpid restart
<desrt> (or rather, it survives, but after that receives no further acpi events)
<daniels> obviously the solution is to NEVER EVER RESTART ACPID :P
<desrt> or uh.. fix hal :P
<pitti> desrt: can hal reconnect if it detects a SIGPIPE on the socket, or whatever?
<desrt> pitti; maybe?  i don't really know
<desrt> pitti; i bet the authors just didn't think of restarting acpid as something worth handling :)
<pitti> daniels: better idea: we restart hald/dbus again and additionally do /etc/init.d/gnome-session restart. MUHAHA
<daniels> desrt: this sounds oddly like an argument we've had before about another daemon
<desrt> hmm
* desrt tries to think about this
<desrt> seriously, though.... the only reason i was on that side in the argument was because upstream had good reasons
<desrt> reconnecting everything to the system bus properly, and in order, is seriously difficult
<desrt> acpid isn't a bus... it's simple client/server
<desrt> server restarts -- clients should reconnect
<desrt> anyway it's on my tomorrow todo list... i'm too tired now
<desrt> cheers.
* TheGodFather grrrrrs
<jsgotangco> when i search pr0n in beagle, it mostly finds jdub's blogs
<pitti> Hey hey dholbach 
<dholbach> good morning
<dholbach> hey pitti
<siretart> bob2: around?
<sivang> morning all
<dholbach> hey siretart 
<dholbach> sivang :)
<siretart> huhu dholbach 
<siretart> bob2 hates me :(
<ajmitch> heh
<ajmitch> what have you done to him now? :)
<dholbach> siretart: he doesn't - send him a nice "bernd das brot" cartoon and he'll love you :)
<siretart> ajmitch: oh, it just because of lyx broken in universe :(
<bob2> I'm fixing it atm
<bob2> bbiab
<bob2> going through the diff between "files in 1.3.4" and "files in 1.3.6" is long and tedious
<dholbach> morning bob2 :)
<siretart> bob2: jipiee! :) - thanks dude!
<sivang> hey dholbach 
<sivang> dholbach: what brings the day?
<dholbach> sivang: a bunch of gnome updates :)
<sivang> dholbach: nice
<dholbach> sivang: how are you?
<sivang> dholbach: fine, trying to figure yet how to add an appropriate PKG_CHECK_MODULES call for a subtree of the src tree I'm working on
<dholbach> good luck with that :)
<sivang> dholbach: I have just copied from another call in the same configure.ac, however somehow configure ignores it
<Lathiat> sivang: whatcha tryign to do>?
<daniels> sivang: you did re-run autoconf, right?
<sivang> daniels: hey what'ya think I am ;=) ?
<daniels> sivang: also, if your first PKG_CHECK_MODULES call is within an if statement, then you have to run PKG_PROG_PKG_CONFIG or something
<Mithrandir> sivang: you need to change the first part of the PKG_CHECK_MODULES
<Mithrandir> you can't have PKG_CHECK_MODULES([FOO] , "$mumble") and then PKG_CHECK_MODULES([FOO] , "$mumblemore") later
<Lathiat> PKG_PROG_PKG_CONFIG is correct
<sivang> Mithrandir: I added a VARNAME to the first part of the _CHECK_MODULES thingy, and added that same VARNAME_CFLAGS and VARNAME_LIBS to the Makefile.am of the module I want PKG_CHECKED_MODULES'd
<sivang> Mithrandir: still, it won't do the SUBST
<daniels> sivang: so you have PKG_CHECK_MODULES(FOO, bar baz quux), and then AC_SUBST(FOO_LIBS), etc
<sivang> daniels: yes, exactly
<sivang> daniels: in fact:
<sivang> PKG_CHECK_MODULES(GWEATHER_APPLET_2, lpint-bonobo)
<sivang> AC_SUBST(GWEATHER_APPLET_2_CFLAGS)
<sivang> AC_SUBST(GWEATHER_APPLET_2_LIBS)
<sivang> Lathiat: what's PKG_PROG_PKG_CONFIG all about?
<sabdfl> seb128: ping
<seb128> sabdfl: pong
<sivang> hey sabdfl 
<sabdfl> seb128: can we please move the Terminal and File Browser to Accessories, rather than System Tools?
<seb128> sabdfl: sure, I'll do that this morning
<sivang> daniels: and in INCLUDS section in the Makefile.am : $(GWEATHER_APPLET_2_CFLAGS)     \
<Burgundavia> sabdfl, shall we drop root terminal at the same time?
<Burgundavia> sabdfl, techincally we are passed UI freeze, but I happen to know that no docs reference any of those
<jsgotangco> Burgundavia, eerrr why?
<Burgundavia> jsgotangco, because it is crap
<Burgundavia> and confuses users
<sivang> daniels: and in gweather_applet_2_LDADD = $(GWEATHER_APPLET_2_LIBS)
<Mithrandir> sivang: if you read the comments in pkg.m4, it's easier to understand.
<jsgotangco> sure its probably better to move it elsewhere than remove it
<sivang> daniels: where am I going wrong?
<sivang> Mithrandir: /me looks
<Burgundavia> jsgotangco, there is an open bug
<sivang> Mithrandir: aclocal.m4 ?
<Mithrandir> no, /usr/share/aclocal/pkg.m4
<sivang> Mithrandir: hmm , also do I need a specific AC version to make this directive work?
<Mithrandir> sivang: no, any version should work.
<sivang> Mithrandir: (AC=2.59, AM=1.4-p6)
<sivang> Mithrandir: OF = what's the deb-pkg name for the Python/Zope doctest modules? (that one that holds a Browser module that allows you to write automatic tests for interactive website, for instance)
<zyga> hello
<zyga> I just noticed something strange in breezy
<Burgundavia> seb128, sabdfl when you ask for UI changes after UI freeze date please CC the doc list so that we can adjust docs as needed
<zyga> xorg.conf had a keyboard driver 'kbd' and no non-ascii characters were inputable
<zyga> that's a leftover from warty probably, right?
<daniels> no, 'kbd' is fine
<zyga> daniels: hmm
<daniels> i'm using 'kbd' now and all non-ASCII wrks fine
<zyga> still I cannot enter non-ascii characters
<zyga> daniels: clean install or upgrade?
<daniels> then you have a problem with XKB
<daniels> zyga: both
<zyga> daniels: any way to solve it?
<daniels> zyga: not with this little information.  i'd need your xorg.0.log and xorg.conf, but this is really a #ubuntu type of question.  also, if you've been upgrading through breezy, you need to read my mail to ubuntu-devel on how to fix xkb.
<seb128> mvo: around?
<zyga> daniels: okay, I'll read your mail - thanks
<mvo> seb128: yes
<seb128> mvo: what am I supposed to do with your lpi changes? say if the de translation is correct? :p
<seb128> mvo: I've sent you a fr.po
<mvo> seb128: oh, nice! I can do the upload if you want. I just wanted to check with you that liblaunchpad-integration0 is the right place for the po files (not that it matters a lot as you already pointed out :)
<seb128> mvo: looks fine to me
<seb128> please go ahead
<sivang> seb128: what more lpi changes are made?
<seb128> sivang: translations
<sabdfl> Burgundavia: good point, thanks for the reminder
<mvo> seb128: thanks, will do
<sabdfl> Burgundavia: why drop root terminal? so that docs can just consistently refer to sudo?
<Burgundavia> sabdfl, we also stop writing on the 8th, so after that date, menu changes are going to require more work
<Mithrandir> sivang: no idea, sorry.
<Burgundavia> sabdfl, https://bugzilla.ubuntu.com/show_bug.cgi?id=12587
<jsgotangco> actually imo its not really a good idea to move stuff that dirverge from gnome standard
<jsgotangco> (but its just me)
<sabdfl> ok, seb128, could ew drop the Root Terminal too, please? cc Burgundavia and mdz
<sabdfl> s/ew/we/
<jsgotangco> ackkk
<Burgundavia> jsgotangco, did you see that bug?
<seb128> sabdfl: we can drop it, sure. Cc on what? Should I send a mail?
<sabdfl> jsgotangco: understood, but balance that against the way we handle root, which is non-traditional (and hopefully better)
<Burgundavia> seb128, just drop a note on -doc about the UI changes
<sabdfl> seb128: just an fyi so there's less WTF??? going on :-)
<seb128> sabdfl: k
<sabdfl> thanks very much
<daniels> Package: linux-restricted-modules-2.6.12-8-amd64-generic-nvidia-legacy
<sabdfl> seb128: nice to see the 2.12's dropping in this morning!
<sabdfl> hey daniels
<daniels> that's getting into longest-name territory, there
<daniels> sabdfl: g'morning
<sabdfl> BenC: ping
<seb128> sabdfl: thanks :)
<Burgundavia> sabdfl, you had a chance to look at our Quick Tour stuff?
<jsgotangco> oh well
<Burgundavia> sabdfl, https://docteam.ubuntu.com/repos/trunk/gnome/quicktour/
<sivang> Mithrandir: the comments doesn't tell me too much...:-/
<sabdfl> Burgundavia: the .html in there comes to me as text/plain?
<Burgundavia> sabdfl, that is because of it being an svn repo. Pull it down and view it in F
<Burgundavia> FF
<sivang> daniels: can I use PKG_CHECK_EXISTS instead? seems like a more manual way to go, and independent weather the first instance of PKG_CHECK_MODULES was called or not
<sivang> daniels: question is, does it add the rigth _CFLAGS and _LIBS just as _CHECK_MODULES does
<Mithrandir> daniels: you're trying to find buffer overflows in dpkg by crafting long names?
<daniels> sivang: no idea, sorry
<daniels> Mithrandir: heh
<daniels> Mithrandir: possibly a stupid question, but you haven't got any old nvidia kit, have you?
<daniels> i'm looking for someone with a geforce2 or something *not* supported by the current nvidia binary drivers
<zyga> daniels: sorry for bothering you again; I've read the entire thread but keyboard configuration applet keeps crashing and displayng error messages
<daniels> zyga: crashing?
<daniels> zyga: if it crashes, then that's a gnome bug
<zyga> daniels: no, not sigsegv  - I used a wrong word
<Mithrandir> daniels: I can probably dig something up.
<zyga> it displays an error dialog asking for results of two commands (the same you gave in the email thread)
<Mithrandir> I might have a TNT2 ultra lying about
<zyga> I followed all instructions on the list
<daniels> Mithrandir: if you could give that a shot with a current nvidia kernel module (say, 7667 -- current l-r-m), but an old nvidia-glx (say, 7174, from hoary), that would be fantastic
<daniels> zyga: please file a bug on bugzilla with the output of those two commands, xorg.conf, and xorg.0.log
<Mithrandir> daniels: I'll give it a shot in a little while
<daniels> Mithrandir: no hurry, thanks
<zyga> daniels: k
<Lathiat> daniels: i have one
<Lathiat> daniels: if you awnt more info
<pitti> Kamion: I will shrink the powerpc install a bit by removing a language pack; are you fine if I re-add some langpacks to i386 and amd64 again? they have plenty of space
<daniels> Lathiat: just what I asked above about new kernel module + old userspace driver
<daniels> Lathiat: if it works, it would make my life *dramatically* more simple
<Lathiat> daniels: uh ok i'll try but im fairly sure its the kernel module that banrfs out and refuses to load?
<kronoss> hi
<pitti> Hi kronoss 
<mjg59> daniels: Do you know if the ALPS pad specification is available?
<daniels> mjg59: no clue
<daniels> Lathiat: okay
<daniels> Lathiat: would be great if you could
<daniels> Treenaks: ping
<mvo> Kamion: permission to upload launchpad-integration with {de,fr,pt,pl}-po updates?
<pitti> Hi astharot 
<astharot> good morning...
<astharot> Hi martin :)
(Kamion/#ubuntu-devel) Burgundavia: you know you can set the svn:mime-type property to tweak a file's MIME type in svn, don't you?
<Kamion> pitti: (sorry, that was yes to both)
<mvo> Kamion: thanks
<daniels> yarrrrrrrrrrrrrrrrrr, I'm an idiot
<daniels> fifteen minutes of debian/control hand-hacking lost to the existence of debian/control.stub
<daniels> Kamion: hrm, how often does your seed mirror kicK
<Kamion> daniels: 3,18,33,48 * * * *      seeds-archive-mirror
<Kamion> daniels: 5,20,35,50 * * * *      update-seeds
<Kamion> daniels: (the former on chinstrap, the latter on rookery)
<daniels> Kamion: 'kay, ta
<jdub> GOOD MORNING FREEDOM LOVERS!
<jsgotangco> hey jdub
<jsgotangco> jdub, just a thought, i was doing some beagle search and decided to search for pr0n and all hits went to you ;)
<ogra> jsgotangco, thats hardcoded :)
* Mithrandir looks at this crack
<sivang> jdub: Jeff !
<jdub> jsgotangco: heh, my blog?
<sivang> ogra: lol
<jdub> sivang: dude, i was with the ppc hackers at ozlabs today :)
<sivang> jdub: wheee! ozlabs - ibm ? 
<jdub> yeah
<jsgotangco> did it work?
<sivang> jdub: nice nice, were you hacking things, or planning ahead? any interesting news from there?
<jdub> chatting to them about ubuntu love
<jdub> and ppc stuff in general
<jsgotangco> ahhh
<jsgotangco> that's a good start for a working relationship
<sivang> jdub: very nice. What about test suits and stuff? did you get any of those already? (did you discuss the certification at all)
<jdub> sivang: talked about it, but not in immediate terms
<sivang> jdub: k, cool. Btw, I've tried to test the latest daily's with the new flags in, it boots to yaboot at last, but br0ken, since it's clueless of where to boot from and spits one error about wrong/unrecognized fs.
<sivang> jdub: (colin has already added them to debian-cd )
<sivang> if only the HMC was kind to let me cut and paste the error messages :)
<jdub> heh
* sivang needs to try to open the X session remotely from that SUSE powerd bulky black box..
<sivang> bah:
<sivang> sivan@hmc:~> cd /
<sivang> -bash: cd: restricted
<pitti> Kamion: I fixed the langpacks on the install CDs, based on today's image sizes
<pitti> Kamion: can we do another image today, to verify? This time I used proper arithmetics instead of guesstimating, but still...
<Mithrandir> can we _please_ drop automake 1.4 for breezy+1
<Mithrandir> ?
<Diziet> What has become of the `quick guide' ?
<pitti> Kamion: the overflow on live CD is not a language pack fault; we already crippled them to contain *no* language packs at all (which is sooo bad, but oh well...)
<kronoss> is there no languajes on live cd?
<pitti> unfortunately not
<kronoss> whats the size of a langpack?
<kent> pitti, I guess it would be to much to create language-specific ISOs? 
<slomo> jbailey: do you know where i can look for openfirmware updates?
<Riddell> elmo: can you apt-get build-dep kdebase on the breezy and hoary chroot
<daniels> phew, new l-r-m finally done, I think
<daniels> Lathiat: any news?
<daniels> actually, hm, time to collapse for the night
<pitti> back
<pitti> kronoss: http://people.ubuntu.com/~pitti/langpacks/langpack-sizes.txt
<pitti> kronoss: it shows the gnome and kde flavours (for Ubuntu and Kubuntu), and also the cumulative siue
<zyga> solong guys :-)
<ivoks> seb128: ping
<seb128> pong
<ivoks> seb128: gnome media will stay version O? :)
<ivoks> 2.12.O
<seb128> yep
<seb128> why ?
<seb128> you are the guy who mailed me?K
<ivoks> yep :)
<seb128> you are the guy who mailed me?
<seb128> and the guy who filled a bug?
<ivoks> maybe :)
<kronoss> pitti, cannot be created localized isos or jigdo lists?
<seb128> ivoks: what is the purpose of the mail?
<ivoks> seb128: well, O is letter, not a number
<frans-th> anyone know matthias? what is his nickname!!
<seb128> ivoks: I had that on my "try to figure what this guy want" list
<seb128> ivoks: and know that, and? your mail is a real question?
<ivoks> ok
<ivoks> sorry
<ivoks> i just tought you had a typo...
<seb128> ivoks: right, but it's done
<seb128> ivoks: "That's 2.6.12.O, O as big letter o. Typo?" ... what kind of reply do you expect?
<seb128> ivoks: "no, that's just to note how many people will send a mail to know if we make funny versions now"?
<pitti> kronoss: that's hard, we have enough trouble with managing 12 CD images, we can't multiply that by 50
<ivoks> seb128: i didn't want to make you angry, sorry
<seb128> ivoks: I'm not angry, I don't what is your question
<seb128> ivoks: you ask if 2.12.O is a typo seriously?
<seb128> ivoks: seems obvious it is to me
<seb128> s/don't/don't get/
<Kamion> kent: yes, it would be too much; we don't have the resources to create or to test lots more images
<ivoks> seb128: yes, cause till now, only numbers were in major version number... now we have letter O
<chrissturm> seb128, i think questions like these are called rhetorical questions :)
<seb128> ivoks: k, seems not clear to you. So let's it "using 2.12.O instead of 2.12.0" is a typo
<pitti> Riddell: ping
<seb128> chrissturm: why people send mails with such questions? :)
<seb128> s/let's/let's say/
<ivoks> seb128: i asked, i didn't say it's a typo
<Kamion> this is an awful lot of conversation about one character
<ivoks> there really is no point in arguing about this... if it's ok by you, it's ok by me
<Kamion> Riddell: are you looking at the Kubuntu CD overflow? if not, please do
<seb128> ivoks: that's a typo, there is no reason to change 12.0 to 12.O on purpose ...
<dholbach> ivoks: we'll work around it, not a big deal :)
<Kamion> pitti: I've kicked a new build
<seb128> ivoks: and .O is newer than .0 so there is no way to upload 12.0 now, and I'm not going to use an epoch for that
<dholbach> seb128: gnome, gnomeui and gnomecanvas done now :)
<pitti> Kamion: thanks
<Kamion> oh, no I haven't, there's a build already running
<ivoks> seb128: i know
<pitti> Kamion: I didn't yet touch Kubuntu (will do that ASAP)
<seb128> dholbach: nice
<pitti> Kamion: any idea how to fix the live CDs?
<seb128> ivoks: if you know don't send mails for nothing, thanks :)
<Kamion> pitti: "fix"?
<pitti> Kamion: downsize
<seb128> dholbach: yelp and libxml to go 
<pitti> Kamion: I don't know why they grew so big
<seb128> dholbach: and with the new gnome-vfs we have GNOME 2.12.0 :)
<dholbach> seb128: ROCK'N'ROLL! :)
<pitti> Kamion: actually I would have liked to see at least the top-12 langpacks on them, but now they are too big even without any packs
<dholbach> seb128: i'll investigate in yelp now
<pitti> Kamion: do these CDs still contain WinFOSS software?
<Kamion> pitti: yes, they do
<pitti> Kamion: hm; maybe we should downsize that? I don't see the point in crippling the Ubuntu demo in favor of adding Win software (that's not the primary purpose of the live CD, is it?)
<Kamion> perhaps we can ask Henrik to downsize that
<Kamion> the Windows software on the live CD is actually really good for pulling in new users
<pitti> hm
<Riddell> Kamion: is it still overflowing?  where can I find how much it's overflowing by?
<pitti> but then they see an absolutely ridiculous Gnome desktop
<Riddell> pitti: pong
<pitti> will this convert them to Ubuntu then?
<Kamion> Eben Moglen commented on it at LCA - first they use the Windows bit, then the live CD, then they install for real
<Kamion> pitti: this isn't black-and-white, we can reduce the size of the WinFOSS segment without having to kill it entirely
<Mithrandir> Kamion: ok to upload http://err.no/patches/libquicktime_0.9.3-2ubuntu1_0.9.3-2ubuntu2_ftbfs_fix.diff ?
<Kamion> Riddell: http://cdimage.ubuntu.com/kubuntu/daily/current/
<Kamion> Riddell: lists CD sizes
<ogra> pitti, drop thunderbird ;)
<ogra> pitti, that gives you an enormeous amount of space, i did it on edubuntu
<dholbach> ogra: mark wouldn't like that
<Mithrandir> ogra: tb is one of the applications which exists for both windows and linux, and that's a major win.
<pitti> ogra: tbird is on the live CD?
<pitti> oh, right
<ogra> pitti, but Mithrandir is right... for the liveCD its important..
<Kamion> Mithrandir: yes
<Kamion> ogra: we discussed all this the other day
<Mithrandir> Kamion: thanks
<ogra> Kamion, yup... i'm a bit more free with edubuntu, i tend to forget about that :)
<Kamion> Riddell: the sizes listed there are in powers-of-two megabytes, so just get it down to 650 and you should be fine
<Kamion> Riddell: I'd suggest starting by dropping some of the very unusual languages from i386 and amd64
<Kamion> although you need to do something with powerpc too
<Kamion> (which has many fewer languages there to start with)
<Riddell> Kamion: I synced kubuntu's ship with ubuntu last night, what else do I have to change for that to take effect?
<pitti> Riddell: if you want, I will fix the langpacks for Kubuntu
<pitti> Riddell: I just wrote a script that assists me on that
<pitti> Riddell: http://people.ubuntu.com/~pitti/langpacks/langpack-sizes.txt
<doko> Riddell: Is 13923 important to be fixed?
<Kamion> Riddell: I don't see any commits from you since 14 August
<Riddell> doko: I've fixed that
* Riddell closes
<Kamion> the last commit to the kubuntu-breezy seeds was from me on 1 September
<Riddell> "arch: no arch user id set"  hmm, that could be the problem
<Kamion> sabdfl: Dropping python-numarray from desktop would save us a few valuable megabytes, because we wouldn't have to ship lapack3; do you have any objections to that? It doesn't look very core
<sabdfl> Kamion: +1
<Kamion> hmm, I wonder if python-tk is all that valuable in desktop
<Kamion> although it's pulled in anyway from python-imaging, so might not be trivial to untangle
<Kamion> sabdfl: thanks
<Kamion> mdz: opinion on removing python-numarray from desktop?
<fabbione> pitti: i just got the crack.. thanks
<Kamion> actually, I'll just DOIT
<pitti> fabbione: you thank me for sending abi changing patches? :) great, want more? :-)
<pitti> Kamion: ++
<pitti> I think there is a whole lot of python libraries in desktop that are probably uninteresting for the average desktop user anyway
<fabbione> pitti: yes.. it changes the ABI... but i think all these stuff is in 2.6.12.6 already
<fabbione> and it has been published
<Kamion> I'm not looking at python per se - just at the list of packages in desktop sorted by size
<pitti> fabbione: ok, BenC will have fun :-)
<Kamion> ttf-baekmuk is annoyingly huge
<pitti> hm, but we probably need it to display spam^WKorean content properly
<Kamion> indeed
<Kamion> anyone know if .ttf files can be stored in compressed form?
<Kamion> although I guess it wouldn't help the .deb size anyway
<pitti> Kamion:  the deb is already compressed
<pitti> Kamion: another question is whether we really need 4 huge chinese fonts
<pitti> ttf-arphic-*
<Kamion> mm
<pitti> they need 20 MB
<pitti> maybe one is enough
<marcin_ant> hi guys
<marcin_ant> does anyone here knows whats going on with google SoC projects granted to Ubuntu?
<pitti> marcin_ant: what do you want to know in particular?
<marcin_ant> I wonder what is the status of firewalling project, and bluetooth support
<Kamion> pitti: I don't think they're equivalent
<pitti> marcin_ant: firewall: concept is ready, backend is half-done, frontend is in the beginnings
<Kamion> two are GB* and two are Big5, to start with
<marcin_ant> hmm any websites for soc projects? any changelogs? afaik - no PR at all - it is pretty strange - a lot of PR and rumour at the beginning
<marcin_ant> and now while deadline was 01.09 it's all quiet
<Kamion> (i.e. Simplified vs. Traditional Chinese)
<marcin_ant> pitti, and what about bluetooth?
<spayne> i've tried reinstalling metacity, gnome-themes and gtk-engine-clearlooks
<pitti> marcin_ant: I don't know, chmj did the main testing
<spayne> and the problem still exists
<spayne> so I have no idea what it is
<spayne> the corners of the Metacity bar are not rounded on two of my machinse
<spayne> and I can't work out why
<marcin_ant> pitti, does it have some repository to take a look?
<spayne> screenie: http://www.evolutioncolt.com/~spayne/shots/metacity-050905.png
<pitti> marcin_ant: http://svn.berlios.de/viewcvs/bluetool/trunk/
<marcin_ant> pitti, thanks - and what about firewalls?
<marcin_ant> pitti, anyway cannot you just create some webpage like this for fedora: http://fedoraproject.org/wiki/FedoraBounties ?
<dato> is there something similar to snapshot.d.n for ubuntu? or how could I retrieve an old version of an ubuntu package (hal)?
<pitti> marcin_ant: it's still not in an SCM, but there are some preliminary packages at http://www.fh-trier.de/~heyc/ufw/
<Mithrandir> dato: if the morgue hadn't been broken, you could have gotten it from morgue.ubuntu.com
<pitti> dato: which version do you need?
<Riddell> elmo: can I get access to the hoary chroots on concordia please
<dato> pitti: 0.5.2-0ubuntu3
<pitti> dato: nope, we don't have that
<dato> pitti: ok
<pitti> dato: so it seems the morgue is broken
<pitti> marcin_ant: our bounty page will be updated shortly
<marcin_ant> pitti, ok it could be nice
<marcin_ant> pitti, thank you anyway for info
<mvo> Kamion: could you please have a look at the patch for #14504? 
<Kamion> mvo: I think the first -mtime -and -ctime should be -mtime -or -ctime
<Kamion> "if the file's data or status was changed within the last $MaxAge days"
<Kamion> mvo: same for the second, actually - I don't think -mtime -and -ctime makes sense
<Kamion> mvo: you use stat -c %Y to get the ctime, but stat(1) says that should be stat -c %Z
<Kamion> mvo: I think it would be worth using stat(1) to get both mtime and ctime in the second chunk; as it is I'm left wondering whether stat(1) and date(1) output exactly the same format (I'm sure they do, but still)
* Kamion wonders why python2.4-samba is in desktop - seems a bit esoteric
<Kamion> not to mention large
<mvo> Kamion: right, I'm going to fix all this now, thanks
<Kamion> cheers
<Kamion> (I was wrong about that -and and -or stuff, due to misreading other arguments)
<thesaltydog> after upgrading to breezy from hoary I am experiencing a great performance loss. Running top doesn't help...
<thesaltydog> every file open is very slow
<OculusAquilae> thesaltydog: strange, my breezy (kubuntu) seems to be faster
<Mithrandir> Kamion: ok to upload http://err.no/patches/libgnujaxp-java_1.3-3ubuntu1_1.3-3ubuntu2_ftbfs.diff ?
<thesaltydog> OculusAquilae, did you upgrade from hoary?
<OculusAquilae> on one pc yes, but i reinstalled it from cd
<Kamion> Mithrandir: yes, looks fine
<thesaltydog> OculusAquilae, maybe the update process from hoary is not well tuned..
<Lathiat> hrm if you have an NTFS partition in the installer
<Lathiat> you cant change its mount point
<Lathiat> nor can you reselect it to be mounted as an existing NTFS if you change it
<Kamion> Lathiat: looks like #14236
<Kamion> I haven't done any work on that bug yet though
<Lathiat> ok
<\sh> mvo: ping
<\sh> mvo: is there a documentation to launchpad integration for python? 
<mvo> \sh: pong
<mvo> \sh: not really, but it's fairly easy
<\sh> mvo: so I could hackit somehow into gajim ,-)
<Lathiat> Kamion: ooc, why arent all the packages just installed before reboot
<seb128> \sh: it's not a desktop component
<seb128> \sh: we said we will not patch out of the desktop
<Lathiat> ++++
<mvo> \sh: shouldn't be a big deal, I'll /msg you a example, ok?
<\sh> seb128: as i understand it's responsible for implementing a direct gateway to malone? 
<\sh> mvo: sure :) 
<seb128> yep
<seb128> but we are not going to make thousands of patches
<seb128> we will probably do a picker for non-patched stuff
<\sh> seb128: so I can redirect all showstoppers and bugreports to the product of gajim, registered in LP
<seb128> nothing specific to gajim
<Kamion> Lathiat: mainly because you want to reboot sooner rather than later to find out whether you actually can boot successfully into the new system before spending ages installing packages
<seb128> that's true every single app
<Kamion> Lathiat: also because the pre-reboot environment is rather limited and difficult to work in
<Kamion> Lathiat: that said upstream may be moving to installing everything pre-reboot at some point, once the pre-reboot environment has been beefed up enough; we'll see
<\sh> seb128: that's enough
<Kamion> but I have no interest in going it alone in changing that
<Lathiat> Kamion: cant you just run thigns in chroot of the main install ?
<Kamion> Lathiat: not that easy
<Lathiat> why niot?
<Kamion> Lathiat: you still need to interact with the user sometimes
<Lathiat> Kamion: sure but thats not hard
<Kamion> you reckon?
<Kamion> it's really fiddly - you have to mess around with the debconf passthrough frontend
<Kamion> trust me, I've done it
<Kamion> and it sucks :)
<Lathiat> can'tr you just display programs from inside the chroot on the current TTY or whatever?
<Kamion> they'd look jarringly different
<Lathiat> (im not so wanting to convince you otherwise, but wanting to understand the problems)
<Kamion> cdebconf and debconf's newt frontends don't look the same, largely due to historical differences in implementation
<Lathiat> ah ok
<Kamion> it would be very obvious if you displayed them effectively side-by-side without an intervening reboot
<Lathiat> i guess thats why i never noticed? ;)
<Kamion> plus, you actually can't do that anyway, because cdebconf runs on tty1 for the duration of the install
<Kamion> blatting something else on top of it would be rather undesirable
<Lathiat> no interaction happens in our post boot anyway
<Kamion> not true - X sometimes asks for the monitor resolution
<Lathiat> my other curiousity
<Lathiat> Kamion: ah, true
<Lathiat> is how hard is it to move things like the keyboard, timezone, user setup to post boot?
<Lathiat> (im thinking like an OEM-style install)
<Lathiat> where you set that up when you get the machien post-install
<Kamion> and in any case I wouldn't want to make such a complex change separate from Debian, and they do have questions asked post-reboot
<Kamion> Lathiat: http://wiki.ubuntu.com/OEMInstaller
<Kamion> see the oem-config package
<Lathiat> ah
<Diziet> Anyone here know about ubuntu-docs ?
<dholbach> i take a walk - brb
<jbailey> slomo: I don't, sorry.  I'm not enough of a Mac user.  Have you found anything yet?  If not, I can try asking around as well.
<slomo> jbailey: i found nothing :(
<pitti> Hi jbailey 
<\sh> re sabdfl 
<jbailey> g'm Martin, Mark.
<sabdfl> hiya
<sabdfl> mvo: am testing hoary->breezy upgrades on silb's laptop
<Diziet> jbailey: Ah, hello.  It has your name on it so I'm going to bug you.
<dholbach> Diziet: #ubuntu-doc should know :)
<Diziet> Oh, there's a #ubuntu-doc ?  I'll go ask there.
<sabdfl> currently, "smart upgrade" wants to remove ubuntu-desktop
<mvo> sabdfl: how is it working so far
<sabdfl> any ideas or suggestions?
<mvo> sabdfl: is there anything unusual about her setup? or is she only using official sources?
<sabdfl> only official, main, restricted, universe
<sabdfl> is there a view which says *why* it wants to remove something?
<dholbach> sudo apt-get -s dist-upgrade  ?
<sabdfl> hmm... elmo says it's because of readahead-list
<sabdfl> dholbach: good call ;-)
<mvo> sabdfl: you can use "Settings/Set internal option" and then set "Debug::pkgProblemResolver" to "true" and see a huge amount of output on synaptics stdout 
<dholbach> bbl *wave*
<mvo> sabdfl: if you send it to me, I can have a look
<elmo> mvo: yes, I just did that
<mvo> elmo: can you mail/msg me the result? 
<elmo> mvo: I'll get jane to send it to you
<elmo> the problem seems to be ubuntu-desktop Depends: readahead while readahead-list C/P/R readahead
<elmo> dselect can deal with it, apt-get dist-upgrade/synaptic can't
<elmo> at least from my off-the-cuff reading of the pkgproblemresolver output
<mvo> elmo: apt-get/synaptic use the same algorithm for dist-upgrades, how is aptitude doing?
<Kamion> that's u-d from hoary presumably; u-d/breezy Depends: readahead-list
<elmo> haven't tried aptitude yet
<mvo> elmo: it uses it's own algorithm that produces better results sometimes (and funny ones at other times)
<mvo> elmo: if it's not too much hassle, I would be curious 
<elmo> kamion: hum
<elmo> Kamion: sorry, you're right, it does
<elmo> so I've no idea why
<elmo> mvo: aptitude seems to work, at least it doesnt' consider ubuntu-desktop broken
<elmo> mvo: let me know if that log jane sent is enough; if not, I can play remote hands some more
<mvo> elmo: interessting, thanks
<mvo> elmo, silbs: the sources.list and the list of installed packages would be interessting as well (e.g. with synaptic,file/save markings, save full state)
<pef> hi
<silbs> mvo: sent
<mvo> silbs: thanks!
<pitti> does anybody have a simple python dbus demo application? maybe something resembling dbus-monitor?
<seb128> pitti: you might want to try pinging ross about that
<seb128> pitti: he's on gimpnet IRC
<pitti> thanks seb128 
<seb128> np
<sivang> pitti: that would be great to have something like that. Long been wished ;)
<pitti> seb128: he does not know anything about it 
<seb128> pitti: yeah, I've read that
<pitti> sivang: dbus-monitor exists, I just want to know why python-dbus is broken
<seb128> that was worth trying, he does quite a lot of dbus hacking
<pitti> hal-device-manager does not get hal events any more
<mxpxpod> zul: hey
<Lathiat> hmm, how can i import a particular gpg key into apt
<bddebian> Howdy
<sivang> bddebian: hey Barry, 'sup?
<mvo> Lathiat: apt-key add
<bddebian> sivang: Heya.  Not much, you?
<bddebian> elmo: ping
<zul> mxpxpod: wlan-ng has been comitted already
<mxpxpod> zul: I saw that... thanks a ton!
<mxpxpod> now I can use ubuntu kernels again and quit compiling my own ;)
<Lathiat> mvo: thanks
<zul> mxpxpod: no probs
<sivang> bddebian: finishing my last lpi patch - gnome-applets
<Riddell> Kamion: I've synced the kubuntu seeds with the ubuntu one for language packs, could you start a new CD build so we know the current size
<bddebian> sivang: Nice
<sivang> bddebian: Well, after I did the first round (gnome-panel) the second round plain just-do-it thing ;)
<bddebian> sivang: :-)
<seb128> sivang: about gnome-panel, no need to put a 14_autoconf patch when there is already a 12_autotools updating the configure ...
<sivang> seb128: ok, but when happens if you want to drop the patch completely due to some unpredicted reasons - you will have to re-edit that patch, creating "yet another patch" relieves you of doing so.
<seb128> sivang: ?
<seb128> sivang: if you want to drop the patch you update the autotools one, no big deal
<seb128> sivang: 2 patches conflicting like this is wrong
<sivang> seb128: ok, so all the autotools changes go there?
<seb128> sivang: your patch maybe broke the autotools one
<sivang> seb128: you mean, 12_lpi_autoconf broke 12_autotools ?
<seb128> yeah, autotools patch is enough, no need to update the configure with 2 different patches
<seb128> 12_autotools update configure
<seb128> 14_autoconf too
<seb128> that's wrong
<sivang> seb128: ok, I will fix that, or have you done so already?
<seb128> I'll do, don't bother
<sivang> seb128: k, I'll keep this in mind the -applets patch as well, thanks
<seb128> np
<mpt> ogra: ping
<ogra> mpt, pong
<mpt> ogra: I was talking with fabbione last night about how to get hardware information
<mpt> to present it in the GUI
<mpt> and he suggested to ask you, since you're the hwdb guru
<ogra> in which gui ?
<mpt> The maximum CPU frequency can be extracted from the cpufreq file, but not all machines have cpufreq
<mpt> just a little python program
<ogra> and /proc/cpuinfo only shows the current speed...
<mpt> pygtk
<mpt> ... exactly
<ogra> hmm
<ogra> thats not easy... 
<mpt> and fabbione suggested a command called something like dmiprobe (I know that's not its real name, but I don't have the IRC log on this machine) which scans the memory and returns all sorts of great info, including the make and model of the computer, but it requires sudo
<ogra> dmidecode
<mpt> right, dmidecode
<ogra> yup
<mpt> Any other ideas?
<ogra> mpt, i dropped the dmidecode/hal patch for this release, since hal has access to the data itself now....
<mpt> I have the amount of RAM from free
<mpt> and the Ubuntu version from /etc/issue
<ogra> sadly it also has the acpi patches that grab the Processor device ...
<mjg59> mpt: If systems don't have cpufreq, then /proc/cpuinfo is either the full speed or it's impossible to determine the full speed
<mpt> and the kernel version from uname -r
<ogra> so the dmidecode data for cpu isnt in hal anymore
<sivang> mpt: you're hacking a user friendly system-information app?
<mpt> sivang: yeah, just an About box basically
<ogra> we could do an odd workaround and push the CPU to fullspeed for a second... but that would generat a lot of user requests
<sivang> mpt: ah nice, since hal's GUI listing is horrific for the unsuspecting newbie sole
<mjg59> ogra: Mm?
<sivang> ogra: you don't want to do that
<ogra> nope
<mjg59> ogra: As I said, cpufreq will either expose the full speed or (in the absence of cpufreq) /proc/cpuinfo gives you the best you can get
<sivang> ogra: AFAICT, XP as well lists the current CPU speed at a given time
<ogra> but then you *could* get the data from /proc/cpuinfo
<mpt> mjg59: The full speed is part of the dmidecode output
<sivang> ogra: in it's right lick menu on my computer
<mjg59> mpt: dmidecode lies
<mpt> oh.
<mjg59> You can't rely on the information in any way
<ogra> mpt, thats only the BIOS info
<mjg59> the dmidecode output is often the maximum processor speed supported by the board
<ogra> it shows 2500 Mhz for this machine.... 
<ogra> while my cpu can only do 2000
<ogra> somethin you could do is writing that info from /proc/cpuinfo anywhere on boot, before powernowd is started....
<ogra> since the CPU will most likely run fullspeed at this point
<ogra> but thats not elegant either
<sivang> isn't there an instruction to ask the CPu for it's speed?
<ogra> in pygtk ? 
<infinity> No, because the CPU speed isn't a constant.
<infinity> Hence the problem.
<mjg59> ogra: Uh. Why not just read from /sys/devices/system/cpu/*/cpufreq/ ?
<mpt> mjg59: I was told not all machines have cpufreq
<ogra> thats true
<mjg59> mpt: Right. So read from there if that exists, and read from /proc/cpuinfo if it doesn;t.
<mjg59> That's the absolute best you can do.
<infinity> mpt : Machines that dont have cpufreq info are likely to have "correct" output in cpuinfo.
<mpt> ah, good point
<mpt> if they can't change their speed, they won't have slowed down
<mjg59> If a machine doesn't have cpufreq, then they're either running at full speed or the kernel doesn't have any way of telling what speed the processor is
<Diziet> aaargh.  I _still_ hate dpatch and all its ilk.
<bddebian> heh
<mpt> ogra: That leaves the machine make/model, which I would love to include, and which dmidecode tells me ... Is there anything else that holds that info?
<mjg59> mpt: Again, that information lies
<mjg59> Though it's right in most cases
<mjg59> The only way you can get that is from the DMI data
<ogra> it is in hal too
<infinity> All comes from the same place.
<ogra> the System Board device shuld hold that data
<infinity> And it'll either be blank, be the motherboard manufacturer/model, or the computer manufacturer/model.
<infinity> So, it's usually "correct", for some value of "correct".
<ogra> yup
<ogra> its vague guessing ;)
<mpt> so what's the hal command?
<ogra> lshal
* mpt wonders why that didn't show up in "apropos hal")
<infinity> (base)adconrad@cthulhu:~$ man -k hal | grep lshal
<infinity> lshal (1)            - List devices and their properties
<infinity> Looks there to me.
<sivang> ogra: lshal | grep "linux.procfs.cpuinfo.model_name" , nice ;)
<ogra> you can grep the udi out of there and read the contentwith hal-get-property
<ogra> sivang, thats gone
<sivang> ogra: ah :-(
<ogra> sivang, its only in hoary
<sivang> ogra: yeah, I realized. Where is it now?
<ogra> i had to move it in the hwdb backend 
<sivang> ogra: why so?
<ogra> because my patch clashes with the new hal functionallity... hal has its own way to handle this stuff now
<ogra> sivang, its only /proc/cpuinfo
<ogra> no need for hal for that :)
<infinity> yeah, but /proc/cpuinfo output varies drastically from arch to arch, hal should normalise that.
<mpt> thanks ogra + sivang + infinity + mjg59
<sivang> ogra: right, useless redundency
<ogra> infinity, it dindnt... my patch only moved the data in there...
<infinity> Oh. ;)
<ogra> sivang, having it doubled in hwdb isnt cool either... the right wy is to make the patch not clash and push it upstream
<infinity> If you wrote a patch that imported the cpuinfo data and normalised it in a sane fashion, and supported, say, all of Debian's current shipping architectures (I can get you cpuinfo output for each), I'll bet upstream would think it was pretty keen.
<ogra> infinity, the prob is to get it working right with the acpi patches hal has now...
<ogra> infinity, i'm planning to have all the stuff upstream for breezy+1 ...
<ogra> at least the stuff upstream accepts
<jordi> jdub: hey, any word on lists?
<bddebian> What TZ is elmo in?
<ogra> bddebian, lodon
<ogra> london even
<bddebian> :-)
<bddebian> So he should be awake then? ;-P
<ogra> the TZ he *is* in, might not be the one he works in ;)
<bddebian> Ahh :-)
<lifeless> hes stepped oiut for a minute
<lifeless> should be back soon
<bddebian> Ah, ok, thx lifeless
<bddebian> Not that he'll talk to me anyway ;-)
<lifeless> hes back now.
<bddebian> So poke him ;-)
<TheMuso> iI/c
<bddebian> Uhm
<Diziet> I want to trace where one of the dpatches in our kernel source tree came from.  Where should I look ?
<mjg59> Diziet: In theory, the header should tell you
<ogra> and the changelog
<sivang> ogra: so let's push it upsteam, I understood sjoerd is working with us mostly
<ogra> sivang, sjoerd is debian... i mean upstream... :)
<Diziet> mjh: Hrm:
<Diziet> ## DP: Patch author: unknown
<Diziet> ## DP: Upstream status: unknown
<mjg59> Nngh.
<mjg59> Diziet: Which patch is it?
<zul> Diziet: which patch?
<Diziet> external-drivers-net_ppp-mppe-compression.dpatch
<sivang> ogra: ah, fd.o
<zul> Diziet: oh thats a fabbione patch
<Diziet> I'm investigating bugzilla 14244 in which someone wants us to apply some hack to the PPTP code.
<mjg59> Diziet: It's not obviously been submitted anywhere
<mjg59> There's a few copies of the patch floating around the web
<Diziet> Did fabbione send it upstream ?  If not, why not ?  I'm trying to find out whether the submitter's patch is any good.
<Diziet> Joy.
<ogra> this one probably:
<Diziet> Do we have any idea whether it's any good or not ?
<ogra>   * Added mppe support (unknown):
<ogra>     . drivers/net/Kconfig
<ogra>     . drivers/net/Makefile
<ogra>     . drivers/net/arcfour.c
<ogra>     . drivers/net/arcfour.h
<mjg59> The openwrt people seem to use it
<ogra>     . drivers/net/ppp_generic.c
<ogra>     . drivers/net/ppp_mppe_compress.c
<ogra>     . drivers/net/sha1.c
<Diziet> ogra: Indeed.
<ogra>     . drivers/net/sha1.h
<ogra>     . include/linux/ppp-comp.h
<ogra> linux-source-2.6.8.1 (2.6.8.1-1) 
<ogra>  Herbert Xu <herbert@gondor.apana.org.au>  Sat, 21 Aug 2004 
<mjg59> Hrm. Dates back to 2.4.21 at least
<ogra> thats the changelopg entry
<Diziet> I found some stuff on the pptpclient sf pages claiming that their stuff had been included in some 2.6.12 rc.
<Diziet> Really, I just wanted to make sure I wasn't wasting my time here.
<Diziet> If no-one else knows much about this then I'll keep digging.
<Lathiat> hrm.. shouldnt gstreamer default to autoaudiosink now?
<bddebian> camilotelles: I apologies but every time I see your nick, I think of cameltoe.. :-)
<Kamion> Riddell: thanks, build running
<camilotelles__> bddebian: i'm not so pretty than a cameltoe.
<bddebian> camilotelles: :-)
<bddebian> Heya slomo
<sivang> jdub: ping
<\sh> grmpf..planet is stupid
<\sh> just restarted my webserver and now it pulls all the old stuff in *grr*
<pitti_live> moin
<\sh> abend pitti :)
<bddebian> Hello pitti_live
<HiddenWolf> Guys, I've installed both xscreensaver and gnome-screensaver at the moment, but neither works. How can I debug this?
<HiddenWolf> Where should I look?
<pitti_live> doko: no PostgreSQL backend for ooo-base? :-/
<shackan> does anyone know what keeps chmj busy offline today ?
<pitti> mdz: just tested the current amd64/live; at shutdown, I got thrown into console 1 and the output was frozen; I did not see any init.d messages and could not switch consoles; CD was ejected, though. Known bug?
<bddebian> pitti: Did you ever answer ajmitch about libpgtcl?
<pitti> no, I don't think so - ajmitch?
<sabdfl> pitti: ipod shuffle is not working for me
<sabdfl> on breezy
<pitti> ajmitch: anyway, I have to leave now, can you please mail me?
<pitti> sabdfl: hm, still the "hotplug goes insane" bug?
<bddebian> pitti: Is there a replacement for libpgtcl?
<sabdfl> let me know what you want, and i'll send you the debug output
<pitti> sabdfl: https://wiki.ubuntu.com/DebuggingRemovableDevices has some proven steps for debugging
<doko> pitti: via odbc-postgresql or libpg-java
<pitti> doko: hum, ok
<pitti> bddebian: not right now; upstream does not ship it as part of postgresql any more, so somebody needs to package it
<bddebian> Ack, OK
<pitti> sorry guys, really have to go now. Please mail me
<bddebian> Later pitti, thx
<pitti> sabdfl: let's hope it's something trivial :-)
<pitti> ok, cu
<Kamion> Riddell: new Kubuntu daily up; you're still a bit oversized on amd64 and i386, but only by about 9MB
<sladen> Kamion: are these still being built to be rsyncable?
<Kamion> sladen: yes
<Kamion> the install CDs were always rsyncable anyway
<jackobill> #ubuntu-motu
<desrt> seb128; thanks for the customary hyperactive uploading of 2.12 :)
* desrt groovin' with the badger and lovin' it :p
<seb128> desrt: thank you :)
<pef> elmo: hi, can you please sync openmsx from Debian ? current breezy version does not compile, latest Debian version does
<desrt> pef; #ubuntu-motu
<pef> desrt: elmo isn't there ;)
<desrt> if he's mataining universe, he should be :P
<bd-mud> pef: Did you add it to MOTUToSync wiki page?
<pef> bd-mud: no, but I will :) thanks
<desrt> bd-mud; ah.  much better advice :)
<elmo> no, it's really not
<elmo> guys, I don't know where this MOTUToSync page idea came from, but it's not something I'm paying any attention
<elmo> canonical way to get stuff synced is still IRC, if I'm around, email if I'm not
<Kamion> desrt: elmo isn't maintaining universe in the sense most people mean when they talk about MOTU
<frans-th> what is MOTUTosync?
<Kamion> if there's nobody on #ubuntu-motu who has the technical power to sync packages, then asking there is rather silly
<ogra> elmo, we dont expect at all that you pay attention to MOTUToSync... we just need a place where we hold the requests... its only our clipboard
<elmo> ogra: ok
<elmo> but if anyone comes up to me after release and says "why didn't you sync blah?? it was on MOTUToSync!!!" I'm going to point and laugh at them.  at best.
<mjg59> elmo: Can you sync hotkey-setup, or is that something that needs to go via mdz now?
<elmo> mjg59: any changes to main need mdz/kamion approval at this stage
<pef> http://dev.erodia.net/ubuntu/MOTUGLUTransition/openmsx_0.5.2-4ubuntu-1.debdiff can someone can explain me why debdiff changes the last changelog entry instead of adding a new one ?
<mjg59> elmo: Ok, no problem
<Kamion> pef: debdiff doesn't change anything; it just reports the differences
<ivoks> pef: ubuntu-1 version?
* ivoks has fetish on versioning
<pef> ivoks: yes , no right ?
<Kamion> pef: it's not a problem though; you started with 0.5.2-4 from Debian, which doesn't (and shouldn't) include 0.5.2-1build1 in Ubuntu. Just leave that out.
<Kamion> pef: should be 0.5.2-4ubuntu1
<Kamion> otherwise bad things happen with the packaging toolchain (it'll look for 0.5.2-4ubuntu.orig.tar.gz)
<pef> Kamion: that's what I have on my changelog :/
<Kamion> pef: well fix it
<pef> Kamion: directly into the debdiff file ?
<Kamion> no! why would you do that?
<mjg59> Kamion: Can hotkey-setup be approved? Difference is that it loads the Sony hotkey module on devices that need it (otherwise hotkeys don't work on them)
<ivoks> no
<Kamion> pef: change the source package and rebuild
<ivoks> pef: sources have pgp signatures
<pef> Kamion: dpkg-buildpackage -S -sa ?
<Kamion> pef: whatever you did to build the package before
<pef> ok, certainly a stupid error of me :)
<Kamion> debdiffs are reports of what changed; you must never change them directly and expect the original source to change as well by magic
<pef> Kamion: I never done this ;)
<Kamion> it's what you asked if you could do, though. :-)
<Kamion> mjg59: yes, diff looks fine
<bd-mud> elmo: Well is there any chance you could take a quick look at MOTUToSync rather than me listing 5 or 6 packages here now?
<mjg59> Kamion: Do I need mdz as well, or just you?
<Kamion> bd-mud: listing the packages here is what everybody else does
<Kamion> mjg59: just me
<Kamion> [pid 22025]  chown32("/dev/tty0", 0, 0)  = 0
<Kamion> [pid 22025]  chown32("/dev/tty7", 0, 0)  = 0
<Kamion> hmm
<Kamion> is X meant to do that?
<mjg59> elmo: kamion approves hotkey-setup sync
<bd-mud> Kamion: I'm not opposed, it just seems like a lot for elmo to digest in an active irc channel
<Kamion> bd-mud: it's the procedure elmo explicitly asked people to follow
<HiddenWolf> seb128: ping
<seb128> HiddenWolf: pong
<bd-mud> Kamion: OK, fair enough
<HiddenWolf> seb128, are you aware of a metacity bug whenever some application sends a popup?
<seb128> HiddenWolf: the one fixed with the upload from some hours ago?
<HiddenWolf> one sec, I'll upgrade
<seb128> k
<HiddenWolf> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<HiddenWolf> Not fixed.
<HiddenWolf> unless I'd need a reboot
<seb128> have you restarted your session?
<HiddenWolf> I'll try.
<bd-mud> elmo: Can you please sync shaketracker 0.4.6-5 from Debian unstable, fixes gcc4 build issues?
<bd-mud> elmo: Can you please sync regina-normal 0.4.6-5 from Debian unstable, fixes build issues? Pretty please :-)
<frans-th> hi all, is it possible mc become part of ubuntu CD...
<Kamion> frans-th: it doesn't seem suitable for the CD, but you can install it from the network
<bd-mud> elmo: Can you please sync libccscript 
<bd-mud> 2.5.7-5 from Debian unstable , on MOM list to merge but can be synced? Pretty please :-)
<frans-th> Kemion: i got it from universe, :P
<Riddell> Kamion: if my calculations are correct that should be the kubuntu seeds down to size now
<Kamion> frans-th: indeed
<frans-th> Kemion: better is it installed by default.
<HiddenWolf> seb128, sorry to bug you, fixed.
<seb128> HiddenWolf: np
<Kamion> frans-th: there are many things which might be nice installed by default, and they're all fighting for space; you need to provide a very strong rationale
<HiddenWolf> I had filed one on gaim earlier, Only now figured out it was more wide than that. I'll close it.
<Kamion> we don't have 2MB spare for things which a few people might use
<frans-th> Kamion: thx :) i just want to know more how the ubuntu development work...
<mvo> Kamion: permission to uplaod the apt cront.daily changes to fix #14504 ?
<Kamion> mvo: yes, please
<seb128> HiddenWolf: bug number?
<mvo> Kamion: thanks
<Kamion> Riddell: ok, I'll launch a build once the current one's finished
<bd-mud> elmo: Can you please sync qm 2.3-1 from Debian testing or unstable.  Fixes Malone bug #380. 
<HiddenWolf> seb128, never mind, you duplicated it earlier. closed.
<seb128> HiddenWolf: all right
<HiddenWolf> -> marked it duplicate 
<bd-mud> elmo: Can you please sync stellarium  0.6.2-3 from Debian unstable.  Fixes gcc4 build failures. 
<elmo> [NOT Updating - Modified]  libccscript_2.5.7-1ubuntu1 (vs 2.5.7-5)
<elmo> [NOT Updating - Modified]  qm_2.2-4ubuntu1 (vs 2.3-1)
<elmo> ok to override?
<frans-th> anyone can help me to get the how to make an .iso from source...
<bd-mud> elmo: libccscript should be fine.  I'm not sure I can say for qm.
<HiddenWolf> btw, there is a missing build-depends bug in lirc which is really bugging me, but the debian maintainer isn't too active. Can one of you fix it?
<elmo> bd-mud: done except for qm then - let me know when you're sure
<bd-mud> elmo: Yes, should be fine.  Changes were to use python2.4 and now 2.3 does that.  Thank you
<HiddenWolf> seb128, btw, evolution has 2 different icons in internet and office menu's. I'd say that's not intentional?
<Diziet> Aha!  I found the upstream for that mppe patch, finally !
<bd-mud> Ack, I don't know what to do about debtags.. :-(
<elmo> bd-mud: done
<seb128> HiddenWolf: 2 different entries, 2 different icons
<HiddenWolf> seb128, ug-ly
<HiddenWolf> But I'll save you the bugreport then. ;)
<seb128> HiddenWolf: wh-y
<bd-mud> elmo: Rockin', thank you sir
<seb128> HiddenWolf: take that as 2 applications, a mailer and a groupware
<HiddenWolf> seb128, the old evo icon sucks, besides it's inconsistent: they have the same name, and I see the same window opening.
<HiddenWolf> seb128, I'd give you your piont if one defaulted to mail, and the other on the calendar tab.
<seb128> HiddenWolf: then don't have the same name
<seb128> HiddenWolf: one has "name" 
<seb128> ups
<seb128> s/name/mail/
<HiddenWolf> seb128, yes, but they still open the same window. :)
<seb128> HiddenWolf: that is a bug, one the non-mail is supposed to open the calendar or contact tab
<HiddenWolf> I'll file it then.
<seb128> don't bother, I'll fix it now
<HiddenWolf> seb128, rock
<seb128> thanks
<bd-mud> Can anyone possibly explain to me why I got successful builds of savant on the buildd but it still isn't in the archive?
<bd-mud> elmo: BTW, do yo ask the same policy for Morgue candidates?
<Treenaks> Would it be a good thing to ship with "10MB" as the default thumbnailing threashold, instead of 3MB as it is now?
<HiddenWolf> seb128, while we're at it, is it remotely possible to disable the blinking of the gnome-menu tab for certain applications? IE: xchat keeps blinking even after I awnser your message.
<Treenaks> The pictures from my Canon 350D are "around" 3MB, so some get thumbnailed, some don't
<Treenaks> I can imagine that's confusing for new people
<seb128> HiddenWolf: not that I know of, probably a xchat bug
<dholbach> Treenaks: put a patch on bugzilla - sounds good at least to me :)
<HiddenWolf> seb128, right, I'll go browsing bugzilla's
<Treenaks> dholbach: meh
<elmo> mdz/fabbione: ?
<elmo> bd-mud: yes
<elmo> pef: what's your email?
<pef> elmo: loic@dev.erodia.net
<bd-mud> elmo: Can you please look at/remove yaprimaxgui?  It is in universe but depends on pxscan from multivers which is not in the archive.
<bd-mud> elmo: Also, xezmlm depends on ezmlm which was removed from Debian quite a while ago
<bd-mud> elmo: pyxine:  Dropped in Debian. See BTS #319699
<bd-mud> elmo: python-pcgi:  Dropped in Debian. Last upload 2001, last upstream 1999.
<elmo> bd-mud: pxscan is in unstable?
<bd-mud> elmo: I can't find it anywhere in Debian.  I think yaprimaxgui may have come from apt-get.org?
<elmo> oh, nm, out of date index
<bd-mud> elmo: ?
<elmo> Origin: www.stuff.demon.co.uk-apt/source
<elmo> ^- yaprimaxgui
<bddebian> elmo: Ah, OK
<Diziet> I would like to leave a note somewhere for the next person dealing with MPPE in our kernel: should I upload a new kernel with only dpatch comments changed ?  Or do something else ?
<pef> elmo: thanks for openmsx's sync !
* bddebian hugs elmo
<lamont__> debootstrap --variant=buildd sid sid http://ftp.us.debian.org/debian
<lamont__> E: Couldn't find these debs: 11053300756
* lamont__ grumbles at mvo/kamion or whoever broke debootstrapping debian from ubuntu
<lamont__> s/from/on/
<bddebian> elmo: Could you possibly tell me why savant doesn't show up in the archive?
<elmo>  what do you mean?
<bddebian> elmo: \sh uploaded a savant change for me yesterday and the buildlogs are fine but it doesn't show in the archive.
<elmo> bddebian: version number?
<bddebian> elmo: 20031216-5ubuntu1
<elmo>     savant | 20031216-5ubuntu1 | breezy/universe | source
<elmo>      scram | 20031216-5ubuntu1 | breezy/universe | amd64, i386, ia64, powerpc
* mpt wonders if the "Pause Break" key next to his "Scroll Lock" key should be configured by default to launch workrave
<bddebian> Goddamn I am such an idiot sometimes. :-(  I was trying to install savant. Grrr.  Thanks elmo.  Sorry to waste your time.
<Diziet> I see no-one wants to answer my question.
<elmo> Diziet: don't upload a new kernel just with comments changed
<Diziet> I would just like to save someone else having to spend half of the afternoon chasing down webpages and ratholes.
<elmo> especially 48 hours before preview
<Diziet> Ah, hello.
<Diziet> OK.  What should I do instead ?
<elmo> each kernel upload is something like .5Gb (if not more) hit for our mirrors
<Kamion> Diziet: there's an arch archive for the kernel, I think; you could branch off that and ask the kernel guys to merge it
<Kamion> lamont__: I probably just haven't merged debootstrap from Debian lately
<mdz> elmo: ?
<Diziet> It's a trivial patch, just to comments in one of the dpatches to actually quote the upstream.  I had a devil of a job finding it.
<Diziet> Not worth faffing with a repo or anything - a 2-liner.
<elmo> mdz: aha; I've just switched debzilla over to the centralized debbugs mirroring - can you let me know if I boken anything?
<mdz> mjg59: what's in the new hotkey-setup?  trivial and safe?
<Kamion> lamont__: also, I suspect debootstrapping sid from sid doesn't actually work at the moment ...
<Diziet> So who are the kernel guys ?
<dholbach> Diziet: #ubuntu-kernel ?
<Kamion> mdz: I debdiffed it and approved it
<Kamion> Diziet: Ben Collins, Fabio Massimo di Nitto
<mdz> Kamion: python-numarray is a sabdfl item; need to run it by him
<Kamion> mdz: I did, he acked, I removed :)
<mdz> Kamion: good and good
* mvo is away to play hockey
<mdz> elmo: what needed changing?  pointing it to a different path?
<lamont__> Kamion: ah, ok
<elmo> mdz: no, you shouldn't need to change anything; I put compat symlinks in place
<Kamion> lamont__: I suspect that was fixed in 0.3.1.5; I'll merge after preview
<lamont__> Kamion: thanks
<Kamion> lamont__: see Debian #314858
<elmo> mdz: i.e. /srv/debzilla/db-h and /srv/debzilla/index are now symlinks pointing to /srv/bugs-mirror
<mdz> debbugs.SummaryMissing: /srv/debzilla.no-name-yet.com/debbugs/db-h/96/324796.summary
<mdz> could have been an out of sync mirror, or a corrupt bug
<mdz> that was at Date: Tue,  6 Sep 2005 18:07:31 +0100 (BST)
<Kamion> 324796.summary is there on spohr
<Kamion> looks fine
<Diziet> Aaargh.  Emacs won't let me switch to the buffer `mail to ?' because it won't let my type `?' because it thinks that means `tell me completions' !
<elmo> probably got caught in the sync; resyncing
<Diziet> C-q worked.
<mjg59> mdz: On Sonys, it loads the sonypi module
<dholbach> morning mdz
<Kamion> mjg59: we were missing the HP tablet stuff in breezy too
<mjg59> Kamion: Oh, yes
<elmo> mdz: hum, rsync from upstream still isn't picking that up
<Kamion> elmo: it's there on merkel and everything
<elmo> yeah, looks broken on bugs-mirror.d.o itself
<Kamion> -rw-rw-r--  1 debbugs debbugs 233 Sep  3 16:03 /org/bugs.debian.org/spool/db-h/96/324796.summary
<Kamion> huh?
<Kamion> looks non-broken
<mdz> mjg59: I'd rather have left that untl after preview, honestly
<spstarr_work> Is there plans for Xorg RC7.0 in breezy? 6.8.2 is kinda getting old :)
<spstarr_work> and buggy
<mjg59> mdz: Ah. Sorry about that.
<elmo> Kamion: well, ok, but I mean that size file is also present on macquarie?
<mdz> spstarr_work: breezy is in feature freeze for the 5.10 release, so no
<spstarr_work> ok
<elmo> Kamion: so I don't see how I could have boken it
<spstarr_work> whats the next release branch being called?
<spstarr_work> or its not started yet
<mdz> spstarr_work: and 7.0 isn't, well, even released yet
<lamont__> Kamion: the patch from #314858 fixes the problem. thanks
<mdz> 6.8.2 is the latest releae
<elmo> -rw-rw-r--  1 archvsync archvsync 233 Sep  3 23:03 324796.summary
<HiddenWolf> mdz, who is the nearest firefox guru?
<mdz> spstarr_work: if you have found a bug, report it to bugzillla
<spstarr_work> true, but 6.8.2 makes 2D video horrible on my r300 (radeon 9600) vs -HEAD 
<Amaranth> HiddenWolf: who touched it last?
<spstarr_work> so hopefully, we get 7.0RCX into the next development tree
<Kamion> mdz: I've spent half the day trying to narrow down anything at all about that vt switching bug, and mostly failing; the closest I've got is that if I boot live CD, ctrl-alt-f1, ctrl-alt-f7, system -> log out -> restart, then it works fine
<Amaranth> all the xorg stuff was backed out then? i thought we more or less had 7.0 except for the xserver itself
<HiddenWolf> Amaranth, no clue. I've got it generating postscript that forces my printer into a hard-reboot tho.
<Kamion> elmo: well yeah, but SummaryMissing means ENOENT
<spstarr_work> mdz: the only bug i noticed was udev broken
<spstarr_work> mdz: but this was going from debian unstable -> unbuntu breezy 
<Kamion> mdz: and I'm seeing the CD fail to eject a lot of the time as well; it seems to eject part of the way, then something goes "hang on, I need that CD" and pulls it back in again
<lamont__> Amaranth: the work of splitting up 6.8.2 into component atoms is in breezy.  what other fixes have come in may or may not be in...
<mdz> spstarr_work: given that udev is working for the rest of us, we need a bit more detail than "udev broken"
<spstarr_work> you have an old udev in breezy 
<mdz> Kamion: that's odd
<spstarr_work> mdz: 2.6.13+ broke with it badly
* Kamion -> dinner
<mdz> Kamion: it's ejected as the very last thing before shutdown
<mdz> spstarr_work: breezy uses 2.6.12
<lamont__> spstarr_work: debian unstable from anywhere newer than June 28 or so is completely random as to whether it will work or not, and is presumed to be broken,.
<spstarr_work> so i just replaced it using debian's unstable's udev and im good now
<Kamion> mdz: if I stick a /bin/sh after that in the script and run eject by hand, it works fine
<mdz> so that's not a bug if newer kernels break things
<mdz> Kamion: any luck with the console switching issue?
<lamont__> (That was when breezy started to be older than sid for many things, since we quit auto-syncing)
<spstarr_work> well i do know older version of udev broke with 2.6.11+
<lamont__> spstarr_work: OTOH, this is really a discussion for #ubuntu
<lamont__> Kamion: btw, thanks again for --resolve-deps
<lamont__> spstarr_work: that is, upgrading from a post-June-28-sid to breezy is presumed to be broken, given that downgrading is "fraught with peril"
<spstarr_work> heh
<spstarr_work> it works though
<spstarr_work> (amazingly)
<pef> have to go, bye !
<bddebian> elmo: My apologies if this is a stupid question but do you just sync the source?  In other words, I have to request an MOTU to upload?
<mdz> bddebian: yes, syncs only involve source, but the builds are automatic and do not involve MOTU
<mdz> Kamion: I've never seen it pull the CD back in, though it uses a pretty hairy method to try to pull everything into page cache before continuing
<mdz> speaking of which, I should make it use readahead one day
<bddebian> mdz: OK thanks.  Looks like it just hasn't hit the buildd yet.
<Riddell> elmo: could you install dpkg-dev on novo please
<bddebian> I assume we prefer not to sync with experimental? :-)
<slomo> bddebian: depends on the package and reason ;)
<doko> mdz: there's an upgrade conflict in OOo2, when upgrading from m113, the upgrade from hoary works as expected. I'd like to delay the fix after the preview. ok?
<mdz> doko: is it something more than a simple Replaces?
<mdz> a Replaces fix is fine for preview freeze
<doko> mdz: it's a replaces, but I've more changes in the tree at the moment
<mdz> hmm, though I suppose it would require new -amd64 etc.
<mdz> maybe better to wayit
<mdz> wait
<\sh> grmpf...
<doko> ok
<\sh> what is the correct ARCH_ define in gcc4 for amd64? ARCH_X86_64 doesn't work 
<\sh> or do i have to give it as compiler directive -D <bl>?
<elmo> Riddell: a) where?  base, chroot?  b) please mail rt@
<doko> \sh: gcc -E -dM - < /dev/null | less
<sabdfl> BenC: did you see the KLive announcement?
<\sh> doko: hmmm...amd64 or x86_64...so a #if defined(ARCH_X86_64) doesn't match?
<doko> __x86_64__, not x86_64
<doko> it doesn't match
<\sh> than their source is completly b0rked, nowonder
<\sh> fixing this beast...
<lamont__> mdz: wrt ghc6 - do we want that built with gcc-3.3 (like debian), or 3.4?
<Riddell> elmo: base
<elmo> Riddell: what do you need it in base for?
<Keybuk> ok, that's kinda interesting ... this code I wrote does exactly what it was supposed to
* Keybuk frowns
<lamont__> Keybuk: exactly what you told it to, or exactly what you meant it to?
<Keybuk> both
<Kamion> lamont__: thank aj
<Kamion> mdz: console switching> no, none
<lamont__> Kamion: ah, ok
<Keybuk> this is really worrying
<Kamion> aside from the workaround mentioned
<Kamion> but obviously that's no use for preview
<Riddell> elmo: for making package archives
<elmo> Riddell: oh, ok.. well do b) and I'll do it ;-)
<desrt> pitti; ping
<bddebian> elmo: Can you please also sync tagcoll 1.3-1 from Debian unstable?  Builds fine in pbuilder and I need it to sync/merge new debtags from Debian.
<bddebian> elmo: Unless you feel brave and want me to try 1.4 from experimental ;-)
<lamont__> Riddell: that's apt-ftparchive, part of apt-utils.
<bddebian> Hmm, wtf is up with stellarium?
<Riddell> lamont__: dpkg-scanpackages?
<lamont__> Riddell: hell yes... throw away dpkg-scanpackages
<Kamion> mdz: are casper changes post-1.8 in arch anywhere?
<Kamion> lamont__: doesn't make that much difference for small repositories
<lamont__> Kamion: well, true....  but apt-utils tends to be there, while dpkg-dev tends not to be
* lamont__ upgrades dpkg-scanpackages to "depricated"
<elmo> Riddell: yeah, added bonus, apt-utils is already installed
<elmo> Riddell: and apt-ftparchive is commandline compatible with dpkg-scan{packages,sources}
<mdz> Kamion: yes, casper--breezy-0
<mdz> Kamion: I've been slack about merging into mainline
<Kamion> oh, ok. what's the difference between mainline and breezy?
<elmo> bddebian: done
<Kamion> (semantically)
<Kamion> and it still seems not to quite match 1.11 anyway
<Nafallo> lamont: could you give back gajim?
<\sh> Mithrandir: ping
<bddebian> elmo: You ROCK no matter what they say about you. ;-P
<lamont__> Kamion: any objections if I give back all of the currently failed, which includes many things with then-uninstallable bulid-deps?
<lamont__> well, actually deps-of-build-deps
* bddebian waits to try debtags
<Kamion> lamont__: stuff in universe is fine; I think it's time to be a bit more careful with main
<lamont__> Nafallo: it was building/failed on ppc and ia64, and appears to be needs-build on the others...  I gave it back on ppc/ia64
<lamont__> Kamion: that was what I was thinking
<Nafallo> lamont: thanx
<desrt> infinity; ping
<desrt> daniels; ping
* desrt needs someone with an acpi laptop and a bit of time
<doko> Kamion, mdz: please could you approve openjade and aspell-bn for sync from unstable (see email)?
<mdz> doko: no mail here yet
<elmo> doko typoed your email
<mdz> doko: unless it's somehow preview-critical, we should wait until after preview 
<\sh> hmmm..can someone kick kxdocker? I uploaded a new upstream package and it hangs because of old package with unmet deps :(
<elmo> forwarded it
<mdz> \sh: lamont__
<mdz> Kamion: mainline casper has tollef's unionfs changes
<\sh> lamont__: please kick kxdocker with the old dep-wait from the buildd :) thx :)
<doko> elmo, mdz: yes, seen it, sent again
<doko> mdz: ok
<desrt> sabdfl; buy me a laptop :P
<sabdfl> yes, maam
<\sh> lol
<lamont__> \sh: kicked
<\sh> lamont__: thx :)
<Kamion> mdz: ah
<bddebian> elmo: Can you please also sync caudium 1.4.7-3 from Debian unstable?  BTW, I love you man :-)
<bddebian> elmo: Oh, forgot to mention it's on the MOM list but can just be synced.  Builds fine
<elmo> bddebian: are the changed merged?
<bddebian> elmo: Well the pike changes are bogus.  I don't know about the configure.ac change.
<elmo> bddebian: dude, not being funny, but if you ask me to merge something with ubuntu changes, you need to be sure to it's ok to overwrite the ubuntu changes, or you shouldn't ask for the sync
<bddebian> Well they are also pike related and the pike deps/build-deps have been updated to pike7.6
<elmo> bddebian: maybe try building the unmodified source on breezy to see if it compiles cleanly?
<bddebian> elmo: They hacked the pike version support because we didn't have it in the archive (which is why I originally couldn't complete the original merge request)
<bddebian> elmo: I did.  I never ask for a sync wihout building
<elmo> bddebian: I'm not being funny, but I don't have time to get involved in every package sync.  I'm a bottleneck.  if you're not confident it should be synced, you probably don't want to be talking to me
<bddebian> elmo: What makes me sound unconfident?
<elmo> "I don't know about the configure.ac change."
<ivoks> :)
<elmo> bddebian: ^-- that
<bddebian> elmo: Oh, sorry, I just looked.  They were for the Pike minor/major revisions
<bddebian> Now unnecessary
<elmo> bddebian: ok, done
<bddebian> elmo: Thank you.  I'm really not trying to be a PITA. :-)
* bddebian decides he better stop pushing his luck for today
<fabbione> Nafallo: ping?
<fabbione> Nafallo: you missed 3 B-D in your last mplayer upload...
<fabbione> Nafallo: libxvmc-dev, libxinerama-dev and libxxf86vm-dev
<fabbione> Nafallo: you also should consider to add --enable-xvmc as general option and not only for custom.
<fabbione> Nafallo: without the above mplayer goes banana on xineraman/multiheads setups
<desrt> fabbione; got a minute?
<desrt> s/minute/lots of minutes/
<Saba_Z> hi
<desrt> sabdfl; k. i've gone shopping & found the one i want
<bddebian> Heh
<fabbione> desrt: no sorry.. going off line in a minute
<desrt> fabbione; k
<fabbione> hi Saba_Z 
<Saba_Z> fabbione: i got your mail
<fabbione> Saba_Z: perfect!
<Saba_Z> fabbione: i found and corrected the internet sharing bug
<Saba_Z> fabbione: thanks
<fabbione> Saba_Z: cool
<fabbione> no problem
<fabbione> i really need to go offline now
<Saba_Z> fabbione: ok
<\sh> infinity: ping -> if you do the ghc6 magic, please be aware on libgmp3 which is now libgmp3c2 thx :)
<\sh> maswan: pign
<\sh> ping even
<maswan> \sh: pong
<\sh> can u install something on ravels breezy chroot?
<maswan> sure
<\sh> maswan: rock...imagemagick recode libid3-3.8.3-dev (>= 3.8.3-4.2) libflac++-dev (>= 1.1.2-1) libmad0-dev libgsl0-dev kdemultimedia-dev (>= 4:3.4.2-0) poxml
<maswan> \sh: apt-get build-dep imagemagick ok?
<\sh> maswan: I think so :) 
<maswan> \sh: if so, try now
<\sh> i only need to test kwave...and why it's not building on amd64...with all patches applied *grmpf*
<siretart> \sh: I'm sure infinity is, he arranged the source for fixed ghc6 in breezy, now it 'just' need to be bootstrapped on all archs
<siretart> \sh: I think only infinity and/or doko can do that, though..
<\sh> maswan: no the same output
<\sh> siretart: ok...thx  :)
<maswan> ah, ok. not build-dep imagemagick, kwave :)
<\sh> maswan: ah thx ;) 
<\sh> lets see what happens
<maswan> \sh: better now?
<\sh> maswan: yeah...much better :) 
<maswan> well, if you need to compile imagemagick, the build-deps are all there. ;)
<\sh> hehehe
<\sh> maswan: u don't believe ,-)
<\sh> configure: error: We need a working libXext to proceed. Since configure
<\sh> can't find it itself, we stop here assuming that make wouldn't find
<\sh> them either.
<\sh> maswan: apt-get install libxext-dev ? :)
<maswan> \sh: ii  libxext-dev    6.8.2-23
<\sh> what the hell is wrong with this package
<\sh> in pbuilder it compiles until cputest.c
<\sh> and in fakeroot dpkg-buildpackage it doesn't find libXext
<maswan> perhaps it needs a version on that libxext-dev dep?
<maswan> I'll try a dist-upgrade
<\sh> actually it needs a libxext-dev build-dep
<\sh> lets see
<\sh> wow
<\sh> pbuilder never complaint and our buildds as well
<\sh> no complaints about libxext-dev
<maswan> there, dist-ugprade done
<\sh> maswan: missing build-dep :( but in pbuilder or on the buildds no complaints...really strange behaviour
<maswan> well, if it is already in there since someitnhg else has built previously? because they don't clear the chroots between builds, right?
<\sh> maswan: but pbuilder does
<\sh> or something else was pulling it in
<\sh> maswan: but if you have time :)  can you have a look over some piece of code? /home/shermann/kwave/kwave-0.7.3/libkwave/cputest.c
<maswan> \sh: not really, sorry
<\sh> maswan: no problem :) thx anyway
<Lathiat> hmm, i just had hal fail to start on boot
<Riddell> Kamion: did you set off the new kubuntu iso build?
<slomo> elmo: do you have some time after the meeting to talk about ffmpeg?
<Kamion> Riddell: no, sorry, there was a build running at the time and then I got distracted. It's running now
* lamont__ was just informed that if you unpack all of the hoary CD + sources for same, you have over 962000 files
<mitsuhiko> ogra: ping
<pitti> hi
<pitti> Hi lamont__, got a minute?
<ogra> mitsuhiko, pong
<lamont__> pitti: we got sbuild fixed, so translations are flowing again
<lamont__> sure
<pitti> lamont__: oh, rock
<pitti> lamont__: that means your script copies tarballs to rookery again?
<lamont__> yep.  the script can now find them again, since the control file now has existant names for them...
<lamont__> script is back in cron, and I pushed things back to 20 july to make sure we didn't miss anything...
<pitti> lamont__: do you think the tarball merge can be integrated easily into your script? or shall I do it in langpack-o-matic? (but then we need another copy of the files for Rosetta import)
<pitti> lamont__: thanks, you rock :-)
<lamont__> pitti: I'd rather they got properly uploaded somewhere, but that's a discussion for a different release...
<lamont__> and I'd rather have you merge them.
<pitti> lamont__: ok, I will merge them
<pitti> lamont__: it will probably/hopefully become obsolete soon anyway, when we use launchpad
<lamont__> pitti: that is, if you pick up the files and merge them, and give rosetta the unmerged ones, all should be good, yes?
<pitti> lamont__: Rosetta needs the merged files, but I can certainly copy them to ~pitti
<bddebian> pitti: Please forgive me.  What is the replacement for libpgtcl that needs to be built from Debian?
<ogra> Kamion, could you put my preseed changes in todays edubuntu ? 
<ogra> Kamion, re mail
<lamont__> pitti: rosetta wants the superset of the unpacked tarballs, yes?
<pitti> bddebian: ISTR that there is a separate upstream project now, but I never bothered since I'm not particularly interested in tcl
<lamont__> ogra: is edubuntu going to learn about SCC architectures again post-preview?
<pitti> lamont__: Rosetta can't import per-arch tarballs, it wants the merged ones (with names as we had before, i. e. without arch suffix)
<ogra> lamont__, already enabled again
<ogra> :)
<pitti> lamont__: ok, thanks for fixing the script; I do the merging myself, no big deal
<pitti> cu tomorrow!
<lamont__> pitti: right.  but the merge method probably wants to take into account that some components might only be built on one architecture, etc.
<bddebian> pitti: Hmm, OK, it's just a build-dep for some stuff.  Later.
<Kamion> ogra: surely you still want the IP address question to be displayed, but just to have a default?
<lamont__> ogra: ah, ok... that'd be -21. thanks
<ogra> Kamion, yup
<Kamion> ogra: needs an extra line in the preseed file then - I'll add that
<ogra> Kamion, thanks :)
<lllmanulll> Hey everyone, speaking about the CDs integrity on the list, I suggested that we write on the CD download page something like "Try to burn your CD at a speed not higher than 2/3 of the maximum allowed speed"
<lllmanulll> Since I believe the rate of bad CDs comes from the fact that people just burn their CDs too fast
<lllmanulll> What do you guys think about that ?
<spayne> doko: ping
<ogra> jbailey, you got mail wrt "formal test plans"
<doko> spayne: pong
<spayne> doko: i'm just contacting you about OO.org 2 not spell checking
<spayne> doko: i've read http://bugzilla.ubuntu.com/show_bug.cgi?id=8333
<spayne> doko: and i do have myspell en gb installed and openoffice.org2 en-gb install and still no luck
<jbailey> ogra: Thanks
<mvo> ping carlos 
<spayne> doko: do you know a work-around for this bug?
<doko> language-support-en is installed?
<spayne> doko: yes
<carstenh> jbailey: ping
<jbailey> carstenh: pong
<spayne> doko: the bug on the debian bugzilla says making a symlink from /usr/share/myspell/dicts/dictionary.lst to something else
<spayne> doko: however /usr/share/myspell/dicts/dictionary.lst does not exist
<Kamion> Riddell: kubuntu build up
<spayne> doko: any ideas?
<Riddell> Kamion: groovy
<doko> spayne: ok, I see it: as a workaround, install openoffice.org (not 2)
<spayne> doko: do i have to :-( i have no need for it
<doko> you did want to know a workaround
<spayne> doko: will it be fixed soon?
<doko> yes, for the release
<spayne> doko: the final release?
<spayne> !
<spayne> doko: not before :-(
<doko> with the next upload
<spayne> doko: days? weeks?
<spayne> doko: i am impatient :-)
<doko> time to learn to be patient ;)
<mvo> Kamion: permission to upload synaptic with http://paste.ubuntulinux.nl/1972? (rosetta does not like two pot files in the same dir apparently)
<mdz> Kamion: I just tried to reproduce the gdm livecd vt switch problem under strace and it worked
<dmk> spayne, the bug say make a symlink to /etc/openoffice/dictionary.lst
<spayne> from what?
<dmk> from /usr/lib/openoffice2/share/dict/ooo
<dmk> on my box only /usr/lib/openoffice2/share/dict existed
<dmk> had to manually create ooo
<dmk> it now works
<ogra> mdz, did you fintd time to look at my ltsp dhcp restart patch ? 
<mdz> ogra: no
<dmk> sorry the other way round
<dmk> ie sudo ln -s /etc/openoffice/dictionary.lst /usr/lib/openoffice2/share/dict/ooo/dictionary.lst
<spayne> thanks dmk
<spayne> dmk: you are my hero :-)
<dmk> spayne, it was in the debian bug. i didn't notice the ooo bit at first
<spayne> i must has missed it
<spayne> thanks
<mdz> Kamion: then I tried again without strace or any other console switching, and it still works
<mdz> so I am unable to reproduce it now
<dmk> spayne, are you getting any suggestions when you miss-spell a word?
<spayne> yep
<dmk> I get the words highlighted but no suggestions - must have broke something on the way
<siretart> elmo: could you please approve me in launchpad for ubuntumembers?
<ivoks> elmo: sorry, i didn't mean any harm
<siretart> or Kamion, you perhaps?
<robitaille> elmo:  is there a way in LP to change where a @ubuntu.com address points to? 
<elmo> robitaille: changed your preferred email in LP
<robitaille> elmo, I guess there is a cron job?  It didn't work immediatelly;  but what if you want your prefered address in LP to be your ubuntu address?
<papyrus2> Hi
<papyrus2> is there a special Url to make bugreport for breezy liveCD  colony 4 ?
<siretart> papyrus2: http://bugzilla.ubuntu.com/enter_bug.cgi I'd say
<papyrus2> just test
<papyrus2> and crashes when modprobe for audio card module
<papyrus2> :(
<papyrus2> because chipset audio 915 using hdaintel
<papyrus2> dunno know if I going to do the upgrade :)
<dholbach> good night everybody
<siretart> papyrus2: look in bugzilla if there is already a bug filed about this
<siretart> papyrus2: if not, file one ;)
<papyrus2> yep
<crimsun> papyrus2: colony 4 does what when you modprobe snd_hda_intel?
<papyrus2> yep
<crimsun> what does it do?
<papyrus2> crashes with backtrace
<papyrus2> and I can do anything 
<crimsun> ok, let me know the bugzilla #
<papyrus2> same with booting live acpi=off :(
<papyrus2> ok
<crimsun> I'll need the lspci -v |grep -i audio information and some additional information from /proc/asound once we have your model #
<crimsun> and the backtrace, preferably ksymoops-formatted
<papyrus2> crimsun : can't provide the backtrace
<papyrus2> all freeze
<papyrus2> ctrl+c didn't answer
<papyrus2> I have to shutdown manually
<papyrus2> is there another way to have the backtrace ?
<crimsun> yes, it's painstaking, but you have to copy it down by hand
<papyrus2> huh ?
<crimsun> then paste it into the ksymoops utility
<papyrus2> it's huge !
<papyrus2> huh ????
<crimsun> yep, welcome to debugging sound drivers
<papyrus2> ok I will do it 
<papyrus2> np
<papyrus2> => proc/asound/cards is enough ?
<papyrus2> or do I have to provide everything on /proc/asound/cardO ?
<papyrus2> card0
<crimsun> for now, just the lspci -v |grep -i audio and the ksymoops
<papyrus2> ok
<papyrus2> something strange
<papyrus2> grep
<crimsun> this is probably better moved to #alsa
<papyrus2> works but lspci -v | grep -i audio
<papyrus2> grep : command not found :)
<papyrus2> ok
<elmo> robitaille: yah, it's in a cron job
<ivoks> bye all
<mdz> Kamion: hmm, still happens on amd64
<mdz> Kamion: notably, usplash timed out on amd64 and not on i386
<cyprinus> did anyone make an upgrade from hoary to colony 4?
#ubuntu-devel 2006-09-04
<ne78> mjg59: i disable offscreen pixmaps manually, but still doesn't work here (with the debian xserver-xorg), it would be great if what you say is true, it would mean that debian could have a working compiz now
<ne78> mjg59: what about the patches from (1:1.1.1-0ubuntu5) 7 Aug 2006 17:21:05 -0300 ?
<mjg59> What about them?
<mjg59> I still don't know what problem you're having
<ne78> mjg59: i think it works because of them
<ne78> mjg59: it's nice to see that ubuntu is more up to date than debian sid
<zul> hey keybuk
<ne78> Keybuk: are you the upstart developper ?
<Keybuk> zul: heyhey
<Keybuk> ne78: yeah
<Riddell> Burgundavia: pong
<Burgundavia> Riddell: I was going to ask you about SoC stuff, but I found what I needed
<ne78> Keybuk: it's great project, i've been following the init replacements lately init-ng,launchd etc.., upstart seem to be really the way to go
<mjg59> ne78: No, it works without them
<ne78> Keybuk: did you noticed that the html mailman archive display some mail in base64 format on lists.netsplit.com ?
<Keybuk> ne78: yeah, no idea why *shrug* mailman bug I guess
<ne78> mjg59: if you say so. So what is needed plain xorg 7.1, what version of mesa is needed ?
<mjg59> Whichever version of mesa is needed for the swrast code to build
<mjg59> Probably recentish CVS, though 6.5.1 might be enough
<ne78> mjg59: thanks for the info, i'll retry tommorow to see if it can be done with the current packages of debian sid
<kristog> Keybuk: did you see #52922
<Keybuk> bug #52922
<Ubugtu> Malone bug 52922 in network-manager "libnm-util0 for network-manager on ppc does not work with wpa passphrases" [Untriaged,Confirmed]  http://launchpad.net/bugs/52922
<Keybuk> no, I didn't see that bug
<Keybuk> but I'm aware of it
<Keybuk> I've heard dups, and I'm sure we patched it *shrug*
<kristog> Keybuk: no idea, didn't look in the ubuntu patches i've attached the debian patch
<kristog> witch will fix it, don't use the upstream one reported in the bug since it's useless
<Keybuk> ok, well, the bug looks fine
<kristog> which*
<kristog> (cool i wrote witch../me should not study macbeth at 00.42)
<Keybuk> heh
<Keybuk> bug #58769
<Ubugtu> Malone bug 58769 in network-manager "Gateway is never saved (edgy knot 2)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58769
<Seveas> mjg59, ping
<mjg59> Seveas: Hi
<Burgundavia> is there a good wiki page talking about how to test dapper-proposed ?
<Seveas> mjg59, I don't know whether you've seen my mail from thursday, but I have some usplash patches for you (the things in that mail are implemented)
<mjg59> Seveas: Ok, cool
<mjg59> I've been a bit busy this weekend, I'm afraid - at a wedding
<Seveas> heh, that's much better than usplash hacking ;)
<Seveas> all is in a branch on launchpad, every feature committed separately
<Seveas> let me know if something needs fixing 
<mjg59> Ok
<Seveas> The only thing really missing is ppc support, I still don't have one of those and the apple store wouldn't let me use one for testing ;)
<gnomefreak> jdub: ping
<zakame> hello
<Keybuk> hello
<zakame> hi Keybuk :)
<jdong> there's mr broke-my-hal :)
<jdong> j/k
<zakame> lol, /me suddenly reminded of shallow hal
<zakame> eerie, just watched that yesterday
<Keybuk> jdong: still don't understand that one
<Keybuk> at least we know what broke it
<Keybuk> I just don't understand why that would break it
<jdong> yeah, it still confuses the heck out of me, too
<jdong> I'd like to do a bit more testing to confirm that's the culprit
* jdong installs upstart on his fresh coreduo install
<jdong> brb :)
<jdong> Keybuk: you might be cleared of blame... I can't cause it to happen on my system now
<jdong> the only difference between now and an hour ago were those few updates that landed in apt
<jdong> hmm
* jdong utterly confused
<jdong> the only possibly related update would be dbus 0.92-1ubuntu2
<jdong> but the changelog entry is not too promising
<slomo> jdong: nothing that could cause breakage changed there
<jdong> slomo: I know :-/
<jdong> I seriously did nothing more than dist-upgrade, then apply the events.d change Keybuk suggested, and rebooted
<jdong> maybe the 2nd reboot is the charm :D
<slomo> what change was this? :)
<slomo> i ask because i wanted to reboot with upstart now ;)
<jdong> slomo: are you experiencing any dbus trouble?
<slomo> nope
<jdong> lucky you :)
<slomo> which evil things does dbus do to you? ;)
<jdong> slomo: bug 58165
<Ubugtu> Malone bug 58165 in upstart "security policy error with hald after latest updates" [Untriaged,Confirmed]  http://launchpad.net/bugs/58165
<jdong> the event.d thing is in there too
<jdong> you can read my rapid rambling :)
<jdong> it certainly doesn't happen without the help of upstart
<jdong> but right now I can't reproduce it on my latest edgy box
<slomo> hm, i'll see what happens after reboot :)
<slomo> brb
<jdong> same here
<jdong> brb
<bddebian> Howdy
<jdong> well, it magically works now
<Burgundavia> https://lists.ubuntu.com/archives/ubuntu-news/2006-September/000052.html
<slomo> Keybuk: upstart is a bit unusable with initscripts that require user input ;)
<Keybuk> jdong: you have "console output" in the event.d file?
<Keybuk> slomo: I want to know how those were usable with usplash <g>
<jdong> Keybuk: no, not on this box :-/
<Keybuk> jdong: and it's all working happily?
<jdong> yeah... :-/
<Keybuk> heh
<slomo> Keybuk: the initscript disabled usplash at the time it required input :P do you have any idea how this could be worked around with upstart? :)
<Keybuk> what did apt update (/var/log/dpkg.log?)
<jdong> Keybuk: I'm completely confused right now... when I get back home I'll try to straighten this one out
<Keybuk> slomo: ah, we could grep for those and make them upstart jobs for edgy?
<jdub> Burgundavia: thought -> why don't you guys use w3m/links to render the web page to text, so your text-only email looks nicer (and without all the moinisms)?
<jdong> Keybuk: avahi, beagle, dbus
<Burgundavia> jdub: never really considered it. I need to do some thinking about general process tomorrow, so I will add that to the list
<slomo> Keybuk: the only one i know about is cryptsetup... shall i file a bug about it and subscribe you?
<Keybuk> slomo: I believe there is one for cryptsetup?
<Burgundavia> jdub: do you have a link about that? is this how dwn does it?
<jdong> Keybuk: hmm, you think avahi could've been screwing with dbus?
<Burgundavia> jdub: another idea would be not to send out the text at all, merely a link to the moin page, ala Fedora
<Keybuk> jdong: no, I think it's dbus
<jdub> Burgundavia: not a link, but man w3m/links/lynx/html2text etc will help
<jdub> Burgundavia: also, you could send u-n as both html and text
<Burgundavia> another idea
<Keybuk> jdong: what version of dbus did you have before?
<Keybuk> can you 'grep "upgrade dbus" /var/log/dpkg.log' for me ?
<slomo> Keybuk: i can't find a bug... not on upstart and not on cryptsetup
<jdong> keybuk:  upgrade dbus 0.92-1ubuntu1 0.92-1ubuntu2
<Keybuk> jdong: the changelog isn't revealing, I agree
<Keybuk> what happens if you downgrade it to 1ubuntu1 again
<Keybuk> does it break?
* jdong tries
<Keybuk> slomo: ah, Thom mailed the mail list
<Keybuk> slomo: file a bug (on the ubuntu source) and I'll forward thom's mail to the bug too
<slomo> Keybuk: on cryptsetup or upstart?
<Keybuk> slomo: ooh, good question ... let's say cryptsetup and upstart :p
<Keybuk> so file it on cryptsetup, and add upstart too
<slomo> hehe ok :)
<jdong> Keybuk: no, it doesn't break :-/
<slomo> jdong: try rebooting... you still have the old, "new" dbus daemon
<Keybuk> jdong: did you try a reboot?
<jdong> no, but I restarted dbus :)
<jdong> but fine, I'll reboot
<slomo> Keybuk: https://launchpad.net/distros/ubuntu/+source/cryptsetup/+bug/58794
<Ubugtu> Malone bug 58794 in upstart "doesn't deal with init scripts that require user input" [Untriaged,Unconfirmed]  
<jdong> still no breakage
<Keybuk> jdong: hmm
<Keybuk> what else got updated in that run (looking at dpkg.log)
<jdong> as I said, a bunch of avahi, beagle, and dbus
<Keybuk> also check "last reboot", had you rebooted in a while?
<jdong> yeah
<jdong> it was a few minutes prior to the dist-upgrade
<jdong> avahi's gonna be a beast to downgrade, not in the mood for it tonight
<jdong> I'll play with this one more tomorrow
<Keybuk> heh
* Keybuk blames slomo
<jdong> :)
<pitti> Good morning ladies and gentlemen, aliens, pets, bots, and artificial intelligences!
<imbrandon> moins pitti
<pitti> hi imbrandon 
* mvo grumbles about epiphany 
* pitti hugs Hobbsee 
<Hobbsee> hey pitti!
* Hobbsee hugs pitti in return
<Hobbsee> pitti: i have a request
<pitti> Hobbsee: go ahead
<Hobbsee> pitti: the request sync script - can we get it to comply more with the current policy?
<pitti> Hobbsee: which is?
<pitti> Hobbsee: (sure, I'm happy to adapt it)
<Hobbsee> pitti: about having to have the ubuntu changes in there, etc.  and having to list the component of debian that it's in.
<Hobbsee> pitti: there's a mail message on ubuntu-devel about the new policy
<Hobbsee> pitti: TheMuso helped me get it working for a smtp server :) so i can use it!
<zyga> pitti: hi, do language packs use bz2 on purpose (when creating debian packages)
<pitti> Hobbsee: ubuntu changes as a diff?
<pitti> Hobbsee: (sorry, I just returned from vac, my mail backlog is horrible)
<pitti> zyga: yes
<Hobbsee> pitti: yeah, fair enough.  i'll try to find the mail for you on the archives, if you like
<pitti> would be nice
<Hobbsee> pitti: how were the holidays?
<pitti> Hobbsee: I do not think it's a good idea to attach a diff; they are potentially huuuge due to PO mangling etc.
* Mithrandir tickles Hobbsee 
* Hobbsee tickles Mithrandir in return, and stomps on his feet
<pitti> Hobbsee: nice and relaxing; canooing, bicycling, tenting, staying in fresh air all the time :)
* Mithrandir is already levitating and watches Hobbsee stomp the ground instead.
<Hobbsee> hah
<Hobbsee> pitti: surely not!  you mean you went...outside?  and...survived????
<pitti> surprisingly, yes :)
* mvo googles "fresh air"
* pitti blows away the smoke from the bear gun
<Hobbsee> mvo: hehe
<pitti> mvo: it's that ugly smell when you open a window
<Hobbsee> gah.  it's on u-d-a
<Hobbsee> meaning i will *not* find it on u-d
<Hobbsee> pitti: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-August/000181.html
<pitti> Hobbsee: ok, obviously I cannot automatically generate such a description
<pitti> Hobbsee: a description of each of the Ubuntu changes (a bullet point list
<pitti>       is fine, but copies of debian/changelog aren't)
<Hobbsee> pitti: true.  even the ubuntu changelog entries would help, i guess.
<Hobbsee> true that
* pitti considers this a bit silly, though
<Hobbsee> pitti: it wouldnt be a full replacement, as it was before, but it would be a help, i suspect
<pitti> we will have lots of unnecessary work during the 'merge from Debian' phase
<pitti> Hobbsee: for now I'll just add the Debian component
<Hobbsee> pitti: yeah, exactly.  if i've done something wrong, which is quite possible considering the number of syncs i requested, i want to know what i got wrong, and why, not "lets punish everyone because a few people made a mistake"
<pitti> Hobbsee: the Ubuntu changes should be added as a followup comment
<pitti> so that the script can work fully automatically
<Hobbsee> pitti: yes
<Hobbsee> hey, yeah, that would be cool
<Keybuk> pitti: I don't agree that there will be unnecessary work
<Keybuk> during the merge from Debian phase, you've just worked out what the changes are
<Hobbsee> "summarise the damned changes here"
<Keybuk> as you've just decided that they can be dropped
<Hobbsee> Keybuk: to write them out is painful
<Keybuk> it's not 5s of work to quickly type them
<pitti> Keybuk: ok, depends on the level of details you expect :)
<Keybuk> pitti: bare minimum detail
<Keybuk> a few words, or a line at most, per change
<pitti> Keybuk: if it's 'PO file changes, all patches adopted', then it's easy
<Keybuk> just enough to acknowledge that the requestor has actually read the damned diff
<pitti> ok
<Keybuk> which a frightening number of people weren't doing
<Hobbsee> Keybuk: really?
<Keybuk> some people actually had "ok to override ubuntu changes" in their sync request template!!
<Hobbsee> Keybuk: was i one of those people?
<pitti> Keybuk: well, requestsync adds this by default
* pitti points out that he wrote that script entirely for his own use initially
<Hobbsee> of course, by definition, the changes would be okay to overwrite, otherwise they wouldnt be using the request sync script.
<pitti> Keybuk: I guess I'll take out this stanza then
<Keybuk> I've seen many mails from you without that line
<Keybuk> Hobbsee: HA HA HA HA HA HA
<Hobbsee> Keybuk: theoretically, anyway
<Hobbsee> :P
<pitti> Keybuk: well, if there are no Ubuntu changes, this line won't be there of course
<Keybuk> Hobbsee: that's what we wanted to prove :p
<Keybuk> basically it got to the point where Colin and I were hand-checking every sync request for sanity
<Hobbsee> Keybuk: you cant really prohibit people's stupidity
<Keybuk> which is too much work for us
<Hobbsee> true that
<pitti> Keybuk: ok, I take out that line, since the description requires a followup comment anyway
<Hobbsee> Keybuk: were the dodgy ones from particular people, or was that everyone?
<Keybuk> Hobbsee: sadly the dodgy ones came from just about everybody
<Hobbsee> Keybuk: ahhhh.  mind telling me which of mine i did wrong then, rather than just "some of them"?
<Keybuk> no idea
<Hobbsee> heh.  yes, me neither.  it seems that's where the problem is :P
<Keybuk> I don't keep that kind of thing in my memory
<Keybuk> I would have mentioned it at the time
<Hobbsee> Keybuk: of course.  i'm more wondering if it was...
<Hobbsee> oh yeah, i remember a few now.  damned wrong versioning
* Hobbsee still gets caught with that, at times.
<Keybuk> we all make mistakes
<Hobbsee> true that
* Hobbsee makes a note to actually learn the content before the next maths test, to avoid said mistakes
<Keybuk> the change wasn't about blame
<Keybuk> it was to try and speed up the sync queue again
<Hobbsee> true that
<Hobbsee> wasnt meaning that it was the brain
<Hobbsee> warning:  Hobbsee has had about 6 hours of class straight, ending in a maths test.  brain is slightly fried.
<Keybuk> heh
<Kagou> hi
<Keybuk> heh
<Keybuk> looks like someone wiped the Planet Debian cache database
* Hobbsee wonders if dbus has still broken everything.  or if it's only everything containing a nvidia card.
<Keybuk> Hobbsee: "broken everything"?
<Hobbsee> Keybuk: well, broken gdm/kdm
<Hobbsee> gnomefreak: mentioned it earlier
<Hobbsee> but has a nvidia card, so that's likely the thing to blame.
<Keybuk> ah, I have another "probably dbus" bug
<Hobbsee> i decided that i didnt want to troubleshoot it in 20 mins, at uni, on batteries.
<imbrandon> Hobbsee: well not /all/ nvidia cards as i'm running latest dbus / kdm / nvida ( nv not binary )
<Hobbsee> imbrandon: oh good
<Mithrandir> I don't really see how dbus could break on one class of graphics cards?
<Hobbsee> Mithrandir: i dont either.  
<imbrandon> i'm thinking gnomefreak was having issues with the binary nvidia drivers and not dbus but i was afk and only read the logs
* Hobbsee upgrades
<imbrandon> moins Mithrandir
<Hobbsee> Mithrandir: so how did you perfect the skill of levitating, by the way?
<Hobbsee> Mithrandir: if i ever make it to a conference, i want to see it in person :P
* imbrandon gets smore more mtdew^Wcoffee and starts the daily email checks
<Mithrandir> Hobbsee: I could tell you, but then I'd have to kill you, and since I like you, I won't.
<imbrandon> hahaha
<Hobbsee> Mithrandir: haha.  right.
<Mithrandir> 'morning, imbrandon 
<Hobbsee> Mithrandir: i'd like to see you try to kill me, if you're on another continent
* Hobbsee is unlikable.
<Mithrandir> Hobbsee: I like three-eyed aliens! :-P
<imbrandon> unkillable ?
<Mithrandir> Hobbsee: also, ICBMs.
<imbrandon> haha
<Hobbsee> ICBM?
<Mithrandir> intercontinental ballistic missiles
<imbrandon> inter cont blastic missle
<Hobbsee> Mithrandir: hehe, right
<Hobbsee> Mithrandir: ahhhhh.....
<Hobbsee> imbrandon: no unlikable.  i'm a psycopathic bitch, after all :P
<imbrandon> ah lol
<imbrandon> icmb , think long pointy stick with a grenade on the end ;)
<Hobbsee> mmm...fun...
<imbrandon> icbm*
* Mithrandir twiddles his thumbs while this workstation upgrades to edgy.
* Hobbsee drops some icecubes down Mithrandir's back to distract him
* imbrandon twidles along with Mithrandir as squashfs squishes the fs ...
<Mithrandir> Hobbsee: eyh!  Here I'm just recovering from a cold and you try to kill me?
<Hobbsee> Mithrandir: now, if i were trying to kill you, then surely i'd be using a ICBM for such a thing.  not just mere icecubes.
<Keybuk> icecubes don't work on Tollef
<Keybuk> they're warm compared to where he comes from
* Hobbsee sticks them down Keybuk's back instead.
<Hobbsee> dont make me find something else...
<Mithrandir> Keybuk: that's why you southerners keep complaining about the heat each time you visit? :-P
<Hobbsee> Mithrandir: their just wusses
<Hobbsee> :P
<Hobbsee> Mithrandir: perhaps one of the next conferences needs to be on the equator or something.  they'd get used to it pretty quick :P
<Mithrandir> Hobbsee: well, equator gives you humidity as well.  Here, we're more in the "make it hot, but not humid" way of doing things.
<imbrandon> *cough* Kansas City *cough*
<Hobbsee> Mithrandir: ahhh...nice.  remind me to move up there someday.
<Mithrandir> imbrandon: Kansas moved to the equator now?
<imbrandon> heheh no but it would be cool to have one in the middle of the US ( not to mention i live here ) hehe
<imbrandon> brb 
<Hobbsee> hehe
<Keybuk> Mithrandir: I seem to remember having to climb snow drifts last time I visited
<Hobbsee> "oh no, it's moving countries again!"
<Mithrandir> Keybuk: oh, true, but that was in winter.  And it wasn't cold.  Just snowy.
<Mithrandir> (which means it's wet. :-/)
<Keybuk> imbrandon: rumour has it that the next will be in SF
<Keybuk> Mithrandir: it was cold for me
<Mithrandir> Keybuk: you live in a country which freezes and panics when you get 2cm of snow on the roads.
<Keybuk> Mithrandir: a fair point
<dcode> imbrandon: I support a middle US con too
<dcode> I'm from StL
<dcode> but in KC all the time
<Keybuk> imbrandon: well known for its international hub airport? :p
<imbrandon> Keybuk: yea it ( we ) have a huge intl airport 
<imbrandon> KCI ( kansas city intl airport hehe )
<imbrandon> and its dead smak in the middle of the US
<imbrandon> dcode: yea i'm in STL all the time too, I have some family there about 45 min outside east stl
<dcode> I'm actually currently going to school in Rolla
<dcode> but my family is from just south of St. Louis
<imbrandon> cool
<imbrandon> Keybuk: but SF would be cool too ;)
<Keybuk> imbrandon: confs tend to be held in places convenient for not just us to get to, but any particular group we're aiming to be involved
<Hobbsee> oh fun.   there is a rumoured location now
<imbrandon> true ;)
<Keybuk> or placed back-to-back with other conferences, etc.
<imbrandon> umm but Keybuk whats in SF heh ?
<Keybuk> imbrandon: most tech companies?
<imbrandon> ahh true alot are there
<imbrandon> well close to there
* Hobbsee is jealous.
<imbrandon> welp i'll be at the next one , even if i dont manage to get sponsored ( as long as its in the US , travel wont be terrible expensive )
<imbrandon> plus if its in SF my wifes family is close, two birsd with one stone , i can "drop her off" hehe
<imbrandon> birds*
<Keybuk> Hobbsee: jealous of?
<Hobbsee> Keybuk: you all going off to a conference
* jdub tries to decide between dell d420 and ibm x60
<pradeeper> Hi guys, I need some bit information about Ubuntu remastering.... I know that you guys are busy but if somebody can tell me where I can get some help on remastering stuff... that's a great help!
<imbrandon> heya jdub, for ?
<Hobbsee> jdub: what's the d420 retailing for?
<imbrandon> pradeeper: https://help.ubuntu.com/community/LiveCDCustomization/6.06
<Mithrandir> jdub: thinkpad > * :-)
<jdub> Hobbsee: just under $3000 with my customisations
<imbrandon> wow
<Hobbsee> jdub: wow.
* imbrandon sticks to his apple lappy(s)
* Hobbsee wonders about the customisations, for that price
<Keybuk> Hobbsee: it happens several times a year :-/
<jdub> but you can get one for AUD$2398
<Hobbsee> Keybuk: heh.  so you have to go, and dont like it.  that'd be right.
<Mithrandir> imbrandon: apples don't have three mouse buttons.
<jdub> apples are also not ultraportable
<imbrandon> Mithrandir: mine does ( just any old usb mouse )
<Mithrandir> imbrandon: external mice are a pain, imo.
<imbrandon> jdub: well my 14in ibook isnt too bad to lug arround
<imbrandon> Mithrandir: true i done use them but it is an option ;)
<imbrandon> dont*
<Mithrandir> pitti: do you have any thoughts on dropping the -ppds as we did for -desktop just before knot-2?
<Mithrandir> imbrandon: I prefer machines with a proper number of mouse buttons built-in.
<imbrandon> Mithrandir: hehe maybe so but apples are just so slick imho for lappys ( i dont like the desktops much ) but all my laptops are apple
<pitti> Mithrandir: I saw the change, but I cannot really comment on it; if it works (i. e. foomatic has the matching backend for dynamic PPD generation), so much the better :)
<pitti> Mithrandir: dynamic PPDs were one of 1.2's major new features, so it seems appropriate to make use of it
<Mithrandir> pitti: it worked in one out of one of my tests.
<pradeeper> thanks imbrandon, I have done some work based on that... but I need more information, for example, I notice that ~ubuntu users is created on the fly when booting the Ubuntu liveCD. if I want to change some settings on ubuntu user then how can I do that?
<pitti> Mithrandir: 'Ubuntu achieves 100% success rate in printing tests'
<Mithrandir> pitti: it also looks like cupsys-common needs a versioned replaces on cupsys; I got file overlap problems when upgrading from dapper now.
<Mithrandir> pitti: do you want to handle that or should I?
<pitti> Mithrandir: I'll test it a bit as well, but Malone will find it out soon enough :)
<pitti> Mithrandir: I'll do it in Debian's and Ubuntu's svn branches
<Mithrandir> pitti: thanks, that saves me filing a bug. :-)
<imbrandon> pradeeper: thats covered on the bottom of that howto , also you can check with the guys at nUbuntu ( they do alot of custom stuff with the livecd )
<pitti> Mithrandir: it already has Conflicts: cupsys (<< 1.2.1-4); same version for R:, I guess
<Mithrandir> pitti: sounds sane, yes.
<pradeeper> thanks imbrandon, let me check on that
<pradeeper> btw, what is nUbuntu?
<imbrandon> an unoffical spinoff
<imbrandon> www.nubuntu.org i think , dont know terribly much about them 
<pradeeper> oh!
<pradeeper> well... nubuntu.org is not working for me :(
<imbrandon> s/.org/.com/g
* imbrandon is afk a bit bbiab
<jdub> looks like the dell wins - has touchpad and clit (not jsut the clit like the ibm), and the mediabase has a dvi port (ibm one doesn't)
<jdub> plus i will probably never get over the position of esc and fn on the ibm ;-)
<mvo> jdub: it has only a 1.8" hdd IIRC though (the ibm has a 2.5")
<jdub> mvo: yeah, that's a bit of a bummer
<jdub> are there any other laptops / docks that have dvi?
<Keybuk> the lack of a touchpad on the Lenovo is what continually prevents me from buying one
<mvo> when I tested the x60 I was unhappy with the hdd though, it kept vibrating under my right palm (not very strong, but constant)
<mvo> but maybe I got a monday model or something
<jdub> i was very surprised at the price of hp laptops
<jdub> $$$!
<neuralis> yeah, it's unfortunate. they're excellent little machines, though.
<Hobbsee> jdub: good or bad?
<jdub> high
<Hobbsee> ah
<Keybuk> neuralis: are they?
<Keybuk> I'm totally unimpressed by my nc4010
<Keybuk> I hope the newer HPs are better
<jdub> $2800 for the D420 + mediabase and a few other bits
<neuralis> Keybuk: i had a nc4010, didn't like it all that much, moved to nc4200, quite happy with it
<jdub> $3000 with 1GB ram, but cheaper if i buy elsewhere
<Keybuk> it's the build quality I'm most upset with
<Keybuk> this thing just hasn't lasted
<neuralis> Keybuk: the 4200 strikes me as much better built, but i haven't used the 4010 for long enough to give you a definitive opinion
<zyg1> jdub: that's a hell lot of money for a laptop
<Keybuk> neuralis: how long have you had the 4200?
<G0SUB> pitti: hello
<pitti> Hi G0SUB 
<neuralis> Keybuk: lemme look
<G0SUB> pitti: PM?
<jdub> zyg1: i don't buy el-cheapo laptops
<Keybuk> neuralis: have you had any problems with the battery life on it?
<pitti> Mithrandir: fixed cupsys in both places, Ubuntu uploaded
<pitti> Mithrandir: thanks for spotting this
<jdub> plus it's australian pesos
<pitti> G0SUB: sure
<neuralis> Keybuk: had it about a year, no battery problems at all yet
<zyg1> jdub: what is el-cheapo? 1.5K for a portable is already alot, but 3K ?!?
<zyg1> you can always buy identical laptop for half 3 months later
<Keybuk> neuralis: this one'
<Keybuk> neuralis: this one's charger has stopped working properly ... it incorrectly reports battery charges, and doesn't fully charge them, etc.
<Keybuk> and won't charge through the travel adapter at all
<neuralis> eep
<neuralis> i think that's a one-off problem; a friend of mine inherited my 4010, and has had no battery problems with it
<jdub> zyg1: where do i find a 12" ultraportable for $1.5K?
<Keybuk> neuralis: I'd believe that, except a friend's different HP model has had exactly the same set of problems I've had with this
<lifeless> jdub: samsung ?
<neuralis> Keybuk: maybe my 4010 is a one-off working one..
<jdub> lifeless: they don't have a comparable laptop
<lifeless> no ? crap
<lifeless> malcc has a q10+ which is nice
<maswan> jdub: I think toshiba just introduced one that had a bit better resolution, and good battery time, at a low weight
<slomo> Keybuk: postrm of upstart is broken it seems... at least from -2 to -3
<Hobbsee> maswan: the trouble with toshibas is that some models like overheating.
<zyg1> jdub: you could try 13" macbook (not so ultraportable but close)
<maswan> Hobbsee: Ah, that doesn't sound fun.
<jdub> zyg1: very heavy, still not that cheap
<Keybuk> slomo: oh, broken how?
<Hobbsee> maswan: oh, and the fans run most of the time, which makes them distracting
<maswan> What about the smallest fujitsus?
<Mithrandir> Apple don't have any sub-2kg machines, do they?
<maswan> Hobbsee: ack
<zyg1> jdub: heavy ack but it's 1K$, about 1.1K with tons of ram from other vendor
<zyg1> Mithrandir: not anymore
<jdub> maswan: ah - didn't think of those, good point. wonder if any have dvi.
<Mithrandir> zyg1: hmm?  Even the 12" powerbook was 2kg, wasn't it?
<zyg1> Mithrandir: 12" ibook was less AFAIR but I may be wrong
<slomo> Keybuk: without any output from the script it said that the old returned with error code 2 and then tries the new one... and fails because of "exec format error"
<Mithrandir> zyg1: nope, 12" white ibook was 2.1 or 2.2.
<jdub> zyg1: a macbook doesn't suit the requirement, and is $2000 anyway
<maswan> jdub: no clue, I think I ruled them out due to no trackpoint
<Keybuk> err
<zyg1> jdub: 2000? huh? mb is 1000$ 
<zyg1> jdub: unless you want black one :P
<jdub> zyg1: note that i've mentioned AUD numerous times
<maswan> jdub: I haven't really looked at notebooks seriously since back when I got my x40 though, and I think I'll get another year out of that
<zyg1> Mithrandir: I'm pretty sure one of the first models was sub 2KG
<zyg1> AUD?
<jdub> australian dollars
<Mithrandir> maswan: yeah, same with me.. going to look at x70 or x80 when that comes out, though.
<zyg1> ahh
<zyg1> jdub: then 3000 AUD is not so scary ;-)
<maswan> Mithrandir: I just hope that they finally get clued in on sticking a 1400x1050 on those without adding extra weight.
<Keybuk> slomo: oh, meh, postrm is buggy -- add #!/bin/sh -e to the top :p
<Mithrandir> maswan: I'm guessing they'd rather go for 1280x800 or thereabouts.
<slomo> Keybuk: oh... i better go back to sleep :) i didn't notice that it was missing although i looked at the file ;)
<maswan> Mithrandir: Sure, but I'd prefer my version. :)
<Keybuk> slomo: is just that file, so explains why it didn't show up in my upgrade test
<Mithrandir> maswan: I think they won't be able to do the "without adding extra weight" bit, though.
<maswan> Mithrandir: Possibly. I guess I probably will have to compromise, I was aiming for twice the number of pixels, half the weight, twice the battery life. It seems like I can perhaps get 1-2 out of those.
<Mithrandir> maswan: two out of three isn't that bad.
<Keybuk> slomo: fix uploaded
<Keybuk> right, nap time
<maswan> Mithrandir: Yeah, as long as the others are at "not (significantly) worse" at least
<maswan> Mithrandir: Btw, the reason I mentioned the toshiba is that it seemed to be about 50% better in all three. So now I just wait for one more year for them to get twice as good. ;)
<Mithrandir> maswan: I've heard the toshiba build quality isn't that great.
<Mithrandir> maswan: that's the thing I really, really love about my thinkpad.  It can take on all the abuse I throw at it.
<jdub> Mithrandir: even the fn/esc abuse? :)
<jdub> doesn't look like fujitsu wins
<Fujitsu> Not me, I hope :P
<jdub> Fujitsu: are you ultraportable? do you have a DVI output? :)
<Fujitsu> Sure...
* Fujitsu tries to fit a DVI connector somewhere.
<Fujitsu> Hm.
<maswan> Mithrandir: Yeah, mine too. Well, the battery is getting old, so I need to either replace that or the laptop in a year or so.
<ivoks> pitti: wb :)
<pitti> ivoks: thanks
<Mithrandir> maswan: I've pondered switching to my 6-cell by default, but then, I don't use my battery that much _anyway_, so I'm saving that for travel, I think.
<maswan> Mithrandir: I just want a larger screen on it, without sacrificing the other parts (too much)
<dholbach> good morning
<zyg1> dholbach: morning
<maswan> Mithrandir: Oh, I only have one battery. And it is down to half according to acpi.
<zyg1> dholbach: are we initerested in FOSS fonts that replace times new roman?
<dholbach> zyg1: it's best to write to ubuntu-devel@ about that
<dholbach> zyg1: but sounds interesting (i'm no expert)
<Mithrandir> maswan: my 4-cell has begun acting weirdly and doesn't report charge correctly any more.  Not that I really care since I have the other one too.
<jdub> we are interested in destroying the last vestiges of times new roman
<maswan> Mithrandir: but then, I'm nto very surprised, since it has been on almost constantly since I got it
<Mithrandir> maswan: mine too.  I've taken to suspending it at night now, though
<zyg1> jdub: I don't understand?
<jdub> zyg1: times new roman is a plague on taste and typography
<maswan> Mithrandir: I've been thinking of that, but it's annoying to restore all those ssh sessions.
<Mithrandir> jdub: it's nice if you're the New York Times and need to put as much text on each page as possible.
<Mithrandir> maswan: heh, true, but then, I don't have a zillion open all the time; I rather open new ones as I go.
<jdub> Mithrandir: new york times doesn't use times new roman!
<jdub> Mithrandir: it uses imperial
<maswan> Mithrandir: I'm quite used to having sessions open in a couple of places, home workstation and movie player up in the leftmost corner, etc, etc
<zyg1> jdub: it's used by websites though :/
<Mithrandir> jdub: it used to, though.  Or rather, it used to use times.
<jdub> Mithrandir: 'times' doesn't refer to the nyt, it refers to 'the times' (uk newspaper) :-)
<Mithrandir> jdub: hmm, I was fairly sure it was designed for the NYT, ICBW however.
<pitti> Hobbsee: requestsync script updated
<Mithrandir> and I don't have any books of typography here which would support my claim or not.
<Hobbsee> pitti: woo!
<Hobbsee> pitti: thanks!
<pitti> np, only trivial changes
<jdub> Mithrandir: nyt used all kinds of stupid shit, 'times' is much older
<jdub> "
<jdub> "Science: Steve Irwin Dead
<jdub> " pure slashdot comedy
<imbrandon> jdub: nah its true , news.com.au has a story on it too
<imbrandon> afaik
<StevenK> And Channel Nine for that matter.
<jdub> ...
<jdub> "science"
<jdub> nutballs
<imbrandon> oh
* imbrandon missed that 
<slomo> fabbione: ping?
<tepsipakki> how come there aren't new meeting logs on the wiki since late July?
<slomo> infinity: could you please kill the mono build on sparc? it got a SIGILL and just stalled instead of failing :(
<Fujitsu> Great!
<Fujitsu> Sounds like fun.
<seb128> "Failed to fetch http://archive.ubuntu.com/ubuntu/dists/edgy/universe/binary-i386/Packages.bz2  MD5Sum mismatch
<seb128> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/edgy/main/source/Sources.bz2  MD5Sum mismatch"
<seb128> is that known?
<infinity> slomo: It's already over that.
<slomo> infinity: oh ok...
* slomo files a bug upstream
<dholbach> hellas ogra!
<dholbach> ogra: new gnome-power-manager for you
<zyg1> why the hell does objcopy use over 500MB of ram after some app crashes/is killed?
<pitti> zyg1: if you have a huge app crashing (with a huge coredump), apport uses objcopy to shrink the coredump size
<zyg1> pitti: the app didn't use even quater of that 
<zyg1> I killed objcopy and kernel barfed :/
<zyg1> kernel oops
<pitti> zyga: do you have a record of the oops?
<pitti> zyga: could be a bug in the crash dump helper
<zyg1> hm, how do I file a bug on the kernel again?
<zyg1> https://launchpad.net/distros/ubuntu/edgy/+package/linux-image-2.6.17-6-686 # 'bugs' link  is not active
<Fujitsu> File it on linux-source-2.6.17
<zyg1> thanks
<sivang> morning
<Burgundavia> morning sivang
<sivang> Burgundavia: hey corey, how are you ?
<Burgundavia> not bad
<Burgundavia> got UWN 12 out, realized my mistakes
<Burgundavia> got my inbox under 500 for the first time in 4 weeks
<Mocka> Hello
<Mocka> My name is Kid Rock.
<Mocka> How are you all today?
<sivang> Burgundavia: nice
<Mocka> sivang do you work on ubuntu?
<sivang> Burgundavia: if you want to see some of the new GUI for hubackup, there's a bzr branch I'm working on
<Burgundavia> ok, cool
<Burgundavia> can't honestly say I willb e able to find time
<sivang> Mocka: I contribute yes, but I am not employee if that what you're asking.
<Burgundavia> but I will try
<Mocka> ok i cant decide what distro to use
<sivang> Burgundavia: okay, cool :-) just FYI sort of thing, I recalled you were asking me about it progress during the last cycle
<sivang> Mocka: This is more of a user oriented question, I'm sure in #ubuntu there will be a lot of people that can help this dilemma 
<Burgundavia> Mocka: we might be slighly biased in here ;)
<sivang> Mocka: and what Burgundavia just said :-)
<Mocka> Ubuntu is very new...
<Burgundavia> well, that was interesting
<Burgundavia> hey heno
<heno> Burgundavia: hey!
<sivang> hey heno , 'sup?
<heno> hey sivang 
<carlos> Riddell, pitti: ping
<pitti> carlos: pong
<carlos> Riddell, pitti: https://launchpad.net/bugs/58526
<Ubugtu> Malone bug 58526 in rosetta "Missing upstream translations for koffice in edgy" [Untriaged,Unconfirmed]  
<carlos> we need to find a final solution for that problem....
<pitti> carlos: is it a real problem that koffice-i18n is in main? if so, let's just promote it
<carlos> I did the manual import with Dapper because was too late to implement something, but I don't think it would scale...
<Burgundavia> carlos: one thing to be careful with "final solution" is an engilsh term for the holocaust and is thus not used very much
<pitti> oh, it's koffice-l10n now
<carlos> pitti: I think the main problem was just that the packages would be empty
<pitti> right
<pitti> I don't know whether we can have the source in main, and all the debs in universe
<carlos> Burgundavia: I see, 'nice' term....
<pitti> but it should work somehow
<carlos> pitti: yeah. Please, tell me if that's not possible so we think on other ways to fix it
<carlos> pitti: should I assign you that bug?
<pitti> carlos: oh, let's promote it
<carlos> well, to get translations in Rosetta we need a new upload...
<carlos> Riddell: could you do it?
<pitti> carlos: I don't have that power, though, please subscribe ubuntu-archive
<pitti> carlos: oh, I can do a no-change upload after the promotion, of course
<carlos> pitti: that's good enough
* pitti wonders what happened to wiki.u.c. - am I the only one who cannot connect to it?
<Burgundavia> pitti: it was up for me just a second ago
<carlos> pitti: I don't need any notification, the files will be handled by Rosetta directly, what I mean is that if is not possible to have the source in main and all binaries in universe, just tell me it to find another solution ;-)
<pitti> carlos: right, but I think having the source in main is the cleanest one
<carlos> pitti: me too
<pitti> carlos: anastacia will complain, but we can ignore that
<carlos> ok
<Kamion> um
<Kamion> I'm not really happy with something we have to permanently ignore
<Kamion> it's ok for now, but I want to be able to get anastacia empty for edgy
<pitti> Kamion: can we promote just koffice-i18n-en to main and leave the rest in universe?
<Kamion> sure, with some suitable comment in the seeds
<pitti> erm, -en doesn't exist, but any other language
<pitti> -engb
<pitti> Kamion: ok, I'll put it into supported then
<Kamion> ok, want me to promote that now?
<pitti> Kamion: that would be nice
<Kamion> done, will be visible after the next publisher run as usual
<pitti> ok, I do the seed change and the rebuild
<carlos> Kamion, pitti: thanks guyes
<carlos> guys
<pitti> Connection error: Unable to connect to SSH host bazaar.launchpad.net:None:
<pitti> grrr
<pitti> I can't access the wiki, nor bazaar.l.n
<carlos> pitti, Kamion: Same problem with k3b-i18n
<carlos> https://launchpad.net/bugs/58556
<Ubugtu> Malone bug 58556 in rosetta "New upstream translations of k3b not imported to Rosetta" [Untriaged,Unconfirmed]  
<pitti> meh
<Kamion> k3b-i18n only has one binary package
<Kamion> (so it's easier, I guess)
<pitti> well, it would be another useless and empty package in main
<pitti> but we can live with that, I guess
<doko> pitti, Riddell: kdegraphics contains a copy of xpdf?
<pitti> Kamion: ok, I'll seed/rebuild it as well (once I can connect again)
<pitti> doko: yes, but we ported it to poppler at the last conf
<Kamion> pitti: I've promoted it
<pitti> doko: i. e. the copy is not used any more
<pitti> Kamion: thanks
<Kamion> ok, ubiquity makes a lot more sense when I turn it *this* way up
<Riddell> doko: it does but it's nt used
<doko> ahh, ok
<carlos> pitti: I just remembered that we took no action for those packages because we were supposed to import universe for Edgy...
<carlos> pitti, Kamion: Thanks for the fast action
<heno> dholbach: ping
<dholbach> heno: pong
<heno> dholbach: Hi! Can you help with getting this into universe? https://launchpad.net/people/onboard/+branch/onboard/main
<heno> ?
<dholbach> heno: i'll make a note
<dholbach> heno: today and tomorrow is gnome 2.16 - so i'll be busy
<heno> I assume it needs to go there before it can go in main
<dholbach> heno: i'll try to shove it in at some time in between
<heno> dholbach: right
<heno> dholbach: or if you know of any MOTUs with spare time that would work too :)
<dholbach> #ubuntu-motu :-)
<dholbach> maybe Luke?
<heno> I tried #u-motu already, but I'll try again :)
<heno> Despite all my prodding Luke has not yet applied to become a motu AFAIK
<heno> It's already packaged, just needs review and upload
* heno gives #u-motu another go
* ogra wonders if he did something wrong ... thats the first time the gnome-power-manager patches all applied straight away ...
<pitti> Riddell: ok, k3b-i18n and koffice-i18n-engb are now promoted and seeded; do you have the current packages on disk to do a quick no-change upload?
<fabbione> slomo: pong?
<pitti> hey fabbione!
<slomo> fabbione: seems like we have a problem with mono on sparc :(
<slomo> fabbione: http://bugzilla.ximian.com/show_bug.cgi?id=79270
<Ubugtu> Ximian bug 79270 in JIT "SIGILL on Linux/sparc" [Unknown,New]  
<fabbione> hey pitti 
<fabbione> slomo: i am in vacation... will be back next monday
<fabbione> slomo: also.. davem is not around now
<slomo> fabbione: oh ok, didn't know this. shall i write him a mail or will you care for everything after you're back from vacation?
<fabbione> slomo: either you write us a mail or remind me once i am back
<slomo> fabbione: ok, i'll remind you on monday... enjoy your free week :)
<Riddell> pitti: why koffice-i18n-engb?
<pitti> Riddell: well, it's as good as any other language :)
<fabbione> slomo: thanks :)
<pitti> Riddell: we just need an 'excuse' to keep the source in main
<pitti> Riddell: without anastacia bitching
<Kamion> Riddell: (germinate doesn't understand keeping one source in main without any binaries)
<pitti> Riddell: and I thought that English speaking people will least likely search for translation packages
<Riddell> pitti: fair enough, I'll upload
<pitti> Riddell: thanks; both packages?
<Riddell> pitti: yep
<pitti> great
<Riddell> what's incharge of making nsswitch.conf again?  it needs to have mdns4 in it for avahi
<Mithrandir> : tfheen@xoog ~ > dpkg -S /etc/nsswitch.conf
<Mithrandir> base-files: /etc/nsswitch.conf
<slomo> Riddell: base-files... but read the debian bugreports about why it was removed again before please
<doko> Kamion: are syncs from testing to dapper-proposed possible?
<Kamion> doko: I don't think so, sorry - sync-source doesn't understand pockets (-proposed)
<geser> whom to talk to get a fix in dapper-updates?
<pitti> geser: primarily, the bug tracker
<pitti> geser: then, asking here is fine
<geser> it is bug 58564
<Ubugtu> Malone bug 58564 in php4-yaz "php4-yaz won't install (broken dependency)" [Untriaged,Confirmed]  http://launchpad.net/bugs/58564
<geser> could someone review the fix and upload it to dapper-updates?
<pitti> geser: I added a dapper task
<pitti> geser: for the review/fix, can you please ask in #ubuntu-motu or just assign the bug to MOTU?
<geser> will do, thanks
<pitti> doko: cdbs uploaded
<dholbach> ogra: you rock
<doko> pitti: thanks
<ogra> dholbach, thanks for the reminder :)
<dholbach> ogra: anytime :)
<Lathiat> Riddell: libnss-mdns
<Kamion> sladen: I don't think you need to explain to the Soyuz team what sync-source is ... :-)
<Kamion> though thanks for the bug
<Mithrandir> pitti: how can I get to the debug symbols from our builds?
<pitti> Mithrandir: not yet, unfortunately
<pitti> Mithrandir: ATM, the ddebs are just thrown away; infinity and I have a plan to store them
<Mithrandir> pitti: so the embedded core dumps aren't very useful yet?
<pitti> Mithrandir: right, not terribly much ATM
<seb128> pitti: could you move the dump after the plain text informations, so one don't need to wait on its browser to load it to read the backtrace? ;)
<ajmitch> Kamion: ping
<Kamion> ajmitch: hi
<ajmitch> Kamion: just wanting to get a UVF exception for f-spot 0.2.0
<ajmitch> which is in sid now
<Kamion> ajmitch: could you mail the upstream NEWS entries (or changelog if that doesn't exist) and the Debian changelog entries to cjwatson@ubuntu.com and mdz@ubuntu.com?
<ajmitch> will do
<Kamion> thanks
<ajmitch> sent, hopefully it gets through (have been having mail problems)
<slomo> pitti: would it be possible to let apport recognize which mono applications was used instead of making each application bug a mono bug? :) i would assume that there is the same problem for python
* ajmitch wishes apport could capture a good mono backtrace as well
<slomo> yes, most of the time the output of the application is more useful than the apport information :(
<Mithrandir> mvo: gnome-app-install still seems to be missing its dependency on python-gdbm
<_ion> Great, a new f-spot. I really hope it is accepted.
<tseng> of course it will be
<tseng> as the old one doesnt work, and its one of our edgy talking points
<pitti> seb128: I can certainly do that, yes
* Hobbsee waves to all
* seb128 hugs pitti
<pitti> slomo: let me think about it
<slomo> pitti: we need apport plugins :)
<pitti> slomo: specs appreciated :)
<pitti> slomo: can you please file an apport bug with the essential bits of the report?
<slomo> pitti: sure
<pitti> slomo: i. e. everything but the core?
<pitti> slomo: (or just point to another bug which has a report)
<pitti> slomo: I have to do some other stuff and I don't want to forget about this
<slomo> pitti: bug #58859
<Ubugtu> Malone bug 58859 in apport "Better support for mono programs needed" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58859
<pitti> slomo: thanks
<pitti> slomo: indeed, we need some kind of hook
<pitti> slomo: something that maps a re pattern to an additional probe
<pitti> slomo: but that smells like edgy+1
<pitti> slomo: we already had that special case for ubiquity (python)
<jono> anyone here know about adding a feed to planet ubuntu? I am getting errors :(
<pitti> it should be fairly interesting to generalize this
<zyg1> jono: any more information?
<slomo> jono: ask jdub... afaik he cares for the planet
<slomo> pitti: and it would prevent unnecessary work of re-assigning the bugs to the correct packages ;) we already had many bug reports like the f-spot one
<jono> zyg1, yeah I am running bzr checkout sftp://jonobacon@bazaar.launchpad.net/~planet-ubuntu/config/main planet-ubuntu but getting:
<jdub> not anymore, it's bzr maintained
<jono> bzr: ERROR: Not a branch: sftp://jonobacon@bazaar.launchpad.net/%7Eplanet-ubuntu/config/main/
<ajmitch> jono: got python-paramiko?
<pitti> slomo: oh, the 'wrong package' bug is important, we'll figure something out
<jono> ajmitch, yep
<pitti> slomo: I meant the 'additional probes for python/mono specific stack traces'
<pitti> slomo: particular packages might have particular additional information they are interested in
<slomo> pitti: ah ok :) yes, that would only be a bonus ;)
<pitti> slomo: e. g. we could do a per-package hook and then call all hooks from the dependency chain
<pitti> slomo: but that's edgy+1
<slomo> pitti: btw, why are there still some apport reports that don't contain any stacktrace at all?
<jono> hmmm
<mvo> Mithrandir: I wil have a look
<pitti> slomo: if the process' cwd is not writable for the process
<pitti> slomo: BenC and I discussed an alternative kernel behaviour which would rectify this
<pitti> slomo: e. g. notification-daemon does chdir('/'), and many daemons o
<pitti> s/o$/do/
<slomo> pitti: ok... because without a stacktrace it is really useless most of the time :/
<pitti> slomo: thus they cannot dump core
<slomo> pitti: i don't think it's possible to get everything the application printed to stderr/stdout?
<pitti> slomo: there is no stdout/stderr in the kernel crashdump helper
<slomo> pitti: often it would be useful to see the last few lines that were printed by the application before it exploded :/
<Kamion> jono: you need to be a member of the planet-ubuntu team (for most people, that's indirectly achieved by being in ubuntumembers)
<pitti> slomo: dreamer! :)
<pitti> slomo: yeah, we totally need that 'look back into history' apport plugin
<jono> Kamion, right, how do I get added ?
<Kamion> jono: https://wiki.ubuntu.com/CommunityCouncilAgenda
<slomo> pitti: how could this theoretically work? where is the output so we can get it after a crash happend? :)
<jono> thanks Kamion 
<pitti> slomo: from the process' perspective it was sent out to a file descriptor and is irrevocably lost
<pitti> slomo: you could ask all running shells and terminals to save their scrollback buffer :)
<slomo> evil
<Hobbsee> pitti: looks good, thanks.  pity it didtn pick up the debian changelog on krename though
<pitti> Hobbsee: you have to wait a bit until changelogs.d.n. catches up
<pitti> (a day)
<Hobbsee> pitti: ah okay...
<Hobbsee>   File "/usr/lib/python2.4/smtplib.py", line 306, in connect
<Hobbsee>     raise socket.error, msg
<Hobbsee> socket.error: (111, 'Connection refused')
<Hobbsee> gah.  i had that working before.
<pitti> Hobbsee: a local MTA is love, my darling
<Hobbsee> pitti: i've never been able to figure it out enough to get it to behave.
<pitti> Hobbsee: if you have a version that talks to ubuntu's smtp server, I'll happily adopt that, of course :)
<Hobbsee> pitti: TheMuso helped me fix it so that it was talking to my mail.bigpond.com server.
<Hobbsee> pitti: got it :)
<Hobbsee> pitti: what was the problem of getting it to talk to ubuntu's smtp server?
<pitti> Hobbsee: I never bothered :)
<pitti> Hobbsee: all my boxes have a nicely configured local MTA
<Hobbsee> pitti: what should the address be?
<Hobbsee> pitti: and do you need to authenticate, etc, for it?
<Hobbsee> (gmail is not a nice smtp server to try to authenticate too)
<Hobbsee> -o
<pitti> Hobbsee: no idea
<Hobbsee> pitti: hmm okay.  didnt even know ubuntu had a smtp server.
<pitti> ~$ dig MX launchpad.net|grep 10
<pitti> launchpad.net.          10783   IN      MX      10 fiordland.ubuntu.com.
<pitti> Hobbsee: I guess you don't need auth for @ubuntu targeted domains, and it won't relay other mail anyway
<pitti> Hobbsee: just try it out :)
<Hobbsee> pitti: trying now.  didtn come back with an error message, but we'll see if it hits the bugtracker.
<Hobbsee> pitti: woo!  it works!
* pitti hugs Hobbsee 
* Hobbsee hugs pitti 
<Hobbsee> pitti: http://rafb.net/paste/results/ZwAnme83.html
<pitti> Hobbsee: so the only change is stating the SMTP server in s = smtplib.SMTP() ?
<Hobbsee> pitti: and deleting a line, yeah
<pitti> Hobbsee: deleting?
<Hobbsee> pitti: s.connect() and s.connect() change to being s.quit()
<Hobbsee> ie, the last section is:
<Hobbsee> s = smtplib.SMTP('fiordland.ubuntu.com')
<Hobbsee> s.sendmail(myemailaddr, to, mail)
<Hobbsee> s.quit()
<Hobbsee> that's the only change
<pitti> Hobbsee: you mean 's.close()' change to 's.quit()'?
<pitti> Hobbsee: and the s.connect() can be dropped? strange
<Hobbsee> yep
<Hobbsee> pitti: TheMuso fiddled with that section, and got it working.  he gets the credit
* Hobbsee just tried changing the smtp server.
<pitti> Hobbsee: ok, I'll test that here as well
<pitti> Hobbsee: if it works, I'll put that into the official script
<Hobbsee> pitti: :D
<pitti> Hobbsee: thanks!
<Hobbsee> pitti: not a problem :)
<Hobbsee> pitti: now i can request scripts with that from uni too!
<Kamion> Mithrandir: so, regarding bug 50319, I don't really see a problem with just doing user creation before running target-config hooks
<Kamion> I think we should probably do locales, user, target-config, everything else
<Kamion> Mithrandir: testing this now ...
<Hobbsee> pitti: you're not an archive admin, are you?
<pitti> Hobbsee: no, I'm not
<pitti> Hobbsee: look at my badges :)
<Hobbsee> pitti: hehe.  i might have to.
* Hobbsee was just looking for someone to poke libgii/libggi thru NEW
<Kamion> I did libgii earlier
<Mithrandir> Kamion: sounds like a good idea
<Hobbsee> seeing as i've got a few packages sitting here that depend on the new version
<Hobbsee> Kamion: excellent, thanks :)
<Kamion> libggi isn't in NEW
<Hobbsee> libgii then.
<Hobbsee> yes, they're playing silly buggers with the naming.
<Kamion> was just a soname bump basically
<hikenboot> greetings--been trying to remove none-essential packages from the live cd...it appears that package ubuntu-live installs office...is this also required package in order to get the live cd to work as an installer or to run from cdrom?
<Hobbsee> Kamion: that's the one.
<Kamion> hikenboot: "office"? (no such package)
<Hobbsee> gah
* Hobbsee goes to look more
<hikenboot> open-office
<hikenboot> and language packs
<Kamion> hikenboot: no
<hikenboot> what i found was that i removed some package...list of about 40 of them that caused it to no longer have the run from live cd feature..I am trying to figure out which package caused this
<Kamion> that would be ubiquity*
<Kamion> if you mean install from live CD
<hikenboot> yes thats what i mean
<hikenboot> the ones i removed also caused gnome-system-monitor gnome-volume-manager gparted hal-device-manager gnome-netstatus-applet python2.4.-gnome-extras python-uno to be removed..are any of these packages critical?
<hikenboot> i would think hal-device-manager would be critical
<pitti> hikenboot: no, h-d-m is harmless
<hikenboot> not sure about the python thgoh
<ogra> g-v-m might be something you want though
<thom> gparted you probably want
<Kamion> hikenboot: gparted is required for ubiquity
<hikenboot> thanks in that case i will just restore x-window-system-core, xbase-clients, gparted, gnome-volume-manager
<hikenboot> thanks for your help guys...I am creating the cd now..we will see if it runs ok
<hikenboot> ah one problem..i removed the packages but did not purge them...is there some directory I should empty or should I start over?
<Kamion> just either reinstall them or use dpkg --purge, depending on the desired result
<hikenboot> ah reinstall them then purge them the right way or dpkg --purge the packages to purge just the packages..thanks
<jdong> so, has anyone ever tried installing ubuntu to a dvd+rw before?
<hikenboot> jdong I heard they are working on making ubuntu so that it will run from a rw dvd and actually save settings on the dvd...is that what you mean?
<Kamion> Mithrandir: mind if I change casper to use sudo instead of su? su's argument handling has changed and was always pretty suboptimal for arguments containing spaces anyway
<jdong> hikenboot: no, more like mkfs.ext2 /dev/scd0; then rsync my ubuntu install onto it :)
<hikenboot> oh ...sorry I was going to give you a link to that project I was refering too
<jdong> hikenboot: I'm just being reckless here :)
<Kamion> Mithrandir: this is working, so I'm just going to commit it; feel free to shout if you object, obviously ...
<Mithrandir> Kamion: su-sudo> sure, sudo's fine with me.
<Mithrandir> Kamion: please make casper depend on sudo, then
<Kamion> done
<Kamion> the patch bug 57620 looks applyable?
<Ubugtu> Malone bug 57620 in casper "incompatible regex in is_usb_device" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57620
<Kamion> s/bug/in bug/
<Mithrandir> Kamion: I'm not sure we have egrep in the initramfs?
<Mithrandir> Kamion: actually, I wonder how that has ever worked.  I can't see grep in the initramfs
<Kamion> it probably never did work ...
<Mithrandir> Kamion: I tested it and it worked for me.
<Kamion> want me to add [e] grep?
<Kamion> hmm, no, grep is in the initramfs
<Mithrandir> Kamion: anyway, I'll poke that bug later and see what's up with it since I'm going to do casper hacking the rest of the week
<Kamion> rather, it's in busybox initramfs
<Kamion> busybox-initramfs. oh I give up
<Mithrandir> : tfheen@xoog ~ > gzip -dc < /boot/initrd.img-2.6.17-6-amd64-k8 |  cpio -t  | grep grep
<Kamion> perhaps none of the initramfs hooks copy it in
<Mithrandir> 41067 blocks
<Mithrandir> : tfheen@xoog ~ >
<Kamion> yeah
<Mithrandir> it is?
<Mithrandir> am I a fool, then?
<Kamion> it's in the busybox-initramfs package, but I think those links need to be explicitly copied
<Mithrandir> yeah, or created on startup
<Mithrandir> maybe they are?
<Mithrandir> oh well, you can change it to "busybox egrep"; that should work
<Mithrandir> I'm off for a nap now. :-)
<Kamion> yeah, busybox-initramfs doesn't seem to do the symlink farm thing
<Kamion> I'll leave this one to you - I'm not in a position to test it, and I'm most concerned with fixing ubiquity-related things anyway
<Mithrandir> ack
<janimo> pitti: hi, could you look at gxine when you next allocate time for reviews?
<janimo> we'd like to replace xfmedia with it in xubuntu
<Spads> zul: ping
<pitti> janimo: hi
<pitti> janimo: I can
<janimo> pitti: thanks
<pitti> till: hello! welcome to the channel
<cbx33> hmmm anyone a gconf expert here
* cbx33 is having an episode :p
<jdub> cbx33: ask your question, no need to ask to ask :-)
<cbx33> sorry jdub, SOP I suppose....
<cbx33> well
<cbx33> I'm writing a patch for Pessulus
<cbx33> so we can use it with the Student Control Panel in edubuntu
<cbx33> I need to edit another users gconf key
<cbx33> I'm root so permissions isn't an issue
<cbx33> but my problem is whenever I save a key....it creates the file as root
<cbx33> and gives it permission 700, so no normal user can read it
<cbx33> originally I planned to get roun this by chowning the files after the write
<jdub> cbx33: are you using the gconf api, or gconftool-2?
<cbx33> but gconf caches the writes
<cbx33> gconf api - the python bindings
<cbx33> so that wasn't an option
<cbx33> do you have any ideas?
<jdub> you could sudo gconftool-2, depending on how disgusting you think that is :)
<cbx33> well that's ok
<cbx33> but
<cbx33> hmm
<cbx33> you mean sudo it to the user it is supposed to be running as?
<cbx33> i suppose that's doable seeing as the gcontool binary isn't a gui
<cbx33> my initial idea way way back was to run pessulus under the sux wrapper
<jdub> you might want to ask vuntz 
<cbx33> I'm in conversation with vuntz
<cbx33> and he approved my chown idea
<cbx33> but i just tested and it doesn't work
<cbx33> because the gconf writes are delayed
<jdub> yeah
<cbx33> otherwise it'd be fine
<cbx33> guess I'll have to sudo gconftool....not a very nice way to do it
<cbx33> but I can't think of any other way
<jdub> keep talking to vuntz tho :)
<cbx33> oh I have been
<cbx33> but he's been really busy with the latest gnome release
<cbx33> and won't have much time
<cbx33> over the nxt few days
<cbx33> I have to get this ready for FF
<cbx33> which doesn't give me long
<cbx33> thanks jdub I'll look into it
<janimo> pitti, for gnome-cups-manager is anyone who tried sending something upstream? They have a few changes since the release in ubuntu
<pitti> janimo: I tried in the past, but it's dead upstream, so I stopped sending patches
<janimo> I'd like ot make a few changes and I wonder if I should increase our debian/patches dir and file patches in LP or make a bzr branch first
<pitti> janimo: it's not bzr'ized ATM
<janimo> hub committed at least occasionally and he used to hang around here as well
<janimo> I sent a mail too but to no avail
<pitti> janimo: for now debian/patches is the way to go
<janimo> pitti, ok
<pitti> janimo: of course, if you feel like it, feel invited to send our patches upstream :)
<janimo> pitti, ok. At least from gnome-system-tools maintainer I got a promise
<janimo> so it may happen with this as well, although I am not sure if there are other distros using g-c-m?
<pitti> not the big ones
<jono> is AIGLX working with i810 cards?
<mjg59> By "i810" do you mean "i855"?
<mjg59> If so, yes
<mjg59> i810 itself is probably a bit slow, but given that it's a P3 chipset...
<jdub> mjg59: dude, i'm getting a(nother) dell!
<thom> jdub: why.oh.why?
<jdub> thom: D420 + MediaBase == sweet ultraportable with desktop DVI
<mjg59> Ha
<mjg59> I keep forgetting my Mac doesn't actually /have/ a DVD writer
* mjg59 finds another machine to burn Vista on
<jdub> got beta 2 or RC 1?
<mjg59> RC1
<mjg59> Tch
<mjg59> Going to take about an hour to copy over via wireless
<mjg59> Go go ethernet
<bluefoxicy> does anyone know why lib64gcc1 is installed on 32-bit x86
<Keybuk> bluefoxicy: in case the 32-bit x86 is really a 32-bit x86-64?
<bluefoxicy> Keybuk:  I have a 32-bit ubuntu on 64-bit CPU
<jdong> wow, ntfs-3g really works!
<bluefoxicy> the kernel doesn't know how to execute 64-bit programs
<jdong> is it possible to get some packages for edgy universe?
<jdong> builds fine with edgy fuse
<jdong> Keybuk: whatever was causing my dbus gripes is gone now... if that's the case with the other dude in the bug report, the ticket can be closed
<Keybuk> ok, will ask nafallo
<jdong> upstart's still runnin' like a charm :)
<slomo> same here :)
<Keybuk> I'm waiting for Kamion to get back before doing something very unwise ;p
<jdong> lol
<thom> Keybuk: that sounds remarkably... restrained of you
<slomo> Keybuk: would it be possible to fix cryptsetup before you do that unwise thing? :)
<Keybuk> slomo: no, that'll get fixed when I do the rootfs changes
<Keybuk> I may just set the console output stuff back on though
<o_cee> anyone who knows when vmware-player will be usable again? someone said last week the modules where going into linux-restricted instead, but i haven't seen that happen yet..
<jdong> in dapper or edgy?
<o_cee> jdong: edgy
<o_cee> jdong: sorry about the delay, got a call.
<jdong> o_cee: in edgy, we're gonna have to wait for updated binaries from vmware
<jdong> they need to recompile against a newer hal
<jdong> so, your guess is as good as mine as to an ETA :-/
<o_cee> jdong: dang, okay..
<jdong> sorry about the delay... gaim sucks as an IRC client
<jdong> :)
<o_cee> hehe
<o_cee> are the vmware files runnable under some other emulator? like qemu?
<sladen> o_cee: IIRC, qemu and generate and load vmware images natively  I think
<o_cee> sladen: allright, will check it out, thanks
<jdong> o_cee: you might want to buy a conroe extreme and a large cup of coffee first, though :)
<o_cee> jdong: heh, that bad? :)
<jdong> qemu is not the fastest thing ever
<jdong> it's bearable on my core duo T2300....
<jdong> I've had to use it to test ubuntu livecd's when vmware was not an option
<o_cee> hrm, p4 3ghz probably won't do then..
<jdong> o_cee: you are gonna have to be patient.. and don't expect any interactive performance out of it
<o_cee> jdong: just need to get to my accounting software really, heh
<jdong> o_cee: you're gonna love your mouse framerate... I guarantee it :)
<jdong> get that coffee
<jdong> or save up for a conroe extreme... that's always nice to have
<o_cee> looking forward to it :)  heh yeah
<o_cee> would be nice
<jdong> builds firefox in a matter of minutes :)
<jdahlin> dholbach: ping
<dholbach> jdahlin: hellas
<jdahlin> dholbach: hello!
<jdahlin> dholbach: is it too late to request the inclusion of a package in edgy?
<seb128> jdahlin: what package?
<seb128> jdahlin: for universe it should be fine
<jdahlin> dholbach, seb128: specifically, I'd like to see python-psycopg2 (58864 in launchpad) to be included in edgy
<dholbach> jdahlin: no, (i guess it's supposed to live in universe)
<jdahlin> I'm not sure if python-psycopg is in main or universe
<seb128> main
<dholbach> jdahlin: and what is python-psycopg2? is that the new unstable line?
<seb128> jdahlin: no issue to have the new version with a different source package to universe though
<seb128> dholbach: cf the bug he pointed
<jdahlin> dholbach: it's the new stable branch, the old one is not actively maintained
<seb128> jdahlin: any reason to keep both? Are they incompatible?
<jdahlin> I just got an upstream bug report closed because it's fixed in the newer branch
<jdahlin> seb128: they're incompatible yes, but parallel installable
<dholbach> http://packages.debian.org/cgi-bin/search_packages.pl?searchon=sourcenames&version=all&exact=1&keywords=psycopg2
<dholbach> it's in debian already
<seb128> let's ask for a sync then
<dholbach> jdahlin: i'll download, testbuild it and file a sync-request bug
<jdahlin> dholbach: thanks!
<dholbach> anytime!
* dholbach hugs J "name tag" Dahlin
<jdahlin> dholbach: haw haw haw
<dholbach> :-D
<jdahlin> dholbach: debian version is slightly old btw, 2.0.4 vs 2.0.5
<dholbach> jdahlin: i'd prefer to get it in like this first, then do an update
<jdahlin> dholbach: cool
<dholbach> jdahlin: i made a note to look at the new version
* jdahlin awaits edgy
<Mithrandir> jdahlin: 52 days to go
<pitti> Kamion: how is the apport-ubiquity bonding doing? anything that I should modify?
<pygi> sivang, poke? can we get it in universe this week pls? :)
<DaSkreech> What's the command to reprogram ubotu?
<pygi> DaSkreech, you use forget, then add factoid
<DaSkreech> ok thanks
<Keybuk> Mithrandir: that seems like ages
<Mithrandir> Keybuk: it does.
<Mithrandir> Keybuk: do you run edgy on your amd64 monster yet?
<Keybuk> Mithrandir: not yet, though I suspect the time is close
<Keybuk> why?
<ivoks> hi
<Mithrandir> Keybuk: I just had my amd64 machine fail to start X because it had loaded nvidia.ko version 71XX, which is utterly ancient, so I wondered if you'd seen the same.
<Mithrandir> I switched to upstart today, but apart from that haven't done anything which should have gotten me such an old driver.
<Keybuk> how is such an old driver even on your system?
<Mithrandir> no idea.
<Mithrandir> I didn't think it was. :-P
<pygi> Keybuk, I think this scdbackup problem should be solved by Thomas, this has nothing to do with upstart :P
<Keybuk> where did you get the version from?
<Mithrandir> Keybuk: X complained so I read it from the log.
<Keybuk> pygi: I strongly suspect it doesn't
<Keybuk> Mithrandir: modinfo nvidia says?
<pygi> Keybuk, I'll be poking Thomas (scdbackup author about this)
<Mithrandir> Keybuk: doesn't give me any version info?
<Mithrandir> filename:       /lib/modules/2.6.17-6-amd64-k8/volatile/nvidia.ko
<Mithrandir> which looks correct
<Keybuk> pygi: though I have a hunch he didn't read the instructions and just installed upstart and not upstart-compat-sysv :p
<Kamion> pitti: just waiting for the bug reporting workflow to get polished up, really ...
<Kamion> Keybuk: yo
<Mithrandir> rmmod nvidia && modprobe nvidia "fixed" the problem, though
<Keybuk> Kamion: so, now you're back, can I make a slight seed change? :p
<Keybuk> Mithrandir: now, _that_ is interesting
<pygi> Keybuk, heh :P
<Keybuk> Mithrandir: I assume you have no other nvidia.ko on your system?
<ivoks> Keybuk: another + for upstart; it runs rc.local before gdm; that's great
<Kamion> Keybuk: go for it
<Kamion> "slight"
<Keybuk> nvidia_legacy shows up as nvidia in the lsmod output, doesn't it?
<Mithrandir> Keybuk: I'm running a find / now, but I none that I know of, no.
<Keybuk> ivoks: it does?  it shouldn't
<Keybuk> Kamion: yeah, just replacing one line for another <g>
<Mithrandir> /lib/modules/2.6.17-6-amd64-k8/volatile/nvidia.ko is all the nvidia.ko-s I have.
<ivoks> Keybuk: well, my rc.local does cping of xorg.conf and restarts gdm
<gnomefreak> the binary drivers from nvidia get rid of the volatile error 
<ivoks> Keybuk: it never restarts gdm, but it copys xorg.conf before starting gdm
<Mithrandir> Keybuk: uh, I have a 7600 GT, I really hope I don't need -legacy for that. :-P
<Keybuk> Mithrandir: no, but it could be the legacy stuff blowing chunks?
<Keybuk> ivoks: err, explain?
<ivoks> Keybuk: i have xen and ubuntun kernel; on ubuntu kernel i use nvidia; on xen kernel i use nv
<Mithrandir> Keybuk: conceivably, yes.
<ivoks> Keybuk: when starting xen i sed xorg.conf to load nv; and other way around for ubuntu kernel
<Keybuk> ivoks: ok ...
<ivoks> Keybuk: so, it does that seding (which is in rc.local) before starting gdm
<Keybuk> ivoks: did you move where rc.local is run in rc2.d?
<ivoks> Keybuk: no
<Keybuk> ivoks: so why is that happening before gdm is started?
<Keybuk> gdm is started at S13, rc.local doesn't happen until S99 ?
<ivoks> Keybuk: i know, but this is what happens :/
<ivoks> Keybuk: i'll investigate more, and let you know
<gnomefreak> are we waiting for the nvidia 9 series before we update nvidia. iirc oct. is the prospected release of 9
<Keybuk> ivoks: are you sure gdm isn't just dying because of the wrong driver?
<ivoks> Keybuk: screen would flickr; it doesn't
<gnomefreak> ivoks: after updateing dbus by chance?
<slomo> gnomefreak: gdm doesn't do anything with dbus
<ivoks> Keybuk: but i'll investigate that and let you know if there's need to think about it :0
<ivoks> gnomefreak: ?
<gnomefreak> slomo: thats what i thought too but it screwed up the nvidia binary drivers only vesa would work after dbus update
<Mithrandir> Keybuk: well, on a reboot it worked..
<gnomefreak> nv didnt work either
<ivoks> Keybuk: could be that I'm missing something
<slomo> gnomefreak: impossible imho... it must be something else that broke the drivers
<Mithrandir> Keybuk: I'll prod you or somebody else if I see it again.
<Keybuk> ivoks: suddenly lots of people are having nvidia problems :p
<gnomefreak> slomo: had to reinstall the drivers the other day
<ivoks> Keybuk: i'm not having nvidia problems :))
<jdong> ATI! ATI! ATI!
<jdong> j/k :)
<ivoks> otoh, i'm planing to buy laptop with intel :)
<gnomefreak> only updates were dbus and avahi
<jdong> Keybuk: doesn't gnomefreak's statement sound familiar? ;)
<jdong> lol
<Mithrandir> oh well, now I should be able to play with Xen.
<jdong> ivoks: have fun in 915resolution-land? ;)
<Keybuk> jdong: heh
<slomo> gnomefreak: maybe you already had new nvidia driver but didn't restart X yet? i find it hard to believe that dbus broke X drivers :P unless the nvidia drivers use hal
<pygi> jdong, yes, movie sending over dbus :)
<ivoks> jdong: that's nothing like now; will it suspend or not; should i even try? :)
<gnomefreak> slomo: nope i was using them for a week bufore this happened
<jdong> ivoks: hehehe..... intel video doesn't guarantee suspending either
<jdong> ivoks: on my intel, X crashes on resume
<jdong> so I might as well friggin reboot :)
<gnomefreak> slomo: the nvidia drivers had to build modules and everything else would dbus mess with any of those? (drivers from nvidia.com
<ivoks> jdong: that's your intel, mine will not be anything like that :D
<angasule> I installed kubuntu in spanish on saturday, and I noticed that it wants to download a 200MB language pack, there should be a less fracked up way of doing a language specific install (we had to give an extra CD with a script that added that package as well as some others, when we gave away linux here)
<jdong> ivoks: lucky you... Strangely my fglrx suspends wonderfully
<slomo> gnomefreak: nope, absolutely not
<jdong> slomo: everything is better when your dbus upload takes the blame ;-)
* jdong ducks
<gnomefreak> lol
<slomo> jdong: yeah i already noticed it :) it's always dbus' fault ;)
<slomo> jdong: but your bug from yesterday could really be caused by dbus
<gnomefreak> well i know avahi had nothing at all to do with anything dbus was only other update. dbus required restart and no gdm/kdm/xdm after about 45 minutes i reinstalled the drivers and poof X wordked
<jdong> :)
<Keybuk> hmm
<gnomefreak> i wanna say it was saterday
<Keybuk> something freaky has clearly gone on
<gnomefreak> saturday
<jdong> Keybuk: you said it
<jdong> Keybuk: did you see #kubuntu-devel a few minutes ago?
<Keybuk> no?
<jdong> [14:53]  * mornfall summons Riddell 
<jdong> [14:54]  * DaSkreech draws Circles on the floor and sprinkles salt
<jdong> [14:54]  * mornfall puts 5 candles on the Circle and draws lines
<jdong> you guys are all weird :P
<Keybuk> hmm?
<jdong> but seriously.... I'm not crazy when I say that something broke yesterday :)
<jdong> and got magically fixed
<jdong> I've been unable to reproduce my dbus problems :-/
<jdong> tried everything
<ivoks> it's the devil, i tell you, the devil
<jdong> lol
<dholbach> good night 
<jdub> Keybuk!!!
<jdub>    * Added upstart-compat-sysv to minimal-i386, minimal-amd64, minimal-
<jdub>      powerpc, minimal-ia64, minimal-sparc
<jdub>    * Added upstart to minimal-i386, minimal-amd64, minimal-powerpc,
<jdub>      minimal-ia64, minimal-sparc
<jdub>    * Removed sysvinit from minimal-i386, minimal-amd64, minimal-powerpc,
<jdub>      minimal-ia64, minimal-sparc, minimal-hppa
<jdub> 
<jdub> !!!
<Keybuk> jdub: three exclamation marks?
<Keybuk> SIX exclamation marks?
<pitti> jdub: afraid? :)
<tseng> pitti: i am :(
<Keybuk> it passed the Tollef test
<Keybuk> he has installed it, and I have remained unbitten
<Keybuk> actually, in general, I'm really happy with how stable it's been
<Keybuk> clearly careful, tes
<Keybuk> test-driven development is a goog thing
<Keybuk> good
<Keybuk> meh
<Mithrandir> Keybuk: usplash doesn't seem to work now, though.
<Keybuk> can't type and cook curry
<Keybuk> Mithrandir: I think that's entirely a usplash problem, given it starts before init :p
<pitti> Mithrandir: for me neither, but it segfaulted before upstart for me, too
<pitti> Mithrandir: itz svgalib bug for me; for you, too?
<Mithrandir> pitti: unsure, I have just noticed it doesn't work.
* pitti wonders whether he is the only one for whom usplash breaks
<tseng> pitti: it does bad stuff to my vts
<Keybuk> pitti: nah, breaks for everyone afaict
* pitti wonders whether mjg59 would kill him if he proposed to revert to plain vga
<slomo> pitti: broken for me too on my ibook
<pitti> on amd64 at least
<pitti> same here
<Mithrandir> pitti: you're using nvidia too?
<Kamion> I think at this point we should make the call based on its state at feature freeze
<Kamion> if it's still broken then, we revert to VGA if that fixes it
<pitti> Mithrandir: 'using' in the sense of "I have an nvidia card"
<Keybuk> pitti: it's not so much mjg59 that would mind, as sabdfl and the art team *shrug*
<Kamion> artwork is a feature ...
<Keybuk> personally I'm all for the "use the usplash that works"
<Mithrandir> pitti: mjg59 had some trouble with nvidia cards before.
<pitti> Mithrandir: Matthew and I gdb'ed it for a fair while, but then we just gave up
<Keybuk> talking of which
<Keybuk> has anyone seen any sign of the increasingly mythical artwork? :p
<Mithrandir> Keybuk: no, usplash doesn't work, so.. :-P
<pitti> it just falls apart in the real mode emulation code, or something like that
<Mithrandir> pitti: trying to run usplash when X is running made my kernel unhappy, though.
<Mithrandir> as in, "oops"
<Keybuk> Mithrandir: heh, yeah
<pitti> Keybuk: I saw usplash, then later text mode output, and now, with upstart, no output at all any more ;) does that count as mythical? :-p
<Keybuk> it does that
<Keybuk> even to plain X drivers
<pitti> Keybuk: it's mystical enough in the sense of 'WTF is this machine doing now?' :)
<Mithrandir> Keybuk: it used to work fine, though.
<Seveas> Mithrandir, ati card?
<Seveas> it happens to me too quite frequently
<Mithrandir> Seveas: nope, nvidia.
<Mithrandir> Keybuk: I have rebooted some more times and not seen the nvidia problem any more, so I guess it was just a fluke.
<Seveas> speaking of usplash -- /me should finish some more patches for it
<Keybuk> Mithrandir: lots of people have seen that fluke :-/
<Seveas> Keybuk, btw, I have some usplash artwork for you
<Seveas> the patches I'm finishing are making sure people can actually create artwork for it without any heroic efforts ;)
<Keybuk> Seveas: why for me?
<Seveas> <Keybuk> talking of which
<Seveas> <Keybuk> has anyone seen any sign of the increasingly mythical artwork? :
<Keybuk> Seveas: isn't is supposed to be uploaded by now?
<Keybuk> Feature Freeze is a mere 1590 minutes away
<Seveas> Keybuk, well, the things I am still working on could be considered patches, they don't affect functionality -- the things I talked about earlier are now entirely mjg59's issue ;)
<Seveas> @calc 1590/60
<Ubugtu> 26.5
<Seveas> hmm, little over a day
<Seveas> pitti, Mithrandir: are you on amd64? I noticed a bug on LP about usplash crashing on that platform
<pitti> Seveas: yes (see backscroll)
<Seveas> ah yes, missed that line
<Mithrandir> Seveas: yes
<Seveas> is indeed an svgalib bug, missing -fPIC at places
<Seveas> patch available at aforementioned bugreport
<pitti> should it be that easy?
<pitti> wow
<pitti> Seveas: gdb crashes on some ridiculously low address here (0x40 or so), according to mjg59 that was due to some real mode emulation code which doesn't work on amd64; funny that PIC cures that
<Kamion> Keybuk: er, isn't FF on Thursday?
<Seveas> pitti, according to the people on that bugreport -fPIC fixes it
<pitti> Seveas: cool
<cbx33> Kamion, I thought it was Fri
<cbx33> put it this way, I hope it was Friday :p
<Kamion> cbx33: normally Thursday
<cbx33> aARGH !
<cbx33> I'm never gonna make it
<cbx33> heh, guess I'd better stop chattin and start coding
<Kamion> infinity: speaking of which, what's the state of the live CD specs?
<_ion> keybuk: Is there high priority stuff in upstart TODO that can't be implemented after feature freeze?
* Kamion is not liking the look of https://launchpad.net/distros/ubuntu/edgy/+specs much
<Seveas> not too much green...
<cbx33> the spec I'm working on isn't even approved yet
* Kamion decides to officially defer ubiquity-advanced-partitioner
<Kamion> oh well
<cbx33> hey popey 
<jdub> Kamion: bummer :(
<cbx33> ogra was waiting for mdz to approve the SCP sec
<cbx33> spec
<Kamion> jdub: just too much stuff in it ...
<Kamion> I'll keep working on it so hopefully I'll be able to merge it early in edgy+1
<Kamion> and this frees me up to help with other things
<Kamion> notably I think I need to hammer on sane-installer-keyboard over the next couple of days
<ajmitch> Kamion: did that f-spot UVF request make it to your inbox?
<popey> hey cbx33 
<cbx33> howz it going popey ?
<Kamion> ajmitch: doesn't look like it
<ajmitch> ok, no surprise, I'll file it as a bug
<ajmitch> and then consider switching ISPs :)
<popey> cbx33: got a bug in 2.6.17 :(
<cbx33> ohdear
<cbx33> popey, what's the bug in?
<popey> via-rhine driver or thereabouts
<popey> well, not specifically that driver because that hasn't changed for years :)
<popey> but something networky, laptop /win 20
<popey> bah
<popey> bug 58469.
<Ubugtu> Malone bug 58469 in linux-source-2.6.17 "via-rhine net card stopped working in 2.6.17" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58469
<cbx33> :(
<Burgundavia> Kamion: is the windows version of OO.o still on the cd?
<zyga> hey
<jott> any chance bug 51893 will get fixed anytime soon?
<Ubugtu> Malone bug 51893 in aptitude "aptitude pegs cpu for extended period of time on "aptitude upgrade"" [Untriaged,Confirmed]  http://launchpad.net/bugs/51893
<cbx33> in gconf, If I specify a mandatory repo path, does it have to be "setup" before I can use it?
<Kamion> Burgundavia: doesn't look like it; look at http://cdimage.ubuntu.com/daily-live/current/*.list etc. if you want to check a particular image
<Burgundavia> Kamion: ok, I was wondering, because somebody wanted a CD to hand out with OO.o on it
<Keybuk> Kamion: isn't it "start of Thursday" ?
<Keybuk> _ion: most of the TODO at this point is post-feature-freeze
<Keybuk> _ion: am unsure whether to abandon b-m-l at this point, or request a stay of absence on it for a few days
<Burgundavia> Kamion: just in time for it to be too late: gparted 0.3
<Kamion> Keybuk: right, but that's not 26 hours away, so your maths is off somewhere
<Kamion> Burgundavia: hmm, the changelog is not enthralling
<Kamion> http://sourceforge.net/project/shownotes.php?release_id=444805&group_id=115843
<Kamion> maybe the NTFS bug fixes would be a good idea
<Kamion> I might pull it in, dunno
#ubuntu-devel 2006-09-05
<Keybuk> Kamion: sure it is, assuming thursday starts at midnight like normal days <g>
<Keybuk> oh
<Keybuk> wait
<Keybuk> it's still Monday
<Keybuk> ok, you win
<jdub> Riddell: ping
<Riddell> hi jdub 
<jdub> Riddell: hey, do you track scribus?
<Riddell> jdub: not generally, although I have done, edubuntu shipped that last I looked
<Riddell> jdub: what's up?
<jdub> Riddell: noticed that there was a micro bump, not sure if it's useful or not
<Riddell> I'll add it to my todo :)
<jdub> thanks
<pygi> night all
* angasule_ punches someone
<angasule_> every user can read every other user's files by default
<angasule_> ok, don't you all answer at once, people
<LaserJock> I think all linux distros I've ever run did that, depending on the group setup
<LaserJock> could be wrong though
<jdub> default umask
<mjg59> angasule_: And?
<angasule_> you don't think that broken?
<mjg59> No
<angasule_> I don't see the purpose of everybody being able to see everybody else's private files, but I can see why people wouldn't want that
<angasule_> chat logs, emails, porn, some things are meant to be private
<mjg59> If the files are private, then there's mechanisms to provide that functionality
<mjg59> emails are, by default, private
<mjg59> As are chat logs
<mjg59> If that's not the case, it's certainly a bug
<angasule_> mjg59: chat logs are indeed readable by anyone
<mjg59> angasule_: Please file a bug
<mjg59> We'll ensure that that's recitified
<angasule_> I don't think all the directories in the way are readable, though
<angasule_> but still, what if aunt tillie writes in oo.org writer her secret recipe?
<angasule_> is she supposed to know what umask she must use?
<angasule_> wouldn't it make a lot more sense to keep everything private by default?
<mjg59> Having everything private by default makes certain aspects of file sharing between users *much* harder
<mjg59> Some people do disagree. We've had this discussion on the mailing lists in the past.
<angasule_> mjg59: anything that sharing a certain folder wouldn't solve?
<mjg59> Yes, because if you have the default to be unreadable files then people tend to expect you not to be able to list them either
<angasule_> also, most kdm themes don't have userlist support (except the default kdm theme that looks like windows 3.1), probably the same situation in gdm
<angasule_> mjg59: but I mean, have a certain folder for sharing files, instead of sharing everything by default (and without warning!)
<angasule_> I'm currently setting up a family install, and the multi user settings aren't the best, for example the dialog to add new users doesn't give any advice on what groups should a new user belong to (would cdrom be useful? how about audio?)
<mjg59> angasule_: Yes. How do users navigate to that folder?
<angasule_> mjg59: it could be /home/common or whatever is proper, here, we use a different partition (so it's in /media )
<angasule_> as I said, what would you do about aunt tillie's secret recipe, or cousin stevie's porn stash?
<angasule_> I gave up on teaching my family the laws of thermodynamics, I'm certainly not going to try to explain umask...
<Kamion> fix the file browser to make it clear when files are public, and easy to change that
<angasule_> at the *very* list, it should be made clear that no file is private, and a ~/private_files directory should be visible everywhere
<Kamion> we should not be polluting default home directories with more crap
<Kamion> the default home directory should be as empty as possible; there are many good reasons for this
<HrdwrBoB> or there should be a shared files area
<HrdwrBoB> to make it easier to 'share' files
<Kamion> just fix the freaking file browser already
<angasule_> HrdwrBoB: which I proposed earlier
<Kamion> can't be that hard to improve nautilus to make it clearer
<HrdwrBoB> and less likely that people will have to go into other peoples home directorys
<angasule_> Kamion: that pretty much requires explaning permissions to aunt tillie
<Kamion> no, it really doesn't
<HrdwrBoB> angasule_: I have my files mounted under /home/storage because there's no real 'proper' place for them
<Kamion> "this file is public and may be read by all users" -> right-click -> "mark file private"
<angasule_> Kamion: you want that string next to every file by default?
<Kamion> obviously not, but it can be done more subtly, for example with well-chosen icons
<mjg59> Kamion: Ubiquity seems a touch unstable at the moment
<Kamion> UI improvements are preferable to breaking Unix for the rest of us
<angasule_> also, the filename itself should be private in many cases, like porn
<mjg59> Or, rather, it got quite confused at partitioning
<Kamion> angasule_: same concept, only with directories
<Kamion> mjg59: you're a bit short on detail ...
<mjg59> A dialog appeared telling me that ntfs resizing was impossible before I'd had an opportunity to touch anything
<angasule_> Kamion: but you complained about ~/private_files ;)
<HrdwrBoB> angasule_: nothing to stop you creating it
<Kamion> angasule_: I complained about creating it on EVERYONE's system
<mjg59> "private_files" is difficult
<Kamion> for one thing, if you're using directory names to convey meaning, remember that you just excluded non-English-speaking users from grasping that meaning
<Kamion> "Desktop" is bad enough
<angasule_> well, the current system is insecure for the sake of some supposed ease of use, and you know what OS does that...
<angasule_> don't get me started on languages
<mjg59> It's not insecure
<angasule_> who the frack got the idea of installing a 200MB language pack right after install? and cancelling the download breaks the install? brilliant!
<Kamion> angasule_: if you have a problem with the installer, file a bug
<mjg59> angasule_: If you have problems, please convey them in a helpful manner
<angasule_> it's not really the installer
<mjg59> angasule_: We're always happy to look at and fix bugs
<angasule_> it's the idea of not including any language
<angasule_> save english
<desrt> it kicks ass being a native english speaker
<Kamion> mjg59: I'm more or less aware of that problem; I think it's been there since dapper thoug
<Kamion> angasule_: you're wrong about that; that's not the idea
<angasule_> desrt: yeah, well, no native english speakers where I live :P
<mjg59> But doing so in hostile tones does not encourage people to do anything, and is against the code of conduct
<angasule_> sorry, a bit pissed, I've been messing with the install the whole weekend
<Kamion> mjg59: it's in ubiquity's partman-auto integration, anyway - it needs to drive partman forward to the resize question in order to find out how to draw the resize bar, but if resizing fails it gets confused
<desrt> mjg59; you'll understand if he's feeling a bit edgy...
<angasule_> the multi-user support could use a few more things
<angasule_> for example, when modifying a user's details, modifying several users at the same time would be nice
<Kamion> I do think we could do with attaching descriptions to groups in some way that the users and groups tool could display
<angasule_> so that I can create all the users and then add them all to the cdrom, audio, etc, groups, if I want to
<Kamion> we already have that documentation in base-passwd - it would just be a matter of exporting it somehow
<angasule_> there is, right now, in kubuntu, no indication of what groups are useful to be added to
<angasule_> also, the ability to add things to all desktops (for example, a link to a certain folder)
<mjg59> angasule_: There is in ubuntu
<angasule_> right now, one must modify /etc/skel
<mjg59> Also that
<angasule_> mjg59: ah :/ I haven't seen it in kubuntu, sorry
* angasule_ thinks of what else he can complain about, while his memories are fresh
<Kamion> angasule_: with regard to your comment about cancelling the download breaking the install, is that in the desktop CD installer?
<Kamion> because that's really not supposed to happen, and I'd like a bug report with log files if it does
<angasule_> Kamion: I believe so, it didn't happen to me, but to a friend
<Kamion> it's meant to be possible to cancel that download harmlessly
<Kamion> now, if this is dapper (.0, not 6.06.1), then it might well be a known bug
<Kamion> (and fixed)
<angasule_> anyway, the mere requirement of an extra 200MB pack at that point IS a bug, in my opinion
<Kamion> *shrug* only so much you can fit onto the CD
<Kamion> the fact that e.g. OOo help, Firefox translations, etc. are incredibly huge isn't one we can do a lot about
<angasule_> well, we are just finishing a linux course here, and we had to provide a second CD with extra packages
<Kamion> assuming that https://launchpad.net/distros/ubuntu/+spec/larger-livefs gets done by feature freeze, we'll have a better solution for Edgy in the DVD
<angasule_> the language pack was probably the largest one
<angasule_> DVDs are still not that common around here
<mjg59> Kamion: Also, the current network config stuff after install seems to interact badly with upstart
<angasule_> unless you're planning to change it to 'linux for human beings in the first world' ;)
<Kamion> then it's simply a "can't squeeze a quart into a pint pot" problem
<mjg59> Kamion: But that's probably something I need to speak to Scott about
<Kamion> we expect and hope that people in other countries will remaster CDs to provide appropriate language packs by default
<mjg59> Kamion: One thing that is worth noting is that not all wireless cards automatically associate with the nearest network
<Kamion> mjg59: sorry, what network config stuff?
<mjg59> Kamion: So if there's no essid specified in the config, they won't associate
<angasule_> here, DVDs are not common, and broadband is rare, regular broadband is 256kbps
<mjg59> Kamion: Oh - dhcp on all interfaces. upstart seems to block on trying to configure the network before starting X
<jdong> mjg59: yes, including the increasingly popular ipw3945
<Kamion> oh, yeah, Scott's problem
<angasule_> in fact, kubuntu and ubuntu are only for high end systems by our standards
<Kamion> I'd like to be able to get network configuration into Ubiquity in some form, but I only just managed to squeeze in grub configuration for edgy, and I doubt I can do netcfg as well befor FFF
<Kamion> before FF
<angasule_> well, high and kind of med, this pc has 256MB of RAM and it doesn't work so badly
<mjg59> Kamion: Yeah, that's a shame
<Kamion> I suppose just an ESSID selector *might* be doable, maybe
<mjg59> Hm
<LaserJock> angasule_: do people use Xubuntu then?
<mjg59> Kamion: Of course, the problem with an ESSID selector is that you then hit problems when the machine is moved elsewhere
<angasule_> LaserJock: no, they use windows
<jdong> Kamion: or you can just networkmanager and call it a day ;)
<Kamion> but in reality, I'd have to get it done tomorrow, and livecd-access and sane-installer-keyboard need to happen before that ...
<mjg59> But possibly that's desirable
<jdong> Kamion: you know it's tempting :)
<Kamion> jdong: no, we really can't :P
<jdong> aww
<Kamion> it's not tempting, having tried it before
<Kamion> once bitten, twice shy, and all that
<jdong> what was wrong with n-m the first time?
<Kamion> mjg59: I think that's OK - it's a configuration tools problem after that
<mjg59> Hm. Didn't we have code that automatically enabled sub-pixel anti-aliasing on LCDs?
<angasule_> we used Kubuntu for the course, simply because that's what we know (we're all kde people, with one strong debian user), and the course was for Computer Systems Engineering and Electronics Engineering students, who usually have higher than average computers
<Kamion> jdong: it had lots of hardware-specific breakage
<jdong> Kamion: ah, I see, never mind then :)
<Kamion> mjg59: yes, in casper
<mjg59> Kamion: It doesn't seem to work now
<Keybuk> Kamion: my problem?
<Kamion> the casper and ubiquity hooks for that both look correct at a quick glance, unless somebody broke gnome-panel-data itself
<mjg59> At least, I just ended up with "best shapes" rather than "sub-pixel"
<Kamion> Keybuk: 01:27 < mjg59> Kamion: Oh - dhcp on all interfaces. upstart seems to block on trying to configure the network before starting X
<mjg59> Oh, wah.
<mjg59> No DRI by default.
<mjg59> Oh, oops
<mjg59> The crack switch is in the "crack" position, not the "work" position
<LaserJock> angasule_: I do most of my Ubuntu development on a 1.3GHz P4 with 256MB ram so I can understand a bit of that, although it runs Gnome,  KDE, and OO.o  quite well
<jdong> mjg59: the crack switch?
<jdong> is that the sony nvidia/Intel switch?
<mjg59> Yeah
<angasule_> LaserJock: well, 256MB is mid-high, 128MB and less is common
<zul> LarstiQ, ouch..
<mjg59> Keybuk: Also, ctrl+alt+del doesn't seem to be doing anything for me
<jdong> mjg59: wow.... I've gotta start calling it that :)
<zul> doh..
<zul> LaserJock, ouch even
<Kamion> mjg59: oh - the problem is that laptop-detect isn't in desktop
<LaserJock> zul: uh, yeah. That's what I do most of my pbuilder'ing on
<angasule_> I'm currently on a 256MB as well (family PC), mine has 512MB, I can't stand this :)
<Keybuk> Kamion: explain?
<Kamion> hmm, no, it still ought to be installed at that point
<mjg59> Kamion: Ah
<Keybuk> mjg59: no, it doesn't do anything for anyone yet :)
<Kamion> Keybuk: I can't, it's mjg59's problem, I have no idea what it is
<Keybuk> mjg59: --> #upstart (it's noisy in here)
<Kamion> right, I'm just going to move laptop-detect into desktop - I'm really bored of trying to guess whether it's installed at various random points in the installation
<Kamion> hmm, in practice it's actually in minimal now anyway, so obviously it's not that
<Kamion> mjg59: ok, having tracked it down further, fontconfig is supposed to default to "Automatic" subpixel rendering as of breezy, which is meant to turn it on only for LCD screens
<Kamion> at least so the fontconfig 2.3.1-2ubuntu1 changelog says
<mjg59> Right
<mjg59> So fontconfig is probably broken
<mjg59> Or gnome
<mjg59> Sigh
<mjg59> And why did dpkg-reconfigure -pcritical xserver-xorg just decide I wanted vesa?
* mjg59 cries
<Keybuk> BE ON EDGY!
<mjg59> Ok, so compiz is /much/ faster on this hardware
* mjg59 needs to sort out some sane compiz defaults
<jdong> mjg59: RenderAccel! Water! Trailfocus!
<jdong> lol
<jdub> craaaaaaaaaaaaaaaaack
<Keybuk> jdub: I thought you liked the crack
<Keybuk> jdub: interesting ... your font rendering looks *very* different to mine
<jdub> Keybuk: sshot taken on windows
<welshbyte> hm, someone's claiming that the ~/Examples symlink is owned by root... that's not right, is it?
<welshbyte> (in knot 2)
<Keybuk> jdub: hmm
<Keybuk> I didn't realise that Linux's font rendering what that different
<Kamion> welshbyte: worth finding out whether they mean in a live session or after installation
<welshbyte> Kamion: good call. will do
<jdub> Keybuk: depends which combinatorial clusterfuckage settings you change
<Kamion> welshbyte: if it's in the live session, it's a casper bug; if it's after installation, it's probably an adduser bug
<welshbyte> ok
* welshbyte hugs whoever changed the launchpad font to a monospace one
<neuralis> hmm, edgy pygtk breakage
<crimsun> (slomo uploaded fixed ones)
<FliesLikeALap> should we be expecting the edgy-desktop and edgy-alternate knot 2 cds to be working properly on server hardware [yet] ?
<FliesLikeALap> I suppose I should try the edgy-server before asking, to see if there are bigger issues at hand
<dcode> FliesLikeALap: what are you trying to do, exactly
<dcode> edgy is alpha
<FliesLikeALap> yes, I'm not talking about production
<dcode> it's known broken
<FliesLikeALap> production boxes*
<dcode> okay
<FliesLikeALap> I'm talking about for testing purposes, asking whether it is too early to start testing such things
<dcode> for server related systems, it's likely more stable than on the desktop...
<dcode> I'm running edgy on a desktop right now....it works but there are obviously bugs
<dcode> and things crash from time to time
<FliesLikeALap> yeah, I am aware of that from when I tried dist-upgrading to degy and it failed last week or the week beore
<FliesLikeALap> beforeP*
<dcode> it's really meant more for developers
<FliesLikeALap> I tried edgy-alternate on one of my spare servers last night and it failed fantastically on boot
<FliesLikeALap> alright, I'll wait until a more appropriate testing time then
<dcode> dapper was build as a solid platform to be reliable for such things as server and enterprise.....edgy is just that....it's bleeding edge stuff....
<dcode> even when it's released, it may not be as stable as dapper....that's not its goal
<FliesLikeALap> ah
<dcode> that's why dapper was LTS (long time support)
<neuralis> crimsun: still broken on an incorrect version check (2.12.0 considered < than 2.11.1 by _gtk.so)
<dcode> FliesLikeALap: really though....for future questions relating to non-development...you should try #ubuntu+1
<crimsun> neuralis: afaict the newest pygtk isn't "out there" yet; should be available in a few minutes
<FliesLikeALap> yes dcode I'm aware of that but was just asking in here to see whether or not it is appropriate to test this on servers yet/at all
<FliesLikeALap> didn't mean to bother you, sorry
<dcode> no prob
<dcode> just trying to help ;-)
<neuralis> crimsun: right, it's the comparison that's strange
<dcode> FliesLikeALap: I'm in ubuntu+1 too...and I woulda answered there as well
<FliesLikeALap> I only asked here because I raised the topic last night in there and nobody answered
<dcode> no worries :D
<stub> Launchpad will be going down in 15 mins for its regular code update. Estimated downtime is 10 mins.
<dholbach> good morning
<jamesh> dholbach: you package things quickly
<jamesh> on the weekend too
<dholbach> jamesh: what do you mean? :-)
<dholbach> jamesh: ahhh gnome-gpg - yeah :-)
<jamesh> dholbach: I release a tarball on Saturday and you package it on Sunday
<dholbach> jamesh: that's not quick - watch me and seb128 do GNOME 2.16 today ;)
* dholbach hugs jamesh
<desrt> dholbach; word's getting around
<desrt> dholbach; keep this up and you're gonna put sebuild out of business
<dholbach> not really... he's WAY quicker
<dholbach> especially doing bug triage
<dholbach> i swear... one of these days they'll have an extra machine in the data centre just to keep up with him
<desrt> sebastien is the reason that inotify-over-ftp was created
<dholbach> haha
<desrt> his polling was causing undue stress on the servers :)
<pitti> Good morning
<ajmitch> morning pitti 
<Burgundavia> morning ajmitch, pitti
* ajmitch decides to try out upstart on the laptop
<shawn_home> Is there plans for a Ubuntu 'sid' ?
<HrdwrBoB> er
<infinity> shawn_home: Our current development release *is* our equivalent to "sid".
<HrdwrBoB> I think you fundamentally misunderstand the ubuntu development process
<infinity> shawn_home: We don't have a "testing", just an "unstable" and several aging "stable" releases.
<shawn_home> infinity: those would be nice
<shawn_home> there is unstable?
<infinity> Err, what would be nice?  I was stating fact, not making a proposal.
<infinity> shawn_home: "edgy" is our current development release.
<shawn_home> but once edgy is 'done', theres nothing else to inbetween
<infinity> I'm not sure what you mean.  Once edgy is released, we open a new development release.
<infinity> Within a week, generally.
<shawn_home> i ment like Debian's sid, where there is a 'release' thats never released
<HrdwrBoB> why bother?
<infinity> Right, but since we don't use an unstable->testing method, we don't need that.
<HrdwrBoB> you can't wait 6 months?
<Mithrandir> shawn_home: our model is different, so no, there's no point in doing what you're suggesting.
<infinity> shawn_home: We just rolled the state of dapper at release into edgy, then kept going.
<shawn_home> HrdwrBoB: well waiting 6 months is a long time as things change so much
<infinity> shawn_home: We could always tag our current development release "unstable" to make that clear, but we intentionally didn't do so, to avoid Debian/Ubuntu moneclature confusion.
<infinity> nomenclature, too.
<shawn_home> but each time you release i have to change my apt configs and apt-get dist-upgrade 
<shawn_home> there is no continuous line of packages fed down 
<infinity> Is that a big deal?
<infinity> It takes 20 seconds.
<shawn_home> it can introduce breakage :)
<Burgundavia> so can sid
<ajmitch> which is why update-manager can do it for you
<shawn_home> but sid is on a individual package based level (aptitude hold foo if foo beaks)
<infinity> shawn_home: If you follow our DEVELOPMENT releases (which seems to be what you want), you'd get no more breakage than running sid.
<infinity> shawn_home: If you're following stable releases (so, only upgrading when we release), then you get to read release notes, and update-manager will try to do a smooth upgrade.
<Burgundavia> ajmitch: although I need to make certain that update-manager get updated to allow -d earlier (mvo waited for about a month to turn that feature on in edgy)
<infinity> shawn_home: I don't think you're understanding what I'm saying.  If you want something sid-like, you should have been running dapper up until June 1, then you should have switched to edgy.
<infinity> shawn_home: Then you get the same "new packages, as we ship them" thing.
<infinity> shawn_home: And the same breakage to go with it. :)
<shawn_home> which is fine :)
<shawn_home> its the wait between when dapper is 'finished' to when edgy gets started
<infinity> shawn_home: Right, so now that we're clear on that, there's no problem.  You want edgy, apparently.
<mvo> Burgundavia: *cough* that is correct, it probably should be turned on a lot quicker
<infinity> shawn_home: There was only a 1-week delay between the two, really.
<shawn_home> oh?
<ajmitch> mvo: takes awhile for things to be installable though :)
<infinity> shawn_home: Give or take.  We opened edgy pretty quickly.
<shawn_home> I was using dapper while it was in alpha
<shawn_home> im just used to the 'unstable is never released as a distribution' mentality 
<shawn_home> what you have is a running cycle 
<Burgundavia> ajmitch: installable != upgradeable
<infinity> shawn_home: That's a reasonably new concept in Debian, too.  We used to freeze unstable to do releases in Debian, just as we do in Ubuntu.
<Burgundavia> ajmitch: I wonder if sid has increased the time between releases, because people are constantly pushing new crap into sid
<infinity> shawn_home: And, while the unstable->testing thing works well for Debian, it doesn't work well with our rapid release model, so we're not doing it.  EOT.
<shawn_home> infinity: parallel then?
<ajmitch> Burgundavia: yes, it's a problem when many developers don't run testing & only care about sid
<infinity> shawn_home: Hire us another 30 people?
<Mithrandir> shawn_home: we don't have enough manpower to run stuff in parallell.
* mvo personally thinks that the a not-frozen sid does not help the releases in debian
<infinity> mvo: It's certainly a point of contention, yes.
<shawn_home> infinity: hire? :) people will do it if asked
<infinity> shawn_home: Not the dirty work that would need to be done to develop two distributions in parallel and keep the fixes in sync between both.  It's not terrible fun.  It's very inefficient.  And we don't freeze long enough to make it worthwhile.
<shawn_home> hmm
<dholbach> I think it's not problematic at all to keep a ~/upload dir in the time where a release is frozen or we're waiting for a new devel branch to open
<shawn_home> 'waiting for new dev branch'
<dholbach> I don't see which *real problem* the proposal is trying to fix
<shawn_home> thats where I want to park myself onto when edgy is done
<mvo> releasing always involves some pain. and it is not fun. if we had two parallel branches that would hurt our quality because less people would actually run (and therefore test) the distro that is about to be released
<shawn_home> (let's see what GNU libc broke today! branch)
<shawn_home> :)
<infinity> shawn_home: Then you just change your sources.list to our newly-opened release after we ship edgy and track that.  I'm really not understanding the problem.
<dholbach> sudo sed -i 's/dapper/edgy/g' /etc/apt/sources.list      -    is that the problem?
<shawn_home> infinity: but that has to be announced beforehand 
<shawn_home> whereas sid was just as-is you get whats dumped in
<shawn_home> if it works, good, if not,wait til the next package push
<infinity> So, as dholbach states, you only issue is the substitution on sources.list?
<infinity> s/you/your/
<shawn_home> pretty much 
<Mithrandir> shawn_home: what you are describing is something like grumpy, which while it haven't been pushed off the ground yet is going to be "latest version of all the crack we can find".  Like, a global build-from-cvs thing.
<infinity> We're not putting "unstable" symlinks in our archive, to avoid confusion with Debian's devel model.
<infinity> It was a conscious decision.
<shawn_home> then call it something else than unstable?
<infinity> Mithrandir: Grumpy may be more bleeding edge than what he really wants (or what anyone really wants)
<infinity> Mithrandir: I'd be curious to see if anyone will actually attempt to run a grumpy system, if it's ever even bootable.
<shawn_home> grumpy eh
<dholbach> I think that much discussion about 52 characters is exaggerated :)
<shawn_home> infinity: sure, could try grumpy in a VM :)
<shawn_home> without worry whatsoever
<Mithrandir> infinity: it'll be bootable once every blue moon every blue moon or something.
<infinity> Mithrandir: If that. :)
<shawn_home> but where is grumpy?  i
<ivoks> waiting to be borne
<infinity> shawn_home: It doesn't exist.
* dholbach takes the dog for a walk
<infinity> shawn_home: It's an infrastructure dream, not a product (yet)
<Mithrandir> shawn_home: https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/GrumpyGroundhog is the description of what grumpy could look like.
* infinity decides that this conversation was delivered stillborn, and goes to work instead.
<Burgundavia> shawn_home: grumpy is a long term plan to create something that is even closer to upstream. Building straight out of upstream sources
<shawn_home> Burgundavia: interesting
<shawn_home> so is it possible ubuntu can develop a symlink thats different that 'unstable' ? 
<Burgundavia> however, I emphasize plan, as it is entirely vapourware currently
<shawn_home> that way, people who want more bleeding can just stay with whatever that 'name' is and not concern the actual release 
<Burgundavia> you want an symlink for unstable to the latest development? as infinity explained to you, that is a decision that was made, not an accident
<ajmitch> if people are brave enough to run unstable software, they can handle changing their sources.list
<Burgundavia> indeed
<shawn_home> ajmitch: no problem changing the list, the question is knowing what to change it to
<ajmitch> the name is announced a month or two out from release, usually
<ivoks> intorducing unstable would result with noone using stable, and that would result with bad product or delayed resleases
<Burgundavia> if you are not following ubuntu development enough to know the next name, I question why you should be running it
<shawn_home> Burgundavia: it'd be the same reason I'd run sid
<Burgundavia> ivoks: indeed. Sid has some serious systemic issues. If I were DPL, killing sid would be the first thing I would push for
<ivoks> Burgundavia: *nod* it's just to tempting to run sid, and not sarge
<ivoks> Burgundavia: i mean, how many of us are running dapper?
<shawn_home> it does however make it nicer for people who want to develop on ubuntu to have a running distribution that doesn't release though
<shawn_home> this is what Grumpy would do for me
<shawn_home> GrumpyGroundhog == what im looking for
<shawn_home> whats the likely hood it will come true?
<ivoks> shawn_home: developting for "unstable" would be risky since your project could or could not end up in stable
<shawn_home> well, true but if my package was in unstable i'd have to give the goahead to move it to a released branch
<shawn_home> but I like what Grumpy is
<shawn_home> Grumpy == sid
<Burgundavia> shawn_home: not really
<Burgundavia> sid is closer to the lastest devel, which is currently edgy
<Burgundavia> look, ubuntu is never going to have a sid, grumpy is a dream
<Burgundavia> end of story
<shawn_home> im hoping it comes true :)
<ajmitch> grumpy would be far more unstable than debian experimental, most likely
<Burgundavia> and developers shoudl be developing on for stable versions of ubuntu
<Burgundavia> ajmitch: I think the plan is that nobody would run an entire distro of grumpy
<Burgundavia> merely one package or so
<shawn_home> Burgundavia: that depends on what someone is developing
<shawn_home> I may require say GNU libc 2.5 thats in grumpy since it has new userland C APIs to hook into the kernel 2.6.40 or whatever
<Burgundavia> right, anyway, this discussion is going nowhere. neither ajmitch nor myself work for canonical
<Burgundavia> infinity and Mithrandir, who do work for canonical have very clearly laid out the why and what
<Burgundavia> not to be rude, but I think we are talking around in circles here
<Mithrandir> shawn_home: in which case you'd pull in that version of libc.  You wouldn't want the latest snapshot of say, your window manager, X, all of gnome, the kernel, etc.  So it's closer to Debian's experimental than Debian's unstable.
<shawn_home> i guess so, yes :)
<Burgundavia> ajmitch: X not starting in latest edgy live? have you seen this?
<ajmitch> Burgundavia: no, I haven't used a live cd for awhile
<ajmitch> don't have the bandwidth to fetch them
<shawn_home> It being 3:30am of the clock is sleep time, thanks 
<Burgundavia> ubiquity has been borked for a while for me, but I need to retest
<ajmitch> Burgundavia: you may be one of the few live cd testers this week, I don't know :)
<Burgundavia> well, presumably everybody who downloaded knot2 tested it
<Burgundavia> it might be an upstart issue
* Burgundavia wonders why it works on the 6th boot
<Hobbsee> hey all
* Hobbsee hugs pitti 
<Mithrandir> hi dudette
<Hobbsee> hey Mithrandir :)
<Mithrandir> seems like my kernel is complaining about the dirt, and I who cleaned here just yesterday:
<Mithrandir> [ 3744.215125]  cdrom: hda: dirty DVD+RW media, "finalizing"
<Hobbsee> heh
<sivang> morning
<Hobbsee> hey sivang!
* sivang hugs Hobbsee 
* Hobbsee hugs sivang 
<Hobbsee> ROFL @ keybuk's message
<Hobbsee> it's the init-crack!
<Hobbsee> http://rafb.net/paste/results/R1XemI81.html
<infinity> Hobbsee: That's nothing to do with Keybuk, that's apt warning you that removing packages marked Essential is a Very Bad Idea.
<Hobbsee> infinity: awww....pity
* Hobbsee considers upgrading
<ajmitch> Hobbsee: the only fun I had was getting a login prompt *really* early
<Hobbsee> ajmitch: right
<ajmitch> apart from that it was disappointingly stable & didn't cause issues
<Hobbsee> bah
<Hobbsee> heh
<infinity> ajmitch: Really early as in, before 'hostname' ran?  Yeah, that's cute.
<ajmitch> now we can say we've got a fast boot time
<infinity> "We deliver you a useless system in record time"
<infinity> "If you'd like to use it, please wait a minute before typing your password"
<dholbach> Kamion: Just a headsup - there's gparted 0.3 - I didn't check the ChangeLog yet, but it might be interesting
<Burgundavia> dholbach: Kamion said it might pull it in for the ntfs fixes
<dholbach> ah ok
* pitti hugs Hobbsee back
<sivang> Hobbsee: is there an equivalen flash-plugin-nonfree for konqueror ?
<pitti> hi Hobbsee 
<Hobbsee> pitti: :) finally
<Hobbsee> heya
<sivang> Hobbsee: I have it installed, but knonqi won't recongnize it
<pitti> hi sivang 
* sivang hugs pitti 
* ajmitch hugs Hobbsee 
<Hobbsee> sivang: er.  not sure on that, i dont use konq much for web browsing
* Hobbsee hugs ajmitch 
* Hobbsee has even had the honour of hugging ajmitch in person :)
<Hobbsee> sivang: libflash-mozplugin apparently
<sivang> Hobbsee: thanks
<ajmitch> :)
<Hobbsee> according to apt-cache search anywya
<sivang> Hobbsee: I'm walking on some KDE grounds (notably Konqueror) after having been fed up with firefox
<sivang> ;-)
<Hobbsee> sivang: hehe, nice
<sivang> Hobbsee: I wonder what kills firefox so hard when I enter www.visitscotland.com, same with moz and opera, but with KHTML , it's a different ball game :-)
<Hobbsee> sivang: i'm not sure.  firefox beta?
* Hobbsee notes that firefox 1.5 doesnt seem to break with it
<sivang> Hobbsee: possibly. ALthough I had similar choke up behavoirs on several websites with the dapper's one as well
<sivang> Hobbsee: I suspect there's something undetected somewhere in gecko if it's still used there.
<Hobbsee> ah
<Hobbsee> interesting.  apparently my machine had decided to shut down, after reaching the critical temperature of 3430 (or similar) degrees celcius.
<ajmitch> Hobbsee: I told you to replace that fan
<Mithrandir> Hobbsee: oooh, do you have a nice black hole in your floor now?
<Hobbsee> ajmitch: hehe
<Hobbsee> Mithrandir: *checks* - i dont think so.
* Hobbsee blames upstart
<Mocka> I ate a pooh.
<doko> Kamion: please approve openoffice.org-l10n for dapper-proposed
<mempf-edgy> hey guys
<mempf-edgy> im having a major problem with upstart
<giftnudel> mpf-edgy: well, keybuk isn't here, can you file a bug?
<mempf-edgy> yeah
<mempf-edgy> hold on
<mempf-edgy> il do that now
<G0SUB> pitti: hello
<pitti> hi G0SUB 
<G0SUB> pitti: can I pm you?
<pitti> sure :)
<Hobbsee> G0SUB: pitti eats people who pm him
* pitti shows his evil teeth for a split second
<G0SUB> Hobbsee: yeah I know :)
* Hobbsee yanks out pitti's teeth
<pitti> Hobbsee: phaph iph noph very niphe oph you!
<mempf-edgy> sigh
<mempf-edgy> i can no longer boot my pc
<Hobbsee> pitti: hehe.  i'm evil like thtat
<pitti> mempf-edgy: it's all Scott's fault
<Hobbsee> pitti: heh..  yeah.  if in doubt, blame scott.  in fact, blame scott anyway
<ajmitch> mempf-edgy: missing upstart-compat-sysv or initscripts?
<Kamion> doko: only openoffice.org-amd64 is there
<mempf-edgy> possibly
<mempf-edgy> il give you the link to my bug report
<ajmitch> mempf-edgy: I saw it
<ajmitch> however I'm not the one who can help with upstart issues
<mempf-edgy> oh ok
<doko> Kamion: ahh, ok. that one should go in as well
<mempf-edgy> is this a known problem?
<giftnudel> mempf-edgy: where is your bug report
<mempf-edgy> https://launchpad.net/distros/ubuntu/+source/upstart/+bug/58985
<Ubugtu> Malone bug 58985 in upstart "Can't boot using upstart" [Untriaged,Unconfirmed]  
<giftnudel> mempf-edgy: how long did you wait`
<mempf-edgy> im still waiting
<mempf-edgy> lol
<mempf-edgy> so an hour?
<giftnudel> I mean, the system is still in the state you described in the bug?
<mempf-edgy> yes
<giftnudel> pressing alt-f1-f8 doesn't do anything?
<mempf-edgy> il try
<giftnudel> alt+f1 then alt+f2 and so on
<mempf-edgy> alt-f1 through f6 takes me to a a login screen
<mempf-edgy> however its (none) Login:
<mempf-edgy> err
<mempf-edgy> not login screen
<mempf-edgy> login prompt
<giftnudel> mempf-edgy: ok, that's ok so far
<giftnudel> how often did you reboot?
<mempf-edgy> huh?
<giftnudel> was this the first reboot after installing upstart
<mempf-edgy> yes
<mempf-edgy> ive also tried a clean install of the september 5th daily build
<mempf-edgy> same problem
<mempf-edgy> the september 5th build would have upsstart in by default
<giftnudel> ok
<giftnudel> mempf-edgy: please mention the clean install of the september 5th build in the bug report, as it's then easier to reproduce
<ajmitch> doko: do we want to get plone 2.5 & update all the other zope products in universe?
<mempf-edgy> roger that
<HiddenWolf> is there a livecd with upstart in it already?
<giftnudel> HiddenWolf: mempf-edgy claims sep. 5th is, don't know if it's live
<mempf-edgy> i used the alternate
<mempf-edgy> but the desktop cd should also have upstart
<giftnudel> HiddenWolf: http://cdimage.ubuntu.com/daily-live/20060905/edgy-desktop-i386.manifest claims it is
<giftnudel> mempf-edgy: do you know what has started (initscripts) and what not?
<mempf-edgy> no
<doko> Kamion: it's now there
<mempf-edgy> bug report is updated now
<doko> ajmitch: yes, low priority
<slomo> infinity: please give-back pygtk on sparc/ia64 :)
<Kamion> heno: http://people.ubuntu.com/~cjwatson/gfxboot/modplay-experiment.iso - unfortunately I just get beeps, not useful sounds
<Kamion> er, sorry, give that a  until scp finishes
<Kamion> a minute
<heno> Kamion: cool, i'll teast, thanks!
<Kamion> I'll tell you when it's all there
<heno> Kamion: will it be possible to get polyphonic tones later? :)
<Kamion> er. let's make it work at all first? :)
<Kamion> I honestly don't know, I don't understand the assembly well enough
<heno> we could probably charge 3 for those actually :)
<heno> yep, no problem
<Kamion> and while I did find a mod file from upstream that I could play in the same way as I played the ones you sent me, I can't find any code anywhere that actually plays that file from upstream
<Kamion> which leads me to question how well-tested the mod-playing code in gfxboot is ...
<heno> understood
<heno> At the same time we are exploring some key and mouse gestures on the desktop that might make the gfxboot options unnecessary in the future
<Kamion> I just randomly assigned mod files to items, before having played them
<Kamion> having now played them, 6th.mod seems like the best choice for a startup sound
<heno> But that requires some fixing of AT-SPI, so it can load dynamically
<heno> ok, I'm sure I can have other ones made as well
<Kamion> the one comment I'd have on the files that you sent is that they all seem to be 8 seconds or so long for no reason - all the actual sound is in the first couple of seconds
<Kamion> not sure if that's a property of the file format or not
<ajmitch> doko: ok, I'll look over what we need & get a list to sync
<heno> It might just be the way they are made. I'll look into that
<Kamion> heno: http://people.ubuntu.com/~cjwatson/gfxboot/modplay-experiment.iso is actually there now
<heno> thx
<heno> oooh, a 10MB ISO :)
<Kamion> it won't do anything much else useful. I could have removed the kernel image and initrd from it too but I usually like to leave those there
<dholbach> can somebody liberate liboobs-1-1 and liboobs-1-1-dbg (of liboobs source package) from NEW? it's needed for new gnome-system-tools.
<heno> Kamion: ok, on the first machine I heard nothing (a compact shuttle computer, which probably doesn't have a speaker). I rebooted this one and did hear the little chirps from the menu
<heno> It might be more useful to have a sound when gfxboot starts up and one upon pressing F5 (the None entry has no sound)
<heno> Another great help would be the possibility to activate the menu items with a unique key, like 1-5, within the menu
<infinity> dholbach: It would help if it were actually in NEW...
<dholbach> uh?
<infinity> dholbach: Did you not upload it..?  Or did soyuz lose it?
<infinity> 2006-08-30 21:55:43 EST  Published  edgy   Release  main  devel  0.2.0-0ubuntu2
<infinity> The current versoin published (above) produces liboobs-1-0.
<dholbach> 0.3.0-0ubuntu1 ... "Successfully uploaded ... to upload.ubuntu.com."
<dholbach> I'll re-upload, ok?
<infinity> Sure.  Did you get a reject message or anything?
<dholbach> If so, I must have deleted it in a state of turned-off-brain
<infinity> Ahh, no, you wouldn't have.
<Hobbsee> infinity: seems that soyuz is losing things again.
<infinity> Yeah, it failed on the upload.  Fun.
<infinity> dholbach: Just reupload it.  I'm curious to watch it go through.
<dholbach> infinity: done
<infinity> dholbach: Made it that time.
<dholbach> infinity: Yooohooo! :-)
<seb128> dholbach: maybe file-roller didn't get accepted neither?
<Kamion> heno: there *is* one on startup
<Kamion> heno: I think the fact that you didn't hear it is not a good sign ;-)
<dholbach> seb128: looks like
<dholbach> nghngh
* dholbach re-uploads
<infinity> seb128: file-roller is indeed in the "failed" queue.
<Kamion> heno: you're right that there's none on F5 at the moment
<seb128> infinity: is there any else gnomish there too?
<infinity> seb128: gconf-editor
<seb128> I'll reupload that one then
<seb128> thank you
<heno> Kamion: I tried restarting twice and listened carefully. Of course those chirps can get drowned out by the birds outside 
<Hobbsee> Kamion: if you're not terribly busy, can you check what happened to https://launchpad.net/distros/ubuntu/+source/lyx/+bug/57478 please?  it seems to be added, yet there's no package in the archive, and there seems to be no listed builds for it.
<Ubugtu> Malone bug 57478 in lyx "Please sync xdg-utils and lyx-common from Debian" [Untriaged,Confirmed]  
<Kamion> heno: I definitely heard a small beep here, but it's not what it's supposed to sound like
<Kamion> Hobbsee: xdg-utils is in NEW
<Hobbsee> Kamion: ah okay.  must have missed that.
<heno> Kamion: ok, I might have missed it both times
<ajmitch> Kamion: any word on the f-spot UVF bug?
<Kamion>        lyx |    1.4.2-4 | edgy/universe | source, amd64, i386, ia64, powerpc, sparc
* Hobbsee wonders how to see the NEW queue?
<Kamion> ajmitch: still no mail?
<Kamion> Hobbsee: https://launchpad.net/distros/ubuntu/edgy/+queue
<ajmitch> Kamion: no, I filed a bug, subscribed ubuntu-release
<Hobbsee> Kamion: thanks.
<Kamion> ajmitch: oh, my bug mail goes to a different folder which I'm very behind on; I'll dig it out
<ajmitch> bug 58968
<Ubugtu> Malone bug 58968 in f-spot "UVF Exception for F-Spot 0.2.0 " [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58968
<ajmitch> ok, thanks
<Kamion> thanks, I'll get back to you on that
<Kamion> heno: so, err, not sure what to do here. Is the unhelpful beep better than nothing?
<Kamion> I could include the code but not the .mod files and people could experiment
<gnomefreak> what package controls sudo /etc/init.d/gdm?
<gnomefreak> - sudo
<heno> Kamion: I think the very weak and unrealliable beeps may be worse than nothing
<Kamion> heno: yeah. I think I'll just include the code and somebody else can try to figure out WTH is wrong
<heno> Kamion: any chance we can add some key navigation to that menu instead?
<dholbach> ogra: ROCK ON
<Kamion> heno: probably - I'll have a look at that now
<welshbyte> gnomefreak: gdm :)
<gnomefreak> welshbyte: i am kind of glad you said that :)
<gnomefreak> ty
<heno> That way we can tell people: wait 20 sec. press F5, the press 3 and Enter
<dholbach> infinity: thanks a lot
<heno> Kamion: that is at least a clear roadmap for them
<heno> as opposed to 'you might hear a sound'
<ogra> dholbach, :)
<heno> Even if we get it working there will still be computers where it fails
<slomo> infinity: please give-back gnome-python and gnome-python-desktop on ia64/sparc
<Kamion> heno: so, just to confirm, I can change the menu item names per bug 58836 now?
<Ubugtu> Malone bug 58836 in gfxboot-theme-ubuntu "F5 options need to be linked to the right casper options" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58836
<heno> Kamion: yes please
<Kamion> heno: for reference, the option names need to be the same across all flavours, at the moment
<Kamion> the above bug is fine with that, this is just a note in case of future requests
<Kamion> heno: "Screen reader" or "Screen Reader" (etc.)? you have "High Contrast"
<Kamion> I think I'll probably use title case throughout to be consistent
<heno> Kamion: cool
<Kamion> "On-Screen Keyboard" replaces "Motor Difficulties - pointing devices"?
<heno> Kamion: by 'the option names need to be the same' do you mean that Kubuntu/Xubuntu will have an on-screen keyboard entry
<heno> which does nothing? (I'm fine with that)
<heno> Kamion: it does, yes
<heno> The scanning devices one has been abandoned permanently
<CyberSnooP> Hi! Is upgrading to edgy using update-manager supposed to work now?
<Kamion> heno: I mean that at the moment I don't have the facility to call it "On-Screen Keyboard" in one and "On-Screen Football" in another
<heno> Kamion: ok, np. but you can leave options out?
<Kamion> at the moment Kubuntu/Xubuntu will have the redundant menu items, though that's somewhat easier to fix
<Kamion> I'll see what I can do there
<heno> either way It's not a big deal. We hope to add all those features by Edgy+1 in K/Xubuntu
<radone> I got error - bash: /dev/dsp: Permission denied
<pitti> radone: you aren't in the 'audio' group probably
<radone> groups ..... audio ....
<radone> crw-rw---- 1 root audio    14,   3 2006-09-05 15:40 dsp
<pitti> radone: what does 'id' show for you?
<pitti> radone: (and, btw, this is an #ubuntu question)
<radone> groups=.....,25(floppy),29(audio),....
<radone> ok, thanks. I am just searching for any app where can I read and write sound stream
<radone> this has last reboot worked perfectly
<radone> but not now :-/
<radone> and after running my app it reports this error
<seb128> ogra: thank you for the gnome-screensaver update
<infinity> slomo: Those both failed again on a retry.
<ogra> seb128, as promised ;)
<elmo> how does /dev/loop/1 get created?
<slomo> infinity: yeah, was too fast... pygobject was already built to fix the build failure but not available to the buildds yet :(
<slomo> infinity: sorry for that
<infinity> elmo: losetup?
<elmo> or should I just mknod it?
<elmo> hmm, losetup
<pitti> elmo: or mount -o loop
<infinity> elmo: Which should be run by mount transparently.
<pitti> however, we currently do not load the loop module automagically
<elmo> I love how the manpage refers to /dev/loop0
* _ion had hoped smartpm <https://features.launchpad.net/distros/ubuntu/+spec/smartpm> would have been ready to use as the default package manager in edgy. :-\
<infinity> pitti: Err, we don't?  I've never had troubles with loop moiunts.
<elmo> hmm, ok
<pitti> infinity: I always need a modprobe loop...
<elmo> so 'mount -o loop' doesn't work
<infinity> pitti: Weird.
<elmo> this is the second loop mount if that matters
<infinity> elmo: Wait, is this a udevish system, or static dev?
<infinity> elmo: You might just need "cd /dev && ./MAKEDEV loop" if it's static.
<ogra> ogra@edubuntu:~$ ls /dev/loop0
<ogra> /dev/loop0
<elmo> /home/james/edgy-alternate-amd64.iso on /home/james/mount1 type iso9660 (rw,loop=/dev/loop/0)
<elmo> wow that's special
<elmo> /home/james/edgy-alternate-amd64.iso on /home/james/mount2 type iso9660 (rw,loop=/dev/loop1)
<ogra> that appears after i modprobe loop here
<elmo> infit's a normal ubuntusystem
<elmo> damn it, inf<tab> should work
* pitti has /dev/loop[0-7]  and no /dev/loop/
<infinity> I'm offended by infinito's presence without participation.
<ogra> infinity, he's busy in -motu ...
<infinity> ogra: I've never seen him speak here, and he breaks tab completion. :P
<ogra> right :)
<Hobbsee> infinity: change your nick then :P
<Hobbsaw> Alright.
<Hobbsee> heh
* Hobbsee could boot you for that.  just for fun.
<Hobbsee> Hobbsaw: i'm suprised you didnt go for calvin or something.
<Hobbsaw> Not a war you want to get into.  I think I have more l33t powers with chanserv than you.
<Hobbsaw> Though I'm ont positive.
<Chipzz> _ion: what's so great about smart?
<Hobbsaw> s/ont/not/
<StevenK> Hobbsee: Try and boot Hobbsaw and hit yourself instead?
<Hobbsee> infinity: same level of access, it seems.
<infinity> Ahh, cool.
<_ion> chipzz: It resolves complex dependencies very intelligently, where apt fails.
<infinity> Shows how much I look or care.
<Hobbsee> infinity: heh.  
<_ion> chipzz: Of course, it has its own issues (which is probably why it is not the default in edgy ;-) ).
<Chipzz> _ion: then fix apt?
<infinity> _ion: Whic his why we always tell people to use frontends like dselect, aptitude, synaptic, etc.
<infinity> _ion: apt's never been good at complex upgrade scenarios, and never will be.
<Chipzz> _ion: I cannot believe you're about to throw out apt for exactly one *extremely* silly reason
<Chipzz> that's just stupid
<infinito> infinity:sorry, i've got this channel in autojoin... im gonna remove it
<infinity> infinito: I was joking. :)
<infinity> infinito: Though if you really have no reason to be here, fixing my tab completion will make elmo happy. ;)
<pitti> infinity: what about 2^infinity-1? :)
<pitti> infinity: that would give us tab completion with just one letter
<neuralis> Chipzz: relax, read https://wiki.ubuntu.com/SmartPackageManager etc
<infinito> bye and sorry ;)
<infinity> pitti: That's still infinity, logically, even if it isn't to crazy mathemeticians and pyshicists. :P
<infinity> physicists, too.
<pitti> infinity: but it's the most important number in infinite improbability drive science...
<Hobbsee> "once you're so far to the right, nothing can save you" yes...
<Hobbsee> infinity: a far better nickname would be fortytwo.
<neuralis> infinity: pyshicists. like shicists, but written in python. also, we should talk later today. how are things looking?
<Chipzz> neuralis: yes, I just read that
<Riddell> Kamion: Kubuntu should still have "Motor Difficulties - pointing devices"
<infinity> neuralis: When is "today" for you?  It's pretty much over for me.
<Chipzz> and it doesn't give me much good reasons to switch to smart
<neuralis> infinity: ah, right. what utc offset are you again?
<infinity> neuralis: If we could make a date for sometime in my tomorrow, that'd be grand.  Say, in about 12 hours? :)
<Hobbsee> hehe
<infinity> neuralis: I'm utc+10
<Hobbsee> infinity: oh are we?  i thought we were in +11....
<Chipzz> if apt doesn't handle complex upgrade scenario's, then that's a bug that should be fixed, not a reason to throw away the child with the bathwaiter
* Hobbsee cant keep track.
<Chipzz> bathwater
<infinity> Hobbsee: date --rfc-822
<neuralis> Chipzz: a lot of smart people working on package management disagree with you
<Hobbsee> infinity: point.
<Chipzz> neuralis: more importantly, I think switching to apt may create a giant rift with debian, and make the situation wrt debian even sourer
<Chipzz> to smart
<infinity> Bouncing between smart and apt should be nearly transparent.
<infinity> At least, that's one of the upgrade goals.
<infinity> They should co-exist peacefully.
<neuralis> infinity: lateish your tomorrow is better here. how's 16ish or so hours from now?
<infinity> Afterall, apt's just an acquisition method, not a package manager.
<Chipzz> infinity: as I understand it, apt is to be deprecated in the end?
<infinity> neuralis: Sounds good to me.
<neuralis> infinity: deal
<infinity> Chipzz: Eventually, yes.
<infinity> Chipzz: I've been fighting against it being replaced until smart can give us a smooth upgrade (and retreat) path.
<infinity> Chipzz: Which, for most things, isn't a big deal, since it's the dpkg database that matters.  But for some things (like the auto-dependency removal DB), you need ot be able to sync.
<Chipzz> sometimes I wonder what it is with opensource people throwing away stuff instead of fixing it
<giftnudel> Chipzz: it's sometimes easier to write sth. from scratch then to try to fix something
<infinity> Chipzz: You've not seen the apt codebase.
<Chipzz> infinity: wasn't the auto-dependency removal introduced into apt recently?
<infinity> Chipzz: Yeah, it was a recent addition.  Yanked from aptitude and massaged into apt.  I assume mvo intends to make it play nicely with smart too.
<infinity> Chipzz: At any rate, it takes a special kind of insanity to wrap one's head around apt's code.  I suspect it's been responsible for driving both mdz and mvo completely mad, and perhaps even jgg, who originally wrote it.
<infinity> Chipzz: There are very valid reasons for rethinking it from the ground up.
* mvo suspects jgg was mad before ;)
<infinity> mvo: Well, this is possible. :)
<_ion> :-)
<Hobbsee> mvo: or seriously on crack, take your pick :P
<Chipzz> possibly :)
<Chipzz> but fwiw, imho dpkg needs improvement a lot harder than apt does
<infinity> mvo: So, since you appear to be following this, are you planning to make the auto-dep-removal magic seamlessly work between apt and smart, for easy swapping of tools without functionality loss?
<infinity> mvo: Cause that would be some kinda spiffy.
<mvo> infinity: hopefully, but smart does not have the magic yet (also there is a experimental patch)
<pitti> mvo: does aptitude and apt use the same auto-removal db now?
<pitti> s/does/do/
<infinity> mvo: But once it grows the magic, you can make it sync with apt (or just use the same DB, ideally), so there's no data loss in switching?
<mvo> pitti: not yet :( also aptitude will update the apt database
<Kamion> Riddell: erm, ok; can you agree this with heno, because he seemed to think differently in bug 58836?
<Ubugtu> Malone bug 58836 in gfxboot-theme-ubuntu "F5 options need to be linked to the right casper options" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58836
<mvo> infinity: yes, that is the plan. smart will be able to import it
<infinity> mvo: s/import/sync/, hopefully, so bouncing back to apt is also possible?
<Kamion> Chipzz: generally, my view is that dpkg needs enhancements, while apt needs fixes
<infinity> mvo: I'd feel much more comfortable about tossing smart in as the default package acquisition tool if we can easily use both for a while, and switch back if we have to.
<mvo> infinity: well, not sure if it will do that automatically, but it will be possilbe too with a command 
<Riddell> heno: what do you mean by "mouse keys"?
<heno> Riddell: you can use the numeric keypad to move the mouse cursor around
<heno> I'm sure KDE has it
<Chipzz> is there a comprehensive list of issues with apt somewhere actually?
<Kamion> heno: it's an X feature
<Kamion> shift-numlock
<heno> We had that switched on in the same profile as sticky keys in Dapper
<heno> Kamion: Right, AccessX
<heno> Both KDE and Gnome have config guis for it, but many other DEs don't
<Riddell> heno: we also have kmousetool which clicks the mouse when you hover over something, does that have an equivalent in one of the ubuntu profiles
<heno> Riddell: yes, I'd like to make that a global X feature too
<heno> Along with mouse-shaking steadying
<heno> I spoke with rodarvus about it at the sprint
<heno> Edgy+1 material I think
<Kamion> heno: ok, I've added an isolinux.cfg option to control the set of access options presented
<heno> Kamion: cool, thanks. I can find it in the gfxboot sources if I want to have a look?
<Kamion> heno: no, in gfxboot-theme-ubuntu
<heno> ok, cool
<Kamion> very little is done in gfxboot directly
<Kamion> http://people.ubuntu.com/~cjwatson/bzr/gfxboot-themes/Ubuntu/
<Kamion> heno: what accessibility options should be presented in Edubuntu?
<pitti> okay, so the official requestsync script on people.u.c/~pitti/scripts does not require a local MTA any more
<pitti> Hobbsee: ^ thanks for that
<Riddell> heno: I think Kubuntu should have 'Keyboard modifiers' with sticky keys, and Keyboard and Mouse Modifiers with sticky keys and keyboard mouse and kmousetool
<Hobbsee> pitti: :)
<heno> Kamion: As far I remember the tools were left out for space reasons (orga?)
<heno> Kamion: so that just leaves themes (possibly) and key modifiers
<heno> Riddell: Sounds good.
<Riddell> Kamion: 58836 updated
<Kamion> Riddell: thanks
<Kamion> Riddell: sorry, I can't have different option names at present
<Kamion> the set listed there for Ubuntu is the set that it's currently possible to have
<doko> seb128: can you erase RW CD's using nautilus?
<Riddell> Kamion: hmm, guess we'll just have the 0,1,2 and 3 then and turn on mouse stuff for three
<Kamion> Riddell: yeah, I may be able to change this in future but I'm already running rather over time today for gfxboot-theme-ubuntu hacking
<slomo> infinity: we could try again gnome-python* now on ia64/sparc if you want ;) the pygobject binaries should finally be available there
<Kamion> Riddell: btw, I added an option to ubiquity to configure where grub is installed, which will need some KDE work
<Kamion> I left TODOs in the appropriate places
<Riddell> Kamion: ok, will try and get to that this week
<infinity> slomo: Are you sure? :)
<Kamion> Riddell: thanks
<slomo> infinity: if not the publisher must've eaten it ;) at least the sparc binary is on archive
<infinity> slomo: Let me guess, gnome-python-desktop depends on gnome-python, so I need to wait a publisher cycle to do it? :)
<infinity> slomo: Looks like.
* infinity waits.
<slomo> infinity: yes... *sigh* only a problem because the x86 buildd already built the arch all packages it seems...
<infinity> slomo: No big deal.
<jdong> infinity: why are some of my successfully built backports not showing up on archive?
<jdong> infinity: namely xchat and kopete
<infinity> jdong: kopete is in the NEW queue.  Not sure about xchat.
* infinity does some -backports NEW processing.
<jdong> :)
<Kamion> jdong: you saw my note about the other effect of the soyuz backports bug, didn't you?
<Kamion> namely that you only get binaries for one architecture for any given backport
<jdong> Kamion: aah, really?
<jdong> yikes
<jdong> :)
<Kamion> Highlander syndrome
<jdong> Kamion: i thought it said I can't do multi-binary-package backports yet
<jdong> lol
* jdong walks away in shame
<Kamion> multi-binary should work no worse than single-binary
<infinity> Kamion: Err, what?
<Kamion> sorry, by binary I meant binary upload, not binary package
<infinity> Kamion: We're not publishing all 6 arches correctly?
<Kamion> infinity: nope
<infinity> Kamion: AWESOME.
<Kamion> good, isn't it
<infinity> Kamion: So, there's no point in my processing NEW for -backport, I take it?
* mjg59 fixes powernowd so it doesn't do stupid on decent CPUs
<Kamion> the second and subsequent binary uploads get ">= version already in backports"
<Kamion> infinity: not really, no - most of them will bounce
<Kamion> well, you could process one of them. :-)
<infinity> Kamion: Wait, this bug must be new, though.
<Kamion> infinity: it's bug 58144
<Ubugtu> Malone bug 58144 in soyuz "Backport is rejected if an older backport is already there" [Critical,In progress]  http://launchpad.net/bugs/58144
<Kamion> it's been there for ages - but it ONLY affects backports
<infinity> Kamion: Cause when you did the first wave of backports, I was NEWing libraries to get their dependants to build, and that was going fine.
<Kamion> infinity: oh, hmm, dunno then
<jdong> mjg59: powernowd.... can we make it poll a bit faster, or would that break some CPU's
<mjg59> jdong: Should now be ondemand for anything vaguely recent, which avoids the polling necessity
<jdong> mjg59: oh really? cool
<infinity> Kamion: Maybe that worked purely by chance, since new->accepted of all 6 arches at once is kinda special.
<mjg59> Hm.
<seb128> doko: yes, doesn't work for you? does it work with cdrecord?
<mjg59> There must be /some/ way of getting an interrupt when a Thinkpad hotkey is pressed
<doko> seb128: didn't try, never mind, just found some older CD/RW's
<infinity> Kamion: Anyhow, I'm going to leave the dapper queue alone until that bug is fixed.  Thanks for the heads-up.
<Kamion> Mithrandir: what's the current state of sane-installer-keyboard? I'm about to dive into it ...
<Mithrandir> Kamion: needs d-i upload and more testing.
<jdong> wow, the eclipse CDT really redefines the meaning of slow and then some, doesn't it?
* jdong just waited 20 seconds on a core duo for it to autosuggest cin.get()
<Kamion> Mithrandir: and the ubiquity code; I don't think we should go ahead with it unless both d-i and ubiquity are doing the same thing
<Kamion> we have a day and a half here, so ...
<Mithrandir> Kamion: well, I can give it all of tomorrow since my live-cd-write-as-you-go isn't feasible after all.
<Kamion> Mithrandir: I've got nothing else to do until FF except rescue other specs, and I have most relevant experience for this one. :-)
<Kamion> Mithrandir: so we can tag-team
<Mithrandir> Kamion: sounds good to me.
<Kamion> infinity: what's happening with live-cd-stacked-filesystems and larger-livefs?
<Kamion> I'd really like to have larger-livefs landed by FF ...
<infinity> Kamion: Finishing up the former tomorrow when I wake up.  When it's done, the latter is just a question of adding a new seed.
<Kamion> infinity: hmm, it's going to be pretty tight to get the necessary support into cdimage and ubiquity before FF
<Kamion> we'll see what we can do, I suppose ...
<infinity> Kamion: Which one would you prefer I try to hack on?  If I finish my side before you wake up, I can tackle another chunk.
<Kamion> infinity: if you can tell me in advance how the filesystems are going to be exported from the buildds, I can do the cdimage/ubiquity stuff in advance
<Kamion> if the former is achieveable, I'd prefer that it happened first, since then as you say the latter is reasonably trivial
<infinity> Kamion: 01_$mumble.squashfs through NN_$mumble.squashfs
<Kamion> what's $mumble?
<Kamion> 01_base, 02_desktop, that sort of thing?
<infinity> Yeah.
<Kamion> o
<Kamion> ok
<Kamion> iwj: how's the Breaks stuff coming along? just wondering if we're going to need to back it out or forbid packages from using it in edgy
<Kamion> seb128: were those patches Henrik sent for sudo-admin-atspi acceptable?
<pitti> hi lloydinho 
<Tonio_> Kamion: ping ?
<Kamion> Tonio_: i
<Kamion> hi
<Tonio_> Kamion: hey :) While mdz isn't there, can you revu UVF Exception request for katapult please ? bug 58213
<Ubugtu> Malone bug 58213 in katapult "0.3.1.2svn20060711 > 0.3.1.3 UVF Exception Request" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58213
<Tonio_> it closes 2 major bugs making it simply unusable
<pitti> lloydinho: got my mail and SMS?
<Kamion> Tonio_: I've added it to my list :-/
<Tonio_> Kamion: okay I'll wait then, thanks !
<seb128> Kamion: I've looked at the bugs and patches but didn't have time to play with those yet. upstream has some valid concerns about them and delayed that for next cycle so I'm not sure yet, I'll try when GNOME 2.16.0 is packaged (which should be done today or tomorrow morning)
<seb128> Kamion: edgy has not so many sudo running app, g-s-t, update-manager, gnome-app-install UI run as user now 
<Kamion> seb128: ubiquity is a big one, and it can't change
<seb128> ah, right, good point
<Kamion> at least not without some major reengineering
<seb128> k, it's next on my list after GNOME 2.16.0 (and some mails replying), I'll let you know when I've tried them
<Kamion> thanks
<iwj> Kamion: Hi.  I have a mail from mvo about update-manager which is vaguely relevant.  Aside from that, I'm working on testing my apt changes.
<seb128> np
* Kamion ponders sucking in unicode-data to save a big chunk of space in console-data
<Kamion> iwj: righto, thanks. Let me know if rescue efforts are needed
<iwj> Willdo.
<iwj> Is mvo about ?  He doesn't seem to have replied to my email ...
<Kamion> mvo_: ping
<infinity> Err, how does one reboot (short of hitting the power switch) after upgrading to upstart?
<infinity> shutdown/telinit can't connect to init.
<slomo> infinity: reboot -f
<jdong> infinity: sync; reboot -f
<mvo_> Kamion: pong
<bddebian> Howdy folks
<jdong> or sysrq-u, sysrq-s, sysrq-b
* infinity shudders.
<Amaranth> slomo, jdong: Of course, that's basically the same as hitting the power button
<Kamion> mvo_: ^-- iwj
<jdong> infinity: the sysrq method is a bit safer
<jdong> at least it does a remount-ro
<tepsipakki> iwj: hi, does #47701 have a chance for edgy?
<Kamion> infinity: Keybuk said he's planning to fix that by special-casing shutdown to be able to talk to sysvinit
<tepsipakki> bug 47701
<Ubugtu> Malone bug 47701 in firefox "enable middlemouse.contentLoadURL" [Medium,Unconfirmed]  http://launchpad.net/bugs/47701
<iwj> mvo_: Ah, hello.
<iwj> tepsipakki: This has been discussed in ubuntu-devel.  I don't like the current behaviour either but consensus seems to be against us.
<jdong> hey, does acpi-support's suspend scripts umount anything?
<mvo_> hello iwj, Kamion. sorry, I missed the context. whats up?
<iwj> mvo_: Breaks might or might not be.
<iwj> Did you see my mail about update-manager ?
<Kamion> tepsipakki: while personally I'm with you and iwj, the reason given originally was that if you're trying to middle-click on a URL to open it in a new window/tab and you miss, whatever random stuff happens to be in your X selection gets loaded by firefox
<tepsipakki> kamion: yes, I've seen that ;)
<mvo_> iwj: yes, I have seen it. your LD_LIBRARY_PATH idea is a bit scary, but I guess it would work
<iwj> mvo_: Well, it just seemed an easy way to make it work and it's what LD_LIBRARY_PATH is for, in some sense.
<iwj> The alternative would be some weirdo rebuild but I didn't really want to suggest that.
<mvo_> iwj: if we really really want to have breaks working for the dapper->edgy upgrade, then this is the way to do it
<mvo_> iwj: the alternative would be to use them onyl for edgy->edgy+1
<lloydinho> pitti, sorry I was in the middle of an interview.. :-)
<tepsipakki> iwj, Kamion: maybe I can paste your responses to the bug, and rename it so it could be left as a placeholder?
<infinity> Kamion: Would have been nicer if he did that before he forced the upgrade on me. :)
<lloydinho> pitti, so I won't be in Dresden before tomorrow, I hope that's okay. Sorry for the late reply..
<infinity> dholbach: My sticky notes are back.  I love you! ;)
<Kamion> tepsipakki: sure
<iwj> mvo_: Right.  So really I think it has to be your decision since you have to decide whether you want to do that somewhat mad thing in u-m.
<slomo> infinity: hrm, same problem for pygtk now at least on amd64 :(
<iwj> tepsipakki: Of course, thanks.
<Kamion> It doesn't seem too bad at this point to say that we'll only allow Breaks in packages as of edgy+1. The downside of course is that we need to make sure somehow that we've caught all the problems or we won't get it until edgy+2, etc.
<iwj> Yes, quite so.
<iwj> doorbell
<mvo_> iwj: I will have a long look at the source code in the dist-upgrader today and try to think about how it could be integrated without being too messy. does that sound ok?
<iwj> back
<iwj> (That was the veg box arriving.)
<iwj> mvo_: Thanks, that would be very helpful.
<iwj> I'm worried by Kamion's point about testing, if we punt on it.
<iwj> Also, in general you want to do the upgrade with the latest apt or what have you anyway, so this mad scheme isn't wasted effort :-).
<math_b> Concerning upstart, I saw no dependency on the initscripts package, is it a bug ? 
<Kamion> math_b: I added that in upstart-compat-sysv this morning
<math_b> thanks !
<dholbach> infinity: I love you too, honey!
<Mithrandir> Kamion: actually, won't we have to not use Breaks until we've released another LTS?
<Kamion> Mithrandir: not if the upgrade tool can cope
<Tonio_> Kamion: thanks for uvf reviewing
<Kamion> pitti: FYI, I'm syncing unicode-data straight into main - it's just data, and it's just split out from console-data
<Kamion> (it'll be a new build-dependency of console-data)
<_ion> Where (or by whom) is the process of migrating stuff from rcS to upstart jobs coordinated?
<pitti> Kamion: sure, sounds good
<pitti> lloydinho: alright, I got your sms
<pitti> lloydinho: see you tomorrow!
<lloydinho> pitti: Cool! See you!
<Kamion> _ion: Keybuk's on holiday today - better ask tomorrow
<_ion> kamion: Ok, thanks.
<pygi> hey pitti 
<pitti> hi pygi 
<pygi> pitti, have I told you about my little DVD experiments? :)
<pitti> pygi: no, what's about it?
<pygi> pitti, I tricked libburn to produce a usable dvd :)
<pitti> cool
<pitti> pygi: by wrapping growisofs, or entirely separate code?
<pygi> pitti, by following steps:
<pygi> 1)blank disc by growisofs
<pygi> 2)burn disc using libburn code
<_ion> 4)PROFIT
<pygi> _ion, ?!
<pygi> sivang, poke?
<sivang> pygi: poyke
<_ion> pygi: Just a joke. One needs to be familiar with the slashdot meme to get it. :-)
<pygi> sivang, can we have packages in universe this weeks pls? :)
<pygi> _ion, why 4)? isn't it 3? :P
<_ion> pygi: 3) is "???"
<pygi> _ion, ah, nothing :P
<sivang> pygi: do you have anything done already?
<sivang> pygi: I mean, some sort of skeleton package?
<pygi> sivang, ehm, well, the code?:)
<pygi> no :P
<_ion> pygi: It originates from http://en.wikipedia.org/wiki/Underpants_Gnomes#The_gnomes
<sivang> pygi: heh
<pygi> sivang, what? :)
<sivang> pygi: okay, toss me a link to a tarball
<pygi> sivang, no tarballs :P
<pygi> svn co http://libburn-svn.pykix.org libburn
<pygi> that should work :)
<sivang> pygi: but then we get the .svn crap in the package :-)
<pygi> sivang, remove it :P
<_ion> sivang: svn export ../foo-1.2.3; cd ../foo-1.2.3; dpkg-buildpackage ...
<sivang> pygi: you should try and alos release "upstream" tarballs :-)
<Mithrandir> debuild -i ftw
<sivang> _ion: right
<pygi> sivang, one day :P
<_ion> mithrandir: Yeah, debuild rocks. :-)
<sivang> Mithrandir: what's ftw ?
<Mithrandir> for the win.
<Mithrandir> sivang: -i makes debuild strip out .svn directories and similar.
<sivang> Mithrandir: right, I just didn't get the ftw :-))
<sivang> Mithrandir: thanks
<pygi> sivang, once there is stable version, then you'll get tarball :P
<sivang> pygi: ah :p
<pygi> sivang, libburn and libisofs might be called 0.2SVN (stable release will be 0.2.1) and cdrskin is 1.5SVN (I don't know what the stable release will be :P)?
<pygi> sivang, ergh, actually, the cdrskin is 1.4SVN
<sivang> pygi: I'll see what I can do, am not promising anything for this week though...I'm quite busy with stuff
<pygi> sivang, I know, but this is important :)
<sivang> pygi: I have to clear out some stuff, once I do, I'll sit to see about it's packaging. Should be quite fun.
<pygi> sivang, oki, thanks :)
<sivang> pygi: my pleasure.
<slomo> infinity: :( and now gnome-python-desktop ftbfs because of the same problem with pygtk on those two archs... what a nightmare
<Riddell> pitti: any chance of main reviewing python-qt4 sometime this week?
<pitti> Riddell: yes, if you need it
<Riddell> would mean hwdb wasn't depending on stuff in universe
<infinity> slomo: Don't worry about it, dude, I'll take care of it by morning.
<infinity> slomo: Patience is a virtue. :)
<Hobbsee> infinity: patience?  what's that?
<slomo> infinity: ok :) only wanted to help you... and i have a feeling that they let most of gnome FTBFS on those archs again ;)
<infinity> slomo: Yeah, new GNOME is always painful.  I'll unsnag it tomorrow.
* infinity needs to head to bed.
<slomo> infinity: sleep well :)
<Hobbsee> hmmm...yeah...bedtime...
<pygi> Hobbsee, night
<dholbach> infinity: good night!
<dholbach> Hobbsee: night Hobbsee
<jdong> bed time, it's bright and early
<jdong> :)
<Hobbsee> no it's not...
<Hobbsee> i live in infinity's timezone.  where ti's definetly time for bed.
<pygi> Hobbsee, just australia :)
<Hobbsee> pygi: heh.  what are you saying. that it's always time for bed here or something?
<pygi> Hobbsee, lol, no :)
<jdub> Hobbsee: putting posters up at club mac yet?
<Hobbsee> jdub: no.
<jdub> Hobbsee: SLACKEUR!
<Hobbsee> jdub: have you any idea how much i even get there?
<jdub> it's club mac
<jdub> of course you don't go
<Hobbsee> jdub: indeed.  pia was about the last person i expected to be calling me at that point
<Riddell> Kamion: I'd say you could merge abattoir's oem-config into your branch now
<Riddell> Kamion: http://muse.19inch.net/~abattoir/bzr/mainline/
<bluefoxicy> uuuuugh it's 11:30 why am I up
<Kamion> Riddell: cool, will do
<_ion> Here it's 18:30. :-)
<neuralis> neat, i'm pulling from cdimage.u.c at 95mbit/s
<heno> seb128, dholbach: obviously feature freeze is drawing near. Just wanted to check: will you be happy to take some patches from me, say tomorrow, for the menu layout of the access stuff? (just to start onboard and orca)
<dholbach> heno: so changes to the orca and onboard package?
<dholbach> heno: onboard and virtkey are in NEW atm.
<heno> dholbach: yes, but also to the gnome assistive technology pref panel (to move it's menu entry and add a checkbox)
<heno> dholbach: will look something like this: http://people.ubuntu.com/~henrik/images/access-sub-menu.png
<mjg59> Seveas: Around?
<Hobbsee> mjg59: unlikely.  he hasnt been before this
<dholbach> heno: did you talk to sabdfl about that before?
<heno> dholbach: no, just mdz
<heno> dholbach: I'll email sabdfl
<dholbach> because he had visions for the menu and he was the last instance to ask last time
<heno> right
<seb128> heno: what dholbach said
<heno> seb128: ok, thanks. I'll get clarification
<seb128> np
<zul> everything is happy
<zul> oops..
<iwj> OK, I give up.  I tried to make a private apt archive area but apt says `Ign' for it and I can't persuade it to say why.
<jdong> iwj: it's because you haven't uploaded firefox 2.0b2 packages to edgy for me to play with yet :)
<iwj> jdong: Uh-hu.
<Kamion> iwj: did you gzip the Packages/Sources files? Common thing I forget ...
<iwj> You have to gzip them or it can't cope ?  FFS
<Kamion> apt doesn't like them uncompressed and isn't very helpful about it
<_ion> iwj: falcon is very handy, it does all the dirty work.
<iwj> That doesn't seem to have helped.
<jdong> tsk tsk tsk... I'm telling you.... :)
<iwj> Why can't I get this SHIT-FOR-BRAINS program to give me an ERROR MESSAGE ?
<iwj> _ion: What is `falcon' ?
<Kamion> iwj: I think you're supposed to use that nethack GUI frontend to generate your apt archives
<iwj> Kamion: That was what I was thinking ...
<LarstiQ> zul: hmm?
<zul> LarstiQ: sorry misfire from last night
<LarstiQ> zul: ok :)
<Seveas> mjg59, I'm here now but not for very long
<_ion> iwj: http://www.kaarsemaker.net/software
<neuralis> Kamion: is lvm in d-i known broken in knot-2? i see a grub lvm bug, but could've missed an installer one
<iwj> _ion: ??  Not in Debian or Ubuntu !
<_ion> iwj: Unfortunately.
<_ion> Its repository has contained the debian packaging forever.
<iwj> You can understand my reluctance.
<Kamion> neuralis: yeah - fixed just afterwards. to see if it's the same bug, check whether lvm2.deb is on the CD (it probably isn't)
<_ion> iwj: Yes, but i sincerely recommend it; it is far easier to use than anything else i've tried.
<Seveas> iwj, 'falcon' is ~9 months old now, didn't yet attempt to have it included
<mjg59> Seveas: I've been looking at your branch
<Seveas> mjg59, cool! How crackful was it?
<mjg59> Seveas: I've tidied up the progress bar pulsation slightly - it wasn't drawing the ends correctly
<Kamion> there must be a bug about apt not recognising ungzipped index files - I noticed that years ago
<mjg59> That is, there should have been two frames drawn at each end rather than just one, otherwise it looks jerky
<Seveas> mjg59, true
<Seveas> I'll be pushing a few more revisions tomorrow, support for a -v switch and a kernel command line argument so it can be made to shut up by default but verbose if wanted
<Seveas> and some packaging things so creating themes will be easier
<mjg59> Seveas: Ok - can you repull from mainline?
<Seveas> will do
<mjg59> I'm just pushing my changes
<neuralis> Kamion: lvm2_2.02.06-2ubuntu2_amd64.deb and matching udeb are there. i wonder if it just failed to load properly; i'll retry.
<iwj> Seveas: I don't need easy to use, I need it to work and really what I need is for apt to explain why it is `Ign'oring me.
<Seveas> iwj, ign is usually for missing .pgp keys
<Seveas> or Release.gpg files
<Seveas> (falcon also works by the way, I know several people who use it and are happy with it -- if you want something in Ubuntu proper, I'd suggest reprepro)
<iwj> Seveas: Thanks for the tip about .gpg; I had a .sig instead.
<neuralis> Kamion: lvm configurator loads and runs, but is still broken; doesn't allow re-entry into lvm group config, and doesn't add the chosen lvm vg(s) to the main partitioning screen
<Kamion> neuralis: ok, partman-lvm bugs would be good; we may just need to sync from upstream
<neuralis> Kamion: ok, filing.
<ivoks> neuralis: this happens on all linux systems
<neuralis> ivoks: uh, no. if lvm doesn't add the vgs to the main partman screen, it's unusable.
<mjg59> Seveas: So do we get a test 256-colour theme soon?
<ivoks> neuralis: i agree, but same thing happens on fedora, too :/
<neuralis> ivoks: then their lvm is broken, as well. this works fine in dapper.
<ivoks> neuralis: if you don't initialize lvm and remove all vg before creating new one, installer segfaults :/
<iwj> 7967  write(2, "Signature made Tue Sep  5 03:33:"..., 70) = -1 EBADF (Bad file descriptor)
<Seveas> mjg59, that's part of the things I plan for tomorrow
<mjg59> Seveas: Rock
<Seveas> 256 colors, png progressbar
<Kamion> ivoks: I don't think it's possible for a partman bug to "happen on all Linux systems"
<Kamion> seeing as it's inherently specific to Debian and derived distributions
<ivoks> Kamion: i don't think it's a partman bug
<Kamion> ivoks: I don't understand how you've got enough information from what neuralis said to conclude that
<mjg59> If Edgy is a colour, what colour is edgy?
<ivoks> Kamion: it's not from what neuralis said, it's from exp. of lots of lvm installations :/
<FunnyLookinHat> maroon...  with orange blaze.
<Kamion> ivoks: please don't conflate all possible LVM bugs into one
<ivoks> Kamion: :) ok
<Kamion> I'm quite sure there's room for multiple issues in there
<neuralis> Kamion: his theory is easy enough to test, i'll let you know in a minute.
<Kamion> neuralis: thanks
<Kamion> Mithrandir: did we figure out any way to port console-keymaps-tree to console-setup?
<Mithrandir> Kamion: just have console-setup build-depend on treetool (or whatever the tool making the decision trees is called), then generate the c-k-t as part of the c-s build?
<Kamion> (keymapper)
<Mithrandir> thanks, I always forget that name. :-)
<Kamion> "just" - hmm
<Kamion> well, I can try, but I'm worried about the timing
<Mithrandir> Kamion: how so?  It'll make the build even slower, but apart from that it'd work fine.
<Kamion> I mean that it's a day and a bit before FF and I'm not sure of the code :)
<iwj> Woohoo!  It works!
* iwj saves the runes in a file for next time.
<iwj> pycentral: pycentral rtremove: installed runtime python2.3 not found
<iwj> I can't remove or install python2.3, it seems.
<elmo> Kamion/mithrandir: is it known that knot-2's server profile is broken?
<Kamion> elmo: no
<Kamion> broken how?
<elmo> Spads: ?
<Spads> hi
<Spads> Kamion: oh, when I installed from alternative-i386
<Spads> I did "install server"
<Spads> and it popped up a warning that it couldn't find the file with the selections
<Seveas> iwj, that has been filed in lp about 50 times
<iwj> Seveas: No doubt the LP search is maliciously hiding it from me.
<Seveas> iwj, heh
<Seveas> it's often filed under the dist upgrader
<ogra> did it ever reveal something for you ? 
<Seveas> since it usually happens when people dist-upgrade from dapper
<Seveas> it's a pycentral bug though and most bugs are marked as duplicate of one filed on pycentral
<mjg59> \o/
<mjg59> Another piece of forum fanservice
<iwj> If I search `Bugs in Ubuntu' for `pycentral' it gives me bug 56690 and bug 51718.
<iwj> Yay, I killed the bug bot too.
<Spads> um, doesn't "fanservice" mean "drawing jiggling body parts to impress young male viewers"?
<mjg59> Spads: That's one form of it
<iwj> Anyway, neither of them are it.
<iwj> No packages matching 'pycentral' are published in Ubuntu.
<Kamion> python-central
<iwj> Oh, of course.
<Riddell> ogra: iz gtk bug with hwdb-client "ImportError: PyGObject version too old, 2.11.1 is required, found 2.12.0."
<ogra> meah
<iwj> python-central has one bug, 57795, which looks like something different.
<slomo> Riddell, ogra: upgrade to -0ubuntu2 of pygtk and pygobject... should fix this one
<slomo> Riddell, ogra: that is... 2.12.0-0ubuntu2 of pygobject and 2.10.0-0ubuntu2 of pygtk
<ogra> ah, so its not hwdb ...
<ogra> great
<mjg59> Woo I win
<mjg59> Can anyone remember where splashdown is actually triggered?
<Riddell> slomo: yep, that fixes it, thanks
<Riddell> mjg59: in gdm and kdm
<Kamion> Spads: thanks; that was an ubuntu-cdimage bug, which I've now fixed.
<mjg59> Riddell: Ta
<Spads> Kamion: thanks
<homegrown> anyone aware of issues with compiz after dodgy xorg patch?
<mjg59> No
<dholbach> good night
<neuralis> Kamion: in other news, the partman-lvm failure appears to be completely non-deterministic; i've been unable to pin it down across 24 reboots before giving up just now. 
<ogra> doko, ping
<doko> ogra: away in one minute ...
<ogra> doko, see pm
<zyga> re
<lisi> mjg59, hello, ping.
<lisi> mjg59, I would like to ask you about this bug: https://launchpad.net/distros/ubuntu/+source/ttf-bpg-georgian-fonts/+bug/55966, is it possibile to fix that ?
<zyga> I'm writing a paper about lisp, if you know and use lisp please /msg me and say what is the most annoying thing about that language and why; thanks
<pitti> Hello again
<HiddenWolf> hey pitti
<ivoks> hi
<ivoks> (i know, i'm late :)
<Lure> anybody knows where did old ubuntu-artwork package went - latest source only has distributor logo...
<LaserJock> Lure: I think themes have been split up into separate packages
<Lure> LaserJock: ok, so probaly *human* something (I am Kubuntu user, just need to borrow two icons ;-))
<LaserJock> Lure: something like that, I can't remember specifically
<Burgwork> yes, I believe it is icon-humans
<Burgwork> icons-human, rather
<Lure> LaserJock: got it: human-icon-theme
<Lure> thanks
<Treenaks> Burgwork: We are the icon-humans! We want human-icons!
<Treenaks> wait..
<Burgwork> Treenaks...
<Treenaks> Burgwork: sorry :)
<Burgwork> *grin*
<HiddenWolf> Burgwork, why is it never Burgfun? :)
<Treenaks> HiddenWolf: All Burgwork and no Burgplay makes jack a dull boy ?
<HiddenWolf> Treenaks: like that. :)
<pitti> G0SUB: I'm here now
<G0SUB> pitti: great
<hikenboot> hello all--question for you all...I am removing perhaps 50 packages from the live cd using apt-get remove `cat file.txt`...one or several of these packages are a causing x-window-system-core xbase-clients ubuntu-base ubuntu-live and ubuntu-desktop to be removed
<hikenboot> my question is how can i see the tree of dependencies so i can figure out which package is causing this
<pitti> hikenboot: apt-cache rdepends might be helpful
<pitti> hikenboot: or http://people.ubuntu.com/~cjwatson/germinate-output/edgy/rdepends/
<hikenboot> thanks...it does help a lot 
<hikenboot> why would ubuntu live depend on xh language pack? I thought the default was english?
<_ion> Wow, apport is really nice.
<pitti> _ion: \o/ :)
<zyga> pitti: apport can kill your machine after 'collecting' a program that died of memory consumption
<_ion> A thought: perhaps the UI should allow the user to read 'strings' output of the core dump, if she wishes to.
<pitti> zyga: I have a bug open about that
<pitti> zyga: repeated crashes, apport catches itself
<zyga> oh!
<zyga> recursive crash
<zyga> I once wrote a crash handler that pretty much got me fired :)
<pitti> yeah, I have to think about that case
<zyga> it required a hard reboot of a really critical production server that manages tons of transactions with real money
<zyga> (the funny thing is that it got there by accident, it was #ifdef'd)
<zyga> it tried to send an email every time a crash happened
<zyga> unfortunatly it looped and forked the system to death
<_ion> Heh.
<pitti> zyga: thanks for that hint with the firing, I'll think *really hard* :)
<_ion> "If something can go wrong, it will."
<zyga> _ion: heh, yeah
<zyga> but I've got a better job now and I'm more careful
<sivang> hmm, anybody recalls how to ident a block in emacs?
<sivang> (the keystorke, that is)
<Seveas> Probably C-m zd^fsdy^H^H^
<sivang> Seveas: I recall that a bit shorter sequence :-)
<pitti> wow, and people say that vim is complicated... (SCNR)
<sivang> but thanks
<johanbr> sivang: Could be Alt-Q, not 100% sure.
<johanbr> Actually, lower-case q in that case.
<pitti> johanbr: didn't that reformat a paragraph?
<zyga> sivang: ctrl-x, ctrl-c, vim
<sivang> zyga: HAH
<zyga> sivang: if you don't know how to use that abomination of an editor why do you do it?
<zyga> (when there are more sane things around)
* _ion was barely able to refrain from giving that advice. ;-)
<johanbr> pitti: In a "normal" mode, yes. I'm not sure what it does in C mode. In any case, doing "M-x fill-region" should work.
<zyga> I'm not flaming, just really curious
<sivang> zyga: I recalled that once, but I wasn't using it for a while and so forgot.
<sivang> zyga: I do like it.
<sivang> johanbr: I'm using a nice python mode, and it's different, still searching
<zyga> sivang: I see, I hope I did not offend you
<pitti> zyga: well, I have used emacs for years, and it's really not that bad
<zyga> pitti: did you hear of chinese slave workers?
<johanbr> sivang: Okay. Try typing "M-x fill", then hit the tab key for completion and see what that gives you.
<pitti> zyga: excuse me?
<zyga> pitti: they seem to have started to like it recently ;-)
<zyga> just flaming now, don't take me seriously
* pitti slaps zyga
<zyga> I had a long flame with the owner of my company about vim and emacs *AND* python and lisp
<seb128> zyga: emacs is a nice editor!
<pitti> seb128: emacs is a nice operating system, it just lacks a good editor
* pitti ducks
<pitti> sorry, guys
<zyga> hehehehe
<zyga> :D
<zyga> emacs *is* nice
<_ion> As far i'm concerned, grub is better than emacs, but ruby is better than kde.
<zyga> it's just that some people don't like how fricking huge it is
* pitti switches off his flaming mode and gives seb128 and sivang a big hug
<johanbr> emacs: "Text-editor for non-human beings". :)
<zyga> _ion: hehe
<pitti> _ion: chocolate is better than vanilla!!!
* zyga loves you too guys :)
<pitti> johanbr: to be fair, vim isn't for the faint-hearted either
<zyga> johanbr: :)
<zyga> btw, would you ack the spec to remove vim and emacs from the CD?
<seb128> zyga: at least you can type your text when it opens without having to know any magic :p
<zyga> pitti: but vim is nice for emacs users and gives them a hint on how to turn it off ;-)
<zyga> seb128: but then you have to know some magic to save it or quit
<seb128> zyga: no, emacs has a menu ;)
<pitti> zyga: ok, I think this really doesn't belong here
<zyga> seb128: gvim has a menu too, you can even use it like a menu
<zyga> ok ok :)
<zyga> I'm just having lots of fun now :)
<seb128> zyga: I didn't say it has not ...
<sivang> seb128++
<welshbyte> the first thing i remember from trying emacs all those years ago is thinking "what's a buffer?"
<zyga> oh boy I started a flame war, let's go to #ubuntu-offtopic
<seb128> I don't intend spending time on that discussion, so no need for that :p
<pitti> please not the 234829423th emacs vs. vim flamewar
<pitti> the kool boys use ed :-P
<hikenboot> any ideas? "xbase-clients" has a lot of dependencies  but i am removing none of them so i am not sure why this package is being removed any ideas?
<_ion> Bah, i modify the files with a magnet.
<sivang> pitti: haha
* zyga walks of to #ubuntu-offtopic
<pitti> hi pygi 
<pygi> hey pitti :)
<_ion> Hi keybuk
<Keybuk> heyhey
<cbx33> If i needed a script to run in the background when someone logs in, where would I add it?
<Riddell> Lure: seb128 should be a good place to start
<cbx33> ping seb128 
<seb128> cbx33: pong
<cbx33> seb128, remember that gconf line I wanted added?
<seb128> yeah
<seb128> did you open a bug?
<cbx33> does it need to be done before FF
<seb128> no
<cbx33> ok that's cool
<Lure> seb128: I have seen g-p-m/g-s-m uses gconf entries to know if suspend/hibernate is provided by system - but whic program populates these gconf entries?
<cbx33> I'll get that done as soon as I can
<cbx33> I also had another quick questions for you
<seb128> Lure: gnome-power-manager
<cbx33> oh btw, don't worry I repackaged pessulus from your sync :D
<seb128> cbx33: why repackaged? what is wrong with my sync?
<cbx33> nothing
<cbx33> I had to add a patch for the Student Control Panel Integration
<cbx33> did you want to review it?
<Lure> seb128: thanks - will check if it just trusts HAL or something else (we have complaints in KDE that HAL report hibernate as supported on some desktops)
<seb128> Lure: why would hibernate be supported on a desktop?
<seb128> wouldn't
<Lure> seb128: it could be, but there are many report that it does not work
<Fujitsu> But it works fine on quite a number, Lure.
<cbx33> seb128, I can send you my diff.tar.gz if you want it?
<Lure> seb128: from g-p-m source, I can only see that it needs both positive from hal as well as from gconf setting, but g-p-m does not look like to set gconf entry on its own
<seb128> cbx33: not today but maybe tomorrow yeah
<cbx33> seb128, what email address?
<Lure> Fujitsu: that is what bothers me - should we trust HAL or should we have any workaround 
<seb128> cbx33: seb128@ubuntu.com
<cbx33> ok cool
<Fujitsu> No, you should trust HAL.
<cbx33> vuntz has been with me all the way through
<seb128> Lure: /usr/share/gconf/schemas/gnome-power-manager.schemas
<cbx33> he's approved all my alterations
<seb128> good
<Fujitsu> HAL should be corrected, not the application, because a number of things work off HAL.
<Fujitsu> (although I'm not sure correction is necessary)
<cbx33> seb128, seeing as you're kinda involved in this now too
<seb128> cbx33: you can discuss that on #ubuntu-desktop with vuntz BTW, so we can participate ;)
<cbx33> for SCP I need to run a python listening script for dbus, everytime someone logs on
<cbx33> where do I place the link so it's gets run for every session login?
<seb128> cbx33: add a .desktop to /etc/xdg/autostart/ by example
<_ion> If it's a X login, perhaps /etc/xdg/autostart?
<cbx33> thakns seb128 
<seb128> cbx33: look to update-notifier by example for an example
<seb128> np
<cbx33> thanks seb128 
<Lure> seb128: thanks - so it is on by default, therefore HAL prevails
<seb128> Lure: which makes sense
<seb128> Lure: the default is to trust HAL
<Lure> seb128: yep, otherwise we should fix HAL
<cbx33> seb128, what does the terminal field invoke?
* _ion was happy to notice that smart-notifier installs a /e/x/autostart file in edgy, btw.
<seb128> not "otherwise", if HAL is wrong it should be fixed
<seb128> cbx33: if you want to start a gnome-terminal
<cbx33> nice _ion 
<cbx33> i see
<seb128> cbx33: like if you start mutt better to do it in a terminal
<cbx33> ah right i see
<cbx33> seb128, does this .desktop apply even if the script that is started is a non-GUI script
<cbx33> ie just a terminal process
<cbx33> requires no intereaction from user
<Kamion> hikenboot: ubuntu-live's dependencies are "everything we want to shove into the live CD to fill up the remaining space"
<Kamion> hikenboot: don't take them as statements of policy
<zyg1> Kamion: would it not be cool to say that ubuntu-live depends on ubuntu-desktop, ubuntu-live-stuff, ubuntu-live-language-packs, ubuntu-another-group-of-packages so that we don't throw everything into one bag?
<Kamion> zyg1: seems mostly pointless to me
<Kamion> I'd rather get rid of ubuntu-live and just handle it with Task fields, TBH
<zyg1> Kamion: task fields?
<Kamion> I don't really see the value in handling that particular one as a metapackage
<Kamion> yes, c.f. aptitude ~t patterns and tasksel
<zyg1> ah
<zyg1> that's the general idea :)
<Kamion> zyg1: also, the items are separated out into blocks in the seeds, so it's perfectly manageable for us
<zyg1> there are not so many tasks currently though
<Kamion> it's only people who try to hack on the generated output without using the seeds who have trouble
<Kamion> zyg1: https://launchpad.net/distros/ubuntu/+spec/ubuntu-server-tasks
<zyg1> mmm, interesting - thank you
<seb128> Keybuk: around?
<Keybuk> seb128: yup, 'sup?
<seb128> Keybuk: my system doesn't boot normally, maybe you have an idea on it
<seb128> I get the "Booting the operating system now"
<seb128> then "No cryptroot configured, skipping"
<seb128> and then a text login prompt
<Keybuk> right ...
<seb128> is the boot suposed to be verbose with upstart?
<Keybuk> what interesting things do you have on your syste,?
<seb128> I just installed upstart now
<Keybuk> no, it's not verbose by default (though I might suggest we change that)
<seb128> knowing I have ubuntu-minimal not installed :p
<Keybuk> why don't you have ubuntu-minimal installed?
<seb128> I had to install the sysv-compat package by hand but it doesn't fix the boot
<Keybuk> do you have initscripts installed?
<seb128> because it probably got removed at some point and I didn't bother reinstalling it
<seb128> I just figured that :p
<seb128> ii  initscripts              2.86.ds1-14.1ubuntu7     Scripts for initializing and shutting down the system
<Keybuk> ok
<seb128> I don't think I've weird things started on boot
<Keybuk> login to the text one
<Keybuk> sudo status rcS rc2
<seb128> "rcS (stop) waiting
<seb128> rc2 (stop) waiting"
<Keybuk> ok, is X/gdm running?
<Keybuk> (ps ax
<seb128> from my X session I started with a /etc/init.d/gdm restart
<seb128> should I rather IRC from an another box and let the desktop to text mode?
<Keybuk> is everything else from rc2 running?
<Keybuk> ie. dbus, hal, etc.
<seb128> looks not a lot of things are running, no
<seb128> no
<Keybuk> ok
<Keybuk> can you do "start rc-default"
<Keybuk> (with sudo)
<_ion> Now the boot logger would be handy. :-)
<Keybuk> and then immediately after "status rc1 rc2"
<seb128> $ sudo start rc-default
<seb128> rc-default (start) running, process 5226 active
<seb128> $ sudo status rc1 rc2
<seb128> rc1 (stop) waiting
<seb128> rc2 (stop) waiting
<Keybuk> ok
<Keybuk> run that sudo status bit a couple of times
<seb128> no change
<Keybuk> "runlevel" says ?
<seb128> 2 2
<Keybuk> odd
<Keybuk> sudo initctl jobs &
<Keybuk> sudo start rc2
<seb128> $ rc2 (start) starting, process none
<seb128> rc2 (start) running, process 5269 active
<seb128> rc2 (stop) stopping, process none
<seb128> rc2 (stop) waiting
<seb128> nothing next
<seb128> it's waiting there
<Keybuk> very odd
<Keybuk> you have /etc/init.d/rc yes ?
<seb128> yep
<Keybuk> ok
<seb128> 82c53693cda46f9144d94551a5442a68  /etc/init.d/rc
<Keybuk> can you edit /etc/event.d/rc2 for me
<Keybuk> add "console output" before the "script" line
<Keybuk> and then "set -x" after it
<Keybuk> ie.
<Keybuk> console output
<Keybuk> script
<Keybuk>         set -x
<Keybuk>         set $(runlevel --set 2 || true)
<seb128> done
<Keybuk> oh
<Keybuk> hmm
<Keybuk> you're in X
<seb128> yeah
<Keybuk> take out console output, and instead add "exec 2>/tmp/rc2.log" before the set -x line
<Keybuk> script
<Keybuk>         exec 2>/tmp/rc2.log
<Keybuk>         set -x
<Keybuk>         set $(runlevel --set 2 || true)
<Keybuk> so you have that
<seb128> k
<seb128> "sudo start rc2"?
<Keybuk> now sudo start rc2
<Keybuk> yup
<seb128> $ cat /tmp/rc2.log 
<seb128> + runlevel --set 2
<seb128> + set 2 2
<seb128> + [ 2 != unknown ] 
<seb128> + PREVLEVEL=2
<seb128> + RUNLEVEL=2
<seb128> + export PREVLEVEL RUNLEVEL
<seb128> + exec /etc/init.d/rc 2
<seb128> stty: standard input: Inappropriate ioctl for device
<Keybuk> O.K.
<Keybuk> hmm
<Keybuk> ok
<Keybuk> it stops immediately after it starts?
<Keybuk> (from the jobs & thing)
<seb128> yes
<Keybuk> ok
#ubuntu-devel 2006-09-06
<seb128> does that makes sense to you?
<Keybuk> try changing the exec line to
<Keybuk> exec >/tmp/rc2.log 2>&1
<ogra> does anyone know if port 1337 is used by anything ? 
<jdong_> ogra: oh boy... why?
<seb128> Keybuk: and then? start rc2?
<pygi> ogra, I don't think so
<jdong_> ogra: I've used it on occasion for the coolness factor... but nothing that I know actually uses it
<ogra> for fun... i'm looking for a funny portnumber (only for internal usage)
<seb128> Keybuk: same log
<jdong_> ogra: it is said to be bad luck to run your daemon on 1337 :)
<ogra> well, its likely that many people will occasionally use it i guess
<ogra> pfft, bad luck ...
<Keybuk> seb128: ok
<Keybuk> seb128: change the exec /etc/init.d/rc 2 to exec sh -x /etc/init.d/rc 2
<seb128> Keybuk: http://paste.ubuntu-nl.org/22680
<Keybuk> seb128: errrrrrr
<Keybuk> could you ls /etc/rc2.d for me
<seb128> $ ls /etc/rc2.d
<seb128> README
<elmo> LOL
<Keybuk> *blink*
<seb128> hum
<ogra> heh
<_ion> :-)
<Keybuk> I THINK WE MAY HAVE FOUND YOUR PROBLEM
<_ion> You think so?
<seb128> something nuked /etc/rcn.d
<jdong_> whoa
<jdong_> lol
<seb128> *great*
<Keybuk> seb128: all of them?
<jdong_> quick! blame it on slomo's dbus upload!
<seb128> rc0.d:
<seb128> README
<seb128> rc1.d:
<seb128> README
<seb128> rc2.d:
<seb128> README
<seb128> rc3.d:
<seb128> README
<seb128> rc4.d:
<seb128> README
<seb128> rc5.d:
<seb128> README
<seb128> rc6.d:
<jdong_> oh boy
<seb128> README
<seb128> rcS.d is still populated
<jdong_> I see someone reaching for a install cd soon.... :)
<Keybuk> no postinst/rm that I can find does that
<_ion> Does the README say "ha ha, got you"?
<Kamion> seb128: did you have initscripts uninstalled at any point?
<Kamion> seb128: if so, did you perchance purge it?
<Keybuk> Kamion: why would initscripts uninstall everything?
<Keybuk> even gdm
<Kamion> oh, true, it wouldn't nuke the lot ...
<seb128> Kamion: I don't think so
<elmo> /var/log/dpkg.log should tell you?
<seb128> nothing today
<zyg1> eh, my primary disk is starting to die according to smartctl :/
<zyg1> crap
<ajmitch> zyg1: that's why you need RAID
<ajmitch> a chance to frantically scramble to replace the disk
<Keybuk> seb128: what have you installed since you last booted?
<zyg1> ajmitch: not untill ubuntu installer allows me to make one without thinking (for /)
<seb128> tonight, libssl0.9.8 liboobs-1-1 powernowd
<ajmitch> zyg1: worked ok for me with the alternate cd (separate /boot)
<seb128> and I was upgrading gnome-system-tools
<zyg1> ajmitch: what I actually want is a flash disk of about 10GB that's comparable in price with 250GB of spinning metal
<seb128> none of them looks like they are doing some weird thing
<zyg1> ajmitch: I will try though, I'm getting sick of failing disks, that's the third one this month
<ogra> grmbl
<ogra> are the keymaps settings in xorg broken currently ? 
<Keybuk> seb128: when did you install upstart?
<jdong_> zyg1: have you had any seagates fail on you yet?
<jdong_> zyg1: it's about the only brand that's been nice to me
<seb128> Keybuk: after that my system had issues to reboot, I figured I might have been in a middle of an upstart upgrade because I didn't have ubuntu-minimal installed
<seb128> so I would not blame it
<Keybuk> no, I'm just trying to ascertain what you managed to uninstall by accident :p
<ogra> pitti, are you able to use setxkbmap on an up to date edgy ? 
<zyg1> jdong_: the one failing just now is a segate 
<Keybuk> I know I definitely didn't put any "if user == seb, delete all his rc symlinks" code in there
<zyg1> no kidding
<ogra> i only get "couldn't interpret _XKB_RULES_NAMES property"
<jdong_> zyg1: wow... never mind then... I was gonna tell you to run away from maxtor.... ;)
<Keybuk> (but not the README, which is quite special ... that takes extra-perverse coding)
<zyg1> jdong_: why is flash so mp3like and not server like, eh :/
<jdong_> zyg1: because it's so expensive-like? :)
<jdong_> zyg1: and I honestly question if it's any more stable
<jdong_> zyg1: I've seen CF cards die on me before
<zyg1> jdong_: but if hard disks were shiny and came with earphones I'm sure people would buy them... oh wait!
<jdong_> we kind of abuse them on our robotics team... IO-intensive workloads off a sandisk 128MB CF card
<zyg1> jdong_: yeah but they don't fail being read (as my server actually does)
<jdong_> so flash isn't the answer :-/
<elmo> Keybuk: it's notably the only file in there (as opposed to a symlink) so not that perverse
<gnomefreak> is there a chance of seeing mozilla-thunderbird 2.0 to match ff in edgy?
<jdong_> I find it interesting that rcS.d was unaffected
<zyg1> heh, I heard a story today: one of our customers was apparently sent a development device that was .... continously updating the flash (for testing purposes) for the past ..... YEAR
<Keybuk> elmo: I could understand rm /etc/rc[0-6.d/*
<Keybuk> or even rm -rf /etc/rc[0-6] .d
<Keybuk> but deliberately iterating symlinks and removing just those ... perverse
<Keybuk> seb128: you have things in /etc/init.d still, yes
<zyg1> jdong_: IMHO flash is more reliable than spinning disk, especially for rare writes as in this case
<Keybuk> and you didn't run any of the Debian "re-order my rc.d" crap? :p
<zyg1> Keybuk: lol
<seb128> Keybuk: /etc/init.d looks complete
<Keybuk> PIMP MY RC.D
<_ion> rm /etc/rc[0-6] .d/*(@) (zsh)
<_ion> :-)
<seb128> Keybuk: ARG
<seb128> Keybuk: thank you
<Keybuk> seb128: ARG? :p
<seb128> Keybuk: I tried the new services-admin from g-s-t update
<Keybuk> I. See.
<seb128> but didn't do anything with it
<seb128> just opened and closed
<jdong_> seb128: that could've done it...
<Keybuk> clearly it did things to you in revenge :p
<jdong_> :)
<Keybuk> did you ship it in edgy?
<pitti> ogra: yes, works fine
<ogra> weird
* jdong_ version controls his /etc
<elmo> aww man
<elmo> we can't blame this on Scott?
<elmo> damn it
<Hobbsee> elmo: blame him anyway :D
<Keybuk> I thought we were blaming slomo for everything this week?
<Hobbsee> elmo: dont get caught up in minor details on whether it's his fault or not.  blame him anyway.
<Hobbsee> Keybuk: no, that was last week.
<Hobbsee> and the weeks suddenly started on wednesdays.
<jdong_> if upstart knew how to start the system without sysv scripts, seb128 would still be booting fine. Thus, scott is to blame.
<jdong_> done
<_ion> pitti just went offline, so why not simply blame him?
<seb128> Keybuk: sorry for making you loose time on that, thank you for the help figuring we should really not ship that services-admin :p
* gnomefreak havent gotten to slomo about it yet but he was right it wasnt dbus it was having more than 1 set of drivers :(
<ajmitch> Keybuk: might as well, he broke f-spot for me with dbus :)
<jdong_> hmm, should I try services-admin for fun?
* jdong_ backs up his /etc twice
<Keybuk> three times
<Keybuk> and don't use sbackup :p
<Keybuk> or whatever that thing was
<ogra> its broken by upstart i heard :)
<ogra> wies your system etc :P
<_ion> I started services-admin and quit it, rc*.d are fine.
<ogra> *wipes
<Keybuk> anyway
<Keybuk> seeing as I'm not to blame
<Keybuk> I'm going :)
<Keybuk> byeeeee
<jdong_> likewise, it didnt nuke my rc*.d
<seb128> great
<seb128> that's services-admin to blame
* seb128 is having a nice discussion with upstream
<ogra> its probably a bit risky to ship such tools in edgy with upstart ...
<jdong_> well, not having a services-admin type of tool kind of sucks, too
<jdong_> has anyone managed to reproduce this?
<ogra> right, but breaking your system because it cant cope with the new initsystem is more evil
<jdong_> true
<seb128> jdong_: I've not uploaded the new version yet
<zyg1> hmm, do you guys think that this is a bug in python: "".split() != "".split(',')
<jdong_> seb128: ah, I see
<seb128> and I'll not 
<jdong_> weirdly the Kubuntu services program deals with upstart just fine
<ogra> so should services-admin
<Kamion> ogra: what's the state of ltsp-dhcpd-autogeneration?
<Kamion> it's the only Essential spec, and isn't done
<wasabi> Has any consideration (maybe a bit odd) been given to using the ideas pioneered by upstart for the desktop itself?
<ogra> Kamion, right, working on it ... let me finish login and session handling 
<wasabi> Maybe dbus covers it. But, imagine upstart starting per-user when you log in, and replacing gnome-session (or parts of it)
<zyg1> wasabi: huh?
<shackan> argh, dbus
<_ion> wasabi: Well, upstart is going to support per-user services, but not in edgy.
<wasabi> Ahh.
<_ion> s/services/jobs/
<wasabi> jsut cron-like stuff.
<wasabi> not attached to a particular X session
<_ion> Well, i don't see anything that prevents one from implementing something like that. It hasn't really been planned AFAIK.
<ogra> Kamion, ltsp-dhcpd-autogeneration will be basically done tomorrow evening ... its the last one i have left and i have the full day tomorrow for it ...
<_ion> But X session management seems to be a bit out of scope for upstart.
<Kamion> ogra: ok, please make sure that gets done; I am available for code review tomorrow, and indeed I'd like to see its state
<Kamion> ogra: since it's Started, how much of the code is in place?
<ogra> Kamion, i have script pieces that determine a possible free NIC and echo an entry for it to /etc/network/interfaces ... the rest is debconf template and value stuff i'll have to write tomorrow i havent looked into it this week yet since i'm nearly done with the login/session spec and want to finish it first
<Kamion> ogra: ok, expect mdz to be asking about the status when he gets back tomorrow
<Kamion> just by way of incentive :)
<ogra> i do :)
<ogra> but i have the full day for it so i'm not really worried ...
<Kamion> I'm worried about everything that's not completed yet
<ogra> and its really some trivial shell scripting only ... the bigger part for me is the debconf stuff ... i do this kind of things to rarely
<Burgwork> Kamion, I think that is part of your job
<Kamion> ogra: hence my offer of code review, since I do debconf hacking all the time
<ogra> i know
<ogra> but i'm not on that part yet 
<ogra> i'll get up very early i hope i can show you something around noon ...
<ogra> <- short break
<Kamion> ogra: thank you
<Kamion> Mithrandir: should live-cd-write-as-you-go be deferred now?
<Kamion> Riddell: is kubuntu-accessibility just blocking on me doing the cdimage/gfxboot glue, or is there more to it?
<Riddell> Kamion: it's blocking on me sending the casper changes to Mithrandir, which I plan to do in an hour or so
<Kamion> mvo_: is cdrom-based-dist-upgrades "beta available" (or more) now?
<mvo_> Kamion: it is beta-available now, yes. I will update it
<Kamion> thanks
<Kamion> zul: what's the state of xen-edgy?
<Kamion> zul: you wrote in the status whiteboard "zulcss 2006-08-16: Testing has begun on x86 amd64 still blocked on the builds" but I don't understand what blockage exactly you mean
<Burgwork> welshbyte, you need to talk to sivang about python-based backup software
<welshbyte> Burgwork: yeah i'm planning to look into hubackup, it looks cool
<Burgwork> welshbyte, given google has now funded 3 seperate backup projects, all written in python
<welshbyte> Burgwork: yeah i guess it does duplicate work and spread the skill thin
<Burgwork> welshbyte, you should talk with the author of system-config-backup (this years effort, being done by Fedora)
<Burgwork> backpack was last years Fedora and sbackup was last years Ubuntu
<welshbyte> Burgwork: yeah i took over last year's fedora one
<welshbyte> not that i use fedora much...
<Burgwork> I am forced to use it at work
<welshbyte> my computer society uses it
<welshbyte> despite my best efforts to get them to switch the desktops to ubuntu 
<Burgwork> you need to provide them with something that is clearly better than Fedora
<pygi> Burgwork, crack fedora boxes :P
<welshbyte> well i'll keep pushing for it while i still hold sway on the exec committee
* mvo_ goes to bed now
* tseng summons Keybuk
<BenC> anyone know why a new debhelper would be breaking kernel compiles?
<BenC> dh_strip debug symbol extraction: using obsolete debhelper compat mode 1
<BenC> Directory debian/tmp-headers does not exist, aborting
<BenC> that's how things are all of the sudden failing
<bddebian> Heya
<Kamion> Mithrandir: ok, I've got as far as getting "These keymaps appear to be indistinguishable" errors out of gen_keymap, so now it's just a matter of pruning keymaps from the tree until the result is sensible.
<bluefoxicy> You know what would be cool?
<bluefoxicy> Human as a dynamic theme.  Draw the buttons using a little random data to introduce slight, organic-looking variation.  :)
<bluefoxicy> (I have been waiting for this since the slashdot on wobbly windows and other such experimental cruft, but no dice)
<theCore> does Ctrl-Shift+[Unicode]  has been removed from GNOME?
<grexk> theCore: dapper? nope
<desrt> "If you hope some day to look back on your career and feel that it has contributed to the growth of a good and free society, you need to make your software free." -- FSF
<infinity> Yeah, I take warm fuzzies in exchange for pay.
<infinity> Sure, it doesn't pay the rent, but boy do I feel good about myself.
<infinity> Also, I'm so very, very hungry.
<desrt> programs that display the GPL when you install them and force you to "agree" are really dumb
<infinity> Very, very dumb, since it's not an EULA, it's a distribution license.
<LaserJock> I've noticed a lot of those on OS X apps
<infinity> Windows stuff, too.
<infinity> People who write free software for proprietary operating systems don't seem to "get" the license.
<desrt> EULAs are really suspicious to me
<infinity> To be fair, people who write free software for Linux/BSD probably don't "get it" a lot of the time too, but we have enough people willing to hunt them down and explain it to them.
<desrt> if someone has sold you the software on the CD then you own that CD
<desrt> you own a copy of their work.  period.
<Fujitsu_> No.
<desrt> you can do with it as you like as long as you don't violate their copyright
<Fujitsu_> Said copy of their work is /licensed/ to you.
<Fujitsu_> Not owned by you.
<desrt> (or any other applicable laws)
<desrt> Fujitsu_; that's BS.
<Fujitsu_> That's what the licenses say.
<desrt> they might want you to think that
<desrt> but it's BS
<desrt> that's like somone adding a note to the back of a cd saying "the music on this cd is licensed to you.  the license says we can take the cd away whenever we want."
<desrt> it's clearly batty
<Fujitsu_> That's life.
<desrt> yes.  companies thinking that they have rights which they actually don't is life indeed
<Amaranth> mjg59: Adding "nvidia" to MODULES in /etc/default/acpi-support seems to make hibernate work on my HP in edgy, thought you might like to know.
<dholbach> good morning
* hunger sighs. Somehow this upstart thing managed to sneak into my system again during the last upgrade I did.
<Burgundavia> hunger: it is now installed by default
<hunger> Burgundavia: I noticed:-(
<hunger> Burgundavia: Does it actually work for somebody?
<Burgundavia> yep
<Burgundavia> you must jsut have interesting software
<hunger> Burgundavia: It does not bring up the consoles to log in which is pretty annoying.
<hunger> Burgundavia: That it fails to mount up encrypted devices is much more annoying though.
<Burgundavia> file bugs
<hunger> Burgundavia: I did.
<Burgundavia> it is early days yet
<hunger> Burgundavia: The first version I tested worked better than the 0.2.x :-|
<Burgundavia> I am most definitely not hte person to talk to about that
<hunger> Burgundavia: You are right, I'll stop bitching.
<pitti> Good morning
<dholbach> heya pitti!
<hunger> Burgundavia: Sorry.
<hunger> pitti: Hi.
<jdub> hunger: this is edgy.
<Burgundavia> hunger: no worries
<jdub> hunger: we have to do *something* edgy.
<Burgundavia> I also understand that Keybuk accepts patches
<Burgundavia> jdub: we should have done smart
<hunger> jdub: Yeap. Do it!
<Burgundavia> and why does Mark have gustavo squirrlled away right a freaking management client?
<hunger> jdub: But of course you are evil if you do something that breaks my system:-)
* pitti hugs dholbach and hunger
<dholbach> Burgundavia: ah! you volunteer to port all the stuff to smart and hack apt features into it! :)
<Burgundavia> dholbach: no, but isn't that what mark is paying all those smart dpkg people todo?;)
<jdub> Burgundavia: you know, that whole "making money to ensure that canonical can continue with this whole ubuntu racket"
<Burgundavia> yes, but anybody can write a freaking managment server. AFter all, the clowns at my company did it
<dholbach> Burgundavia: what do the dpkg people have to do with smart?
<Burgundavia> they write package management software
<Hobbsee> hi pitti 
<pitti> hey Hobbsee 
<Hobbsee> pitti: my laptop is dying :(  i'm not happy
<jdub> Burgundavia: who is the best person to put on a money earning project - "just anybody" or "fucking brilliant"?
<lifeless> fucking awesome
<jdub> lifeless: THAT WAS NOT IN THE LIST
<lifeless> jdub: I'm a radical man
<jdub> lifeless: THINK INSIDE THE BOXES I GIVE TO YOU
* lifeless breaks
<lifeless> She canna take it captain!
<zyga> hey
<ajmitch> hello
<jdub> elmo: ping
<carlos> Kamion: you owe me some .po files for debian-installer ;-)
<Kamion> carlos: did you do the dapper import?
<Kamion> IIRC I was leaving the files there for you deliberately
<carlos> Kamion: no, are the files in place?
<Kamion> carlos: yes, they were last time we talked as well
<carlos> sorry, I thought you were going to ping me...
<carlos> ok
<carlos> let me do it
<Kamion> carlos: ok, I've archived them to http://people.ubuntu.com/~cjwatson/installer-po-dapper/
<Kamion> please use that, and I'll point /installer-po/ at edgy
<carlos> ok
<carlos> thanks
<ogra> hmm, is there a way to excude my package from a dbgsym build ? 
<ogra> i surely dont need that for ltsp
<pitti> ogra: yes, there is
<ogra> pitti, how ? 
<pitti> ogra: NO_PKG_MANGLE=1
<ogra> in rules ?
<pitti> ogra: does it hurt to built with debug symbols?
<ogra> well, its wasted energy 
<pitti> ogra: yes, in debian/rules
<pitti> ogra: pah, the buildds can cope :)
<ogra> i dont have anythin in it that could have debug symbols
<pitti> ogra: oh, if there are no ELF files at all, then there won't be dbgsym packages anyway
<ogra> (its only a bunch of scripts)
<pitti> if there are, that's a bug I need to fix
<ogra> i just saw the attempt in the log
<ogra> dpkg-deb: building package `ltsp-client-dbgsym' in `../ltsp-client-dbgsym_0.99_amd64.ddeb'.
<pitti> oh
<ogra> ah
<ogra> there is this 10 line c proggy that maps printers to port 9200 mdz imported from ltsp.org
<ogra> so there is an ELF file :)
<pitti> ogra: getltscfg and lp_server perhaps/
<pitti> ?
<pitti> ah
<ogra> i'll add the rules option
<pitti> as you wish
<jdub> "Elmo loves wasabi. That's why Elmo has no eyelids."
<ogra> is there something wrong with the i386 buildd ? 
<ogra> i wonder why my ltsp package from 7h ago is still pending
<ogra> infinity ^^^ ?
<Fujitsu> ogra, KDE stuff is taking its time.
<Fujitsu> I've got 3 builds waiting, about to be 4.
<ogra> well ...
<Fujitsu> It's off KDE stuff now, but it'll take a while to get rid of the backlog.
<ogra> yeah
<ogra> 7h is quite some delay
<Fujitsu> It is.
<Fujitsu> We need a seperate lot of buildds for KDE! They block everything else by many hours...
<ogra> heh
<infinity> ogra: Before KDE, both i386 buildds were stuck on OpenOffice builds for more than 10 hours.  Blame doko.
<ogra> infinity, thanks ... i would have blamed him anyway for fun ... :)
* ogra blames doko
<Fujitsu> Why's i386 always doing so much?
<pitti> Fujitsu: it additionally has to build all the arch:all packages
<ogra> because it builds all these arch all packages probably ...
<Fujitsu> Ah.
<Fujitsu> That's very silly.
<Fujitsu> Has somebody considered fixing that behaviour?
<infinity> Fujitsu: Two reasons.  1) i386 builds the "arch:all" packages.  This isn't normally a big deal, except for openoffice.org-l10n, and 2) More stuff builds successfully on i386 than anywhere else.
<ogra> we could also drop all arch:all packages :P
<Fujitsu> True, infinity.
<pitti> infinity: 1) langpacks :)
<doko> infinity: just the dapper builds, the edgy builds are coming ...
<infinity> pitti: langpacks aren't a big deal, since they're individually quite small, so they don't cause the 10+ hour delay that ooo-l10n does.
<ogra> as long as you let some packages through inbetween thats fine doko 
<doko> the buildd's are idling around now ...
<ogra> yay, it built ...
<infinity> doko: i386 isn't.  It's still catching up. :)
<doko> ohh
<infinity> Anyhow, this will sort of resolve itself if and when -security builds move to soyuz, since we'll have 3 buildds of each arch again, and we rarely have a 3-package blockage.
<infinity> Well, except on doko's uploading day.  But still.
<sivang> morning
<Fujitsu> Ah, I thought there were 3 each at some point...
* Kamion sighs at the slowness of keymapper, and adds an interactive mode
<Fujitsu> Oh great. vernadsky's back onto kdeutils...
<Fujitsu> And rothera's still on kdemultimedia... KDE is TOO big!
<ogra> seb128, would you mind to take a look at http://people.ubuntu.com/~ogra/scp-integration.patch ? its written by cbx33 and afaik ok with vuntz to add to our package
<ogra> (its for pessulus)
<seb128> ogra: yeah, cbx33 already talked with me about it yesterday evening
<ogra> ah, k
<seb128> ogra: I'll do that when I'm done with GNOME 2.16.0, the g-s-t update with some patches and the a11y patches I said I would look at next
<seb128> ogra: ie: probably this afternoon
<ogra> i'm just trying to sort his packages 
<vuntz> seb128, ogra: fwiw, I didn't review the patch, but what cbx33 told me looked reasonable
<carlos> pitti: btw, I removed the .pot exports from language packs
<seb128> vuntz: ok, thank you
<pitti> carlos: ok; I don't need them any more
<seb128> vuntz: don't forget about the SoC review for peter
<carlos> pitti: I think you told me that you don't need them anymore now that we only use Rosetta for language packs
<carlos> ok
<vuntz> seb128: I'm not forgetting it :-)
<ogra> wasnt the deadline yesterday ? 
<seb128> vuntz: gut ;)
<seb128> ogra: no, tomorrow
<ogra> oh
<ogra> damned and i already reviewed him ... 
<ogra> now he will slack the last two days ...
<ogra> :)
<pygi> ogra, I also thought it was yesterday :P
* ogra gets more coffee ...
<seb128> "September 8, 2006:
<seb128> - All mentor and student evaluations due by 08:00 Pacific Daylight Time"
<seb128> according to http://code.google.com/soc/mentorfaq.html#timeline
<seb128> Mithrandir: around?
<seb128> Mithrandir: have you planned to look at xkeyboard-config from Debian?
<seb128> Mithrandir: Denis Barbier did almost 10 uploads in a month, probably a bunch of good changes that could be useful to have
<Mithrandir> seb128: hiya.
<Mithrandir> seb128: I keep meaning to merge stuff from there, yes.  ENOTIME so far..
<seb128> k
<seb128> just pointing it in case you didn't notice
<Mithrandir> seb128: but yeah, I should probably look at their changes and merge in some of it.
<seb128> cool, thank you
<janimo> doko: hi, should all python packages have an __init__.py? It's not clear to me when reading the policy. The package I am making is a single importable .so w/o .py files upstream, is it worth using python-central?
<doko> janimo: no, it's not required, but the extension should be built for all supported python versions.
<cbx33> ping seb128 
<seb128> cbx33: pong
<cbx33> seb128: you interesting in seeing that pessulus update?
<seb128> <seb128> ogra: I'll do that when I'm done with GNOME 2.16.0, the g-s-t update with some patches and the a11y patches I said I would look at next
<seb128>  ogra: ie: probably this afternoon
<cbx33> http://www.progbox.co.uk/main-additions
<seb128> cbx33: that's the reply to ogra who already asked about like half an hour ago
<cbx33> heheh
<cbx33> ok
<cbx33> thanks ogra 
<seb128> cbx33: please open a bug on pessulus with the patch
<cbx33> will do
<seb128> thank you
<seb128> hey Keybuk
<cbx33> seb128: I have repackaged 
<cbx33> and have the diff.tar.gz
<ogra> mjg59, the glowing of my consoles is gone since the last upgrade, but now i have stripes and no chars there ...
<janimo> doko: can I just assume that only current is supported or should I make 2.3 and 2.4 packages too?
<cbx33> anyone know why this http://progbox.co.uk/scp/non-root-scp-client won't run from a launcher....if I run on terminal it's fine...and also run from launcher "in terminal"
<cbx33> can anyone help me out...what have I done wrong
<StevenK> cbx33: It won't get a terminal by default.
<doko> janimo: pyversions --supported gives yo the answer
<cbx33> I don;t want it to have a terminal
<cbx33> I just want it to run in the background
<cbx33> as a process
<janimo> doko: thanks
<ogra> cbx33, you should mention that you want it started from xdg/autostart
<ogra> ;)
<cbx33> ogra: it doesn't work from a normal launcher either
<ogra> btw, why dont you start it from /etc/X11/Xsession.d ?
<ogra> (i think the spec says that but i'm not sure)
<cbx33> ok I'll check
<ogra> with a number above 75 ...
<ogra> (since you need dbus)
<cbx33> hehe
<ogra> hmm, no rodarvus ...
<cbx33> no
<cbx33> I was hoping to speak to him too
<ogra> does anybody have an idea why i have stuff like 90x11-common_ssh-agent, 90xorg-common_ssh-agent, 99xorg-common_start and 99x11-common_start in that dir ? 
<ogra> they are identical scripts
<gnomefreak> mjg59: are you around?
<ogra> one from xinit and the other from x11-common
<Kamion> old conffiles that haven't been purged, maybe?
<ogra> well, dpkg -S shows them to belong to the packages ..
<ogra> do we really have conffiles in .d dirs ? 
<Mithrandir> ogra: because x11-common hasn't cleaned them up.  It should, really.
<ogra> yeah
<Mithrandir> ogra: they don't do any harm, though
<Mithrandir> (apart from wasting 0.1s of your precious login time)
<ogra> right, i was just wondering since i had to poke around in that dir a lot yesterday
<ogra> and it looked a bit weird
<cbx33> ogra, just fyi, the X11 didn't work either.  :S
<ogra> but its the right place for it ...
<cbx33> ok
<cbx33> I'll move it to there
<cbx33> and figure out why it's not working
<ogra> if you put it in autostart only desktops that use xdg will be able to use it
<cbx33> pygi can't see a problem with it
<cbx33> ahhh. ok thanks ogra 
<janimo> when adding an ubuntu chaneg to a native debian package do I just append ubuntu1 to the current one?
<cbx33> ogra: I found the problem
<cbx33> working on a fix now
<ogra> janimo, yes
* netjoined: irc.freenode.net -> brown.freenode.net
<janimo> ogra: thanks
<cbx33> ogra: FIXED !
<cbx33> rebuilding package now
<cbx33> will have to post it when I get home
<cbx33> will finish up MIR :D
<ogra> dont forget to update the changelog entry
<cbx33> so pleased that it's fixed, that was doing my nut - of course not
<ogra> best is to pull the package from universe now
<cbx33> ogra: is this now 0.5 ?
<pygi> cbx33, it's still 0.4 I would say :)
<ogra> will be, yes
<cbx33> ok
<pygi> oh, 0.5 :)
<ogra> since its a native package
<cbx33> 0.4ubuntu1
<ogra> no
<cbx33> oh right
<cbx33> ok 0.5
<ogra> no need for the ubuntuX 
<cbx33> sorry ogra thought you were agreeing with pygi
<ogra> but base on the package from universe
<cbx33> of course
<cbx33> I always do
<ogra> i made two very minor changes to yours
<cbx33> ok. I'll check them out
<cbx33> problematic?
<ogra> (your package still had the edgy distro, and didnt have the updated grep string for the userlist set)
<ogra> s/set/yet/
<cbx33> ah 
<cbx33> thanks ogra 
<cbx33> you're a start...really !
<cbx33> s/start/star
<ogra> me ? 
<cbx33> yes
<ogra> who did all the wokr ? 
* Keybuk muses over his specs
<ogra> *work 
<cbx33> heh
<ogra> that wasnt me :)
<ogra> youre the awesome guy here ... dont hide your credits ;)
<cbx33> Keybuk: too many, too little time?
<cbx33> ogra: it's funny in other communities, I've tried to show people what I've done and been told no one cares.....but here I get told to show off more :p
<cbx33> heheh
<cbx33> thanks for the encouragement ogra 
<ogra> thaks for all the hard work :)
<ogra> *thanks too
<Keybuk> cbx33: trying to decide whether to try and complete anything else before FF
<cbx33> do you want me to use 0.4 or 0.41
<cbx33> Keybuk: I know that feeling...on a much smaller scale
<Fade> is anybody else experience a serious crash in xemacs, and a similar non-crashing bug in emacs?
<Keybuk> I could try and port some of initscripts to upstart, but that runs the risk of dropping support for md/lvm/evms/etc.
<Fade> on edgy
<cbx33> 0.5 or 0.41 as it's just a tiny change?
<Keybuk> that may be considered bad
<ogra> cbx33, as you like :)
<cbx33> ok
<ogra> i consider it more your package than mine already ;)
<Mithrandir> Fade: can you see if you still see that problem in a couple of hours?  I just uploaded a fix for Xlib which I believe might be the cause of some emacs problems.
<ogra> so feel free to make the decidions
<ajmitch> Keybuk: yes, I like being able to boot
<cbx33> heh, ogra you da man !
<Fade> Mithrandir: that would be awesome.
<Fade> sure
<Keybuk> ajmitch: don't suppose you could send me your /var/log/udev ?
<ajmitch> Keybuk: sure, one for LVM on RAID, or just LVM?
<Fade> the c stack trace seems to indicate xlib
<Mithrandir> Fade: once you have libx11-6 2:1.0.3-0ubuntu3 installed, try to reproduce and if you can, it was something else, if not, yay. :-)
* Fade nods
<Fade> this is my report with traces on the xemacs package: https://launchpad.net/distros/ubuntu/+source/xemacs21/+bug/58856
<Ubugtu> Malone bug 58856 in xemacs21 "xemacs segfaults on edgy powerpc system" [Untriaged,Unconfirmed]  
<gnomefreak> Keybuk: you gonna be around for a little while?
<Kamion> Mithrandir: should live-cd-write-as-you-go be deferred?
<ajmitch> Keybuk: http://ajmitch.dyndns.org/~ajmitch/udev.lvm has output from my laptop using LVM
<Keybuk> ajmitch: either, both
<Keybuk> gnomefreak: umm, why?
<gnomefreak> does upstart affect tty's?
<gnomefreak> or can
<Keybuk> "affect" ?
<gnomefreak> blinking curser on all tty's
<Mithrandir> Kamion: yes, I'll mark it so now.
<Fujitsu> My tty1 went missing, but my others are fine.
<Keybuk> gnomefreak: I've had a report of that
<gnomefreak> ok cool
<Keybuk> Fujitsu: is it still missing?
<Mithrandir> Kamion: can we have the health check reports say how oversized any images are when they are?
<Fujitsu> Keybuk, yes, I last upgraded yesterday...
<Keybuk> Fujitsu: ok, what happens if you reboot without "splash" on the kernel command-line
<ajmitch> Keybuk: http://ajmitch.dyndns.org/~ajmitch/udev.lvm_raid has output from my desktop box
<Fujitsu> I'll try that in a couple of minutes, Keybuk.
<Keybuk> ajmitch: what does your laptop mount as root= ?
<ajmitch> root=/dev/mapper/acer--vg-ubuntu
<Keybuk> right
<ajmitch> works fine at the moment with upstart
<Keybuk> that's because upstart isn't do anything special at the moment
<Keybuk> if we changed the filesystem mounting to be event-based, yours would fail, because LVM is still in the dark ages and doesn't use udev
<ajmitch> great :)
<Keybuk> what does your desktop mount as root=?
* ajmitch checks
<cbx33> ogra: https://wiki.ubuntu.com/MainInclusionStudentControlPanel does that look better now?
<ajmitch> it's been awhile since it was rebooted
<ajmitch> ah, it's using UUIDs
<ajmitch> however it may not have been rebooted since that change was made :)
<fabbione> ajmitch: you can check with /proc/cmdline or something like that
<fabbione> it will tell you the options passed to the kernel
<fabbione> including root=
<ajmitch> thanks
<ajmitch> root=/dev/mapper/ubuntu-root
* fabbione vanishes again
<Keybuk> yeah, would have the same problem then
<Keybuk> I think the right thing to do here is to make an edgy+1 goal of "ReplacementInitscripts" and have more time to spend on it
<Keybuk> and include in that spec that dev-mapper and mdadm must be made to work with udev
<Keybuk> given a couple of months, that's definitely possible, which it isn't in a couple of days
<Kamion> Mithrandir: good idea; done for the next check
<Keybuk> Kamion: do you think that's sane?  defer that work to edgy+1 so we can spend more time on it?
<peterz> are you guys aware current edgy fails to build uml kernels?
<Kamion> Keybuk: boot-message-logging isn't possible without replacement-initscripts?
<Keybuk> Kamion: not sure yet, evaluating that now
<Kamion> Keybuk: I agree though, there was always going to be some part that got deferred and AIUI it was always going to be serious initscript conversion
<Kamion> it's a shame that we can't fix fstab handling in edgy, but there you go
<Keybuk> Kamion: we could fix it for the common/sensible case of people just using partitions and ordinary filesystems ... but at the cost of dropping support for the "exciting" ones
<Keybuk> I'm sure somebody would suggest that edgy is a good time to do that temporarily, while dapper is still out
<elmo> err, what?
<Keybuk> but I think that it'd be better to work it out so we have a very easy, step-by-step plan for edgy+1 instead
* pygi nods
<elmo> keybuk: are you seriously suggesting we drop support for root sw-raid?
<Keybuk> elmo: no, I'm suggesting seriously that we be more conservative and *don't* drop support for it, at the cost of deferring part of a spec
<elmo> Keybuk: ok, but please don't refer to root sw-raid as either uncommon, not sensible or "exciting", as I really don't think it's any of those
<Keybuk> elmo: ok, "crufty" ? :p
<Keybuk> "poorly maintained" ?
<Kamion> Mithrandir: believe it or not I'm *still* running gen_keymap
<madduck> Keybuk: poorly maintained?
<elmo> Keybuk: poorly maintained in ubuntu maybe, but that just reinforces my fears about ubuntu on servers :-p
<Mithrandir> Kamion: sheesh, that's a bit excessive.
<Keybuk> and poorly maintained upstream ... given none of these systems have been updated to expose their block devices correctly, despite this changing a couple of years ago in the kernel
<elmo> yeah, because udev is such a shining beacon of good maintenance *snort*
<madduck> Keybuk: i am trying... http://lists.alioth.debian.org/pipermail/pkg-mdadm-devel/2006-August/000859.html
<madduck> Keybuk: as of right now, mdadm and udev/lvm work fine together, at least in Debian.
<Kamion> hmm, gen_keymap wants me to pick one of Bosnia/Herzegovina, Croatia, and Slovenia unicode keymaps as the default for that set of branches in the decision tree. Which is least likely to get me assassinated?
<pygi> Kamion, Croatia
<pygi> I can help you there :)
<madduck> ubuntu should really upgrade mdadm and *not* ship 2.4.1 i think.
<Keybuk> elmo: *shrug* they're a bit prone to dropping backwards compatibility
<madduck> Keybuk: apart, what's poor about upstream?
<Mithrandir> Kamion: iirc, they're the same so it doesn't really matter.  We might want to default to the first, alphabetically.
<Kamion> Mithrandir: they're sufficiently close that gen_keymap can't tell them apart, anyway
<Keybuk> madduck: "apart" ?  that's all I've mentioned
<Kamion> hmm, yes, they're all "include cs(latinunicode)"
<pygi> Kamion, /me really suggests Croatian :P
<madduck> Keybuk: apart from my suggestion to upgrade
<Keybuk> madduck: you make no sense
<Kamion> I'll pick cs:latinunicode if it lets me, since that's the structure of the X keymaps
<Kamion> pygi: biased opinions don't count :)
<pygi> Kamion, ergh! :P
<madduck> Keybuk: let's not get hung up on english, okay?
<madduck> Keybuk: what's poor about mdadm upstream?
<elmo> madduck: we're way past UVF - what would upgrading mdadm now give us?  it certainly wouldn't fix the problem we're discussing (upstart and root sw-raid/dm)
<Keybuk> madduck: the fact that even after two years, they've not updated their code to work properly with udev/driver-core
<Keybuk> (ah, I believe we've reached the beginning of this conversation)
<pitti> rodarvus: is there a gitweb of x.org?
<madduck> elmo: ok. tbh, the changelog is a couple of hundred lines.
<madduck> elmo: i would not touch 2.4.1 with a stick anymore.
<madduck> Keybuk: as said, i am working on it.
<pitti> rodarvus: nevermind, got it
<Keybuk> madduck: indeed
<Keybuk> I never said you weren't :p
<Keybuk> and I even said I'd work on the other things to make sure they're all fluffy
<Keybuk> just not in 48 hours :p
<Keybuk> PUT YOUR KNEES AWAY! :p
<rodarvus> pitti, yes, http://gitweb.freedesktop.org/
<rodarvus> oh
<rodarvus> (/me should read all backlog before typing stuff :) )
<ans-tor> Is there any packages in debian that doesn't exist in ubuntu?
<Hobbsee> plenty
<Keybuk> "plenty" ?
<Keybuk> it's about 15-20 iirc
<Kamion> yes, for three reasons: (1) we're past upstream version freeze and new packages have been introduced in Debian since then, (2) we didn't quite get round to syncing in all new packages pre-UVF, (3) there are a few packages we've intentionally removed because they don't work for us
<ans-tor> ubuntu/universe doesn't contain all debian packages?
<Kamion> most, not all
<Kamion> the ones we've deliberately removed wouldn't work anyway
<Kamion> the rest are just too new, and will come into universe for edgy+1 at the latest
<segfault> morning. :-)
<Kamion> wouldn't work> for example, there's no point in linux-kernel-di-i386-2.6 (kernel packaging machinery for the installer), since our own linux-source-2.6.17 package does all that work itself
<ans-tor> not work in ubuntu but work in debian?  that's so weird.
<Kamion> the Ubuntu kernel is packaged quite differently from the Debian kernel, for maintenance workflow reasons
<ans-tor> opps, i see.
<Hobbsee> Keybuk: oh, i thought there were more than that.
<Hobbsee> Keybuk: dont mind me
<Kamion> although they do share a fair amount of common code even in the packaging, of course
<Kamion> Keybuk: that sounds like the count of deliberately-removed-and-blacklisted packages
<Keybuk> Kamion: err, yes
<Keybuk> lp_archive@drescher:~$ new-source | wc -l
<Keybuk> 283
<Keybuk> lp_archive@drescher:~$ new-source contrib | wc -l
<Keybuk> 34
<Keybuk> lp_archive@drescher:~$ new-source non-free | wc -l
<Keybuk> 64
<janimo> pitti, do you know if the "printer id" line at the start of foomatioc xml files should be exactly the same as the file name?
<pitti> janimo: no, I don't know, sorry
<janimo> there's one exception to this in the db now and I don't know if it's a bug or it is valid (to state that the devices are compatible or something like that)
<pitti> janimo: once till is online, you should ask him
<janimo> pitti: ok. Ia mhaving a look again at the fedore printing tools
<janimo> turns out that the one we looked at in paris was old, they were writeing a new one for FC6
<pitti> janimo: btw, till had the idea to port printerdrake to ubuntu
<janimo> pitti: with those nastly mandrake/perl libs?
<pitti> I hope not :)
<pitti> let's see
<janimo> pitti: is it ok with you if I upload python-cups (the fedora bindins library) to universe?
<pitti> janimo: of course, if it is free software
<pitti> sounds useful in any case
<janimo> pitti, ok, I was not sure if ivoks worked on something similar or not
* bluefoxicy blinks at massive disk access and checks top.
* bluefoxicy killall -9 updatedb
* bluefoxicy rm /usr/bin/updatedb since ubuntu-desktop depends directly on slocate
<Kamion> use dpkg-divert
<Kamion> or, more sensibly, edit the conffile that calls updatedb
<Kamion> it's a conffile for a reason
<bluefoxicy> Kamion:  there's a conffile?
<bluefoxicy> it looks to be a crontab
<Kamion> /etc/cron.daily/*
<bluefoxicy> won't that get replaced on upgrade?
<Kamion> no
<bluefoxicy> (granted so will the binary)
<Kamion> not if you've modified it
<Kamion> you'll get a dpkg conffile prompt
<Kamion> how long have you been using Debian/Ubuntu systems exactly? ;)
<bluefoxicy> I've never touched cron
<Kamion> or anything in /etc, apparently
<Kamion> well, not quite anything, but the bulk of files there are conffiles
<bluefoxicy> on gentoo certain things in /etc/ weren't treated as config files
<bluefoxicy> I'd assumed crontabs were more system scripts than configuration
<Mithrandir> well, this isn't gentoo
<ogra> Kamion, just to give you an impression of the triviallity of the ltsp-dhcpd stuff : http://people.ubuntu.com/~ogra/netscript
<Kamion> bluefoxicy: if they were, they would not be in /etc
<ogra> i need one debconf selection and one message now
<ogra> adding it to the ltsp-client-builder and im done ...
<bluefoxicy> Kamion:  they'd be in /etc or /var
<Kamion> ogra: you can't use awk in d-i
<ogra> hmm, it worked on on the d-i console
<bluefoxicy> anyway interview time
<ogra> i tested it 
* ogra goes to look for an alternative then
<Kamion> busybox-1.1.3/debian/config-udeb:# CONFIG_AWK is not set
<Kamion> ogra: oh, is this code running inside a chroot /target?
<ogra> nope
<ogra> thast for the server
<Kamion> I'm not sure how it worked for you, then :)
<ogra> but i ran it on tty2 on the CD
<ogra> hmm
<Kamion> if [ ! $iface = $DEFAULTROUTE_IFACE ] ; then 
<Kamion> that should be:
<Kamion> if [ "$iface" != "$DEFAULTROUTE_IFACE" ] ; then
<ogra> right
<Kamion> if [ $(echo ${IFACE_LIST}|wc -w) -gt 1 ] ; then 
<Kamion> quotes around the $(...), same elsewhere
<ogra> the condition was the other way around before ...
<Kamion> it's more the quoting I'm commenting on - you need to be especially careful with quoting in [ arguments because it will fall over messily if you don't
<ogra> ok
<Kamion> I assume you'll be replacing that use of select with a debconf select template
<ogra> yep
<ogra> thats why it still is /bin/bash
<Kamion> maybe put an extra blank line after the cat <<EOF
<ogra> ok
<Kamion> will look neater in interfaces
<Kamion> elif [ $(echo ${IFACE_LIST}|wc -w) -lt 1 ] ;then
<Kamion> you can't do [ -z "$IFACE_LIST" ]  ? :-)
<Kamion> I guess it might contain just whitespace, dunno
<ogra> it will ...
<ogra> IFACE_TMP="$IFACE_TMP $iface" adds whitespace 
<Kamion> oh, that's easily fixed
<Kamion> IFACE_TMP="${IFACE_TMP:+$IFACE_TMP }$iface"
<ogra> scary quoting :)
<Kamion> ${var:+string} does "if var is set, then expand string, else nothing"
<Kamion> set and non-empty actually
<Kamion> ok, otherwise looks plausible. you don't need to write to /etc/ltsp/dhcpd.conf from that script, just /etc/n/i?
<ogra> yep
<ogra> we keep /etc/ltsp/dhcpd.conf as is ...
<ogra> i'll add a grep 192.168.0. /etc/network/interfaces at the top as well ...
<ogra> and let it exit if it finds something ...
<ogra> but that should be about it 
<Kamion> or pick a different subnet
<ogra> then i'd need to touch dhcpd.conf
<ogra> which we dont want ...
<Kamion> ok
<ogra> i'll just fall back to the echo "error: no interfaces found please configure /etc/ltsp/dhcpd.conf manually after install"
<Kamion> what happens if there's only one interface?
<ogra> the same 
<Kamion> I'd be inclined to pick something that's less commonly used than 192.168.0.*, if possible
<ogra> it shows that message
<ogra> right
<Kamion> pick a random one from one of the bigger private-use ranges
<ogra> i thought about 10.0.0 or something
<Kamion> it's 10.0.0.0/24, so you wouldn't need to start with 10.0.0., even
<Kamion> er, /8
<ogra> well, something from the 10. range ...
<Fujitsu> Or 172.16.0.0/16.
<Kamion> Fujitsu: /12
<Kamion> (RFC1918 s.3)
<Keybuk> it's amazing how many people get that one wrong :p
<Fujitsu> :$
<Keybuk> 10 = Class A, 172.16 = Class B, 192.168 = Class C
<Fujitsu> B = /16!
<Keybuk> of course, the Internet has "grown up" and the Class System is merely a memory
<Keybuk> no, B = /12
<Keybuk> (top-level allocations, not sub allocations)
<ans-tor> ubuntulog: hi
<ans-tor> ubuntulog: ?
<ans-tor> ubuntulog: help
<Treenaks> Keybuk: 'The correct modern representation for what would have been referred to as a "Class B" prior to 1993 would be "a set of /16 addresses"'
<Keybuk> err, maybe I'm confused there then
<Fujitsu> I thought so.
<Fujitsu> Cisco teaches B = /16.
<Treenaks> They still TEACH it, even though the internet has been classless for 13 years now?
<Keybuk> Treenaks: most Cisco kit still IMPLEMENTS it
<thom> Keybuk: yeah; 172.16 is 16 /16s (16 class Bs)
<Treenaks> *shudder*
<mdeslaur> rfc 791 defines a class B to be /16
<Keybuk> thom: that's what I thought
<Keybuk> and 192.168 is 256 class Cs
<thom> so you're right to say it's a /12, but wrong to say it's a B
<Keybuk> ahh, yes, I got myself confused along the way :p
<thom> yup
<Keybuk> 172.16/12 is the "set of private Class B networks", and isn't itself class B
<Keybuk> ok
<thom> Keybuk: when you stop being confused, can you make sysvinit non-Essential so apt'll stop trying to remove upstart? :_)
<Fujitsu> Yes, that'd be nice...'
<Keybuk> thom: sysvinit is non-Essential
<Keybuk> upgrade sysvinit ;)
<Keybuk> and then APT will be happy
<thom> urgh
<Keybuk> then you can file a bug on APT for failing to take into account changes in the Essential field
<thom> oh what a pain
<Fujitsu> Is ubuntu-minimal able to be installed with upstart yet?
* thom shakes his fist at mvo :-)
<thom> Removing upstart ...
<thom> dpkg (subprocess): unable to execute post-removal script: Exec format error
<thom> dpkg: error processing upstart (--remove):
<Kamion> there's an argument that it shouldn't take them into account until it's upgraded them anyway ...
<Keybuk> thom: stick a #!/bin/sh on the front of the postrm, sorry
<thom> slacker :-)
<Kamion> Keybuk: ISTR that there's special handling in dpkg for one Essential package C/Ring another, or maybe C/R/P
<Kamion> for exactly this reason
<Kamion> however upstart does not appear to be Essential
<Kamion> I suspect if you make it so, it'll work better ...
<Keybuk> Kamion: yeah, that will happen in my next upload
<hunger> Do ttys work whith upstart again?
<Keybuk> hunger: it appears to be a usplash bug
<Keybuk> or, at least, a bad interaction
<Keybuk> people report that if they downgrade usplash, their ttys come back
<hunger> Keybuk: I have no usplash and still no ttys.
<Keybuk> hunger: then perhaps you'd like to reply to my message on the bug report ?
<Keybuk> hunger: can you do "sudo status tty1 tty2 tty3 tty4 tty5 tty6" for me
<hunger> Keybuk: Damn... my mailserver must be down again:-(
<Keybuk> hunger: no worries, we can debug here :p
<hunger> Keybuk: Not really:-) I do not have upstart installed anymore.
<Keybuk> hunger: then I'm afraid I'll have to Reject your bug
<hunger> Keybuk: One sec... I'll go and break my system again by installing upstart.
<Keybuk> :)
<Keybuk> thanks
<hunger> Keybuk: No IRC while I am in an upstarted system though.
<Keybuk> why no IRC?
<thom> Keybuk: in answer to your question about cryptdisks and upslash, i've long since turned usplash off for precisely that reason
<hunger> Keybuk: Because my homedirs are gone, so is /usr and all the other stuff that I have encrypted.
<Keybuk> thom: <g>  I did have a momentary cunning hack thought that one could just < /dev/console the script
<Keybuk> hunger: ok, there's a temporary workaround for that
<Keybuk> install upstart, upstart-compat-sysv (and make sure sysv-rc and initscripts are also installed)
<Kamion> pitti: apt-get-debug-symbols presumably isn't happening for edgy
<Kamion> ?
<thom> Keybuk: eh, evil person :-)
<Keybuk> then edit /etc/event.d/rcS and /etc/event.d/rc2 and add "console output" to both files above the "script" line
<Keybuk> thom: evil?
<thom> well, hacky anyway. but yes, that'd be a short term fix for the problem
<hunger> Keybuk: All of those were installed.
<Keybuk> hunger: ok
<hunger> Keybuk: One sec... I'll reboot soonish.
<hunger> Keybuk: Just need to backup some data first.
<Keybuk> (also on a more general note, I've noticed that you almost consistently file bugs and then revert whatever is causing your problems ... it's useful for us, if you run the development release, to keep it broken while we debug it; otherwise we simply can't obtain any information about the bug, and assuming nobody else has the same problem, have no choice but to assume it's not a bug)
<Kamion> Riddell: I noticed a couple of things about your accessibility patch to caper
<Kamion> casper
<hunger> Keybuk: I only have this one computer. I can not keep it broken till somebody stops by to fix it.
<Kamion> Riddell: one is that "impairment" is consistently misspelled "imparement". Is it possible to fix that?
<Riddell> Kamion: certainly
<hunger> Keybuk: I most of the time need to revert the problem to be even able to report it in the first place.
<Keybuk> hunger: we can't fix it unless you keep it broken
<Keybuk> it's a not unreasonable assumption that it must be working for most other people, after all
<Kamion> Riddell: the other is that you've got an entry for access=m2, whereas that doesn't seem to be mentioned in bug 58836. Do you want me to leave access=m2 switched on for Kubuntu?
<Ubugtu> Malone bug 58836 in casper "F5 options need to be linked to the right casper options" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58836
<hunger> Keybuk: I am willing to rebreak if somebody is working on the fix. But I will not keep things broken till somebody finds the time to look into the bug I had.
<jdub> Kamion: what's richard weideman's nick?
<ogra> jdub, RichEd
<jdub> thanks
<ogra> (he's in -meeting atm)
<Keybuk> hunger: ok, ready to reboot ?
<Mithrandir> Riddell: I've fixed casper to use impairment now.
<Kamion> Riddell: (access=m2 being on-screen keyboard)
<hunger> keybuk: 10min max.
<mojo> isn't it me or my computer stuffed up? the gtkfile chooser dialog of "Save as.." of any programs missing Home and Desktop icons? am i gone mad?
<Keybuk> hunger: make sure you modify /etc/event.d/rcS and rc2, that'll give you the usual boot messages, etc.
<hunger> Keybuk: I did.
<hunger> Keybuk: rebooting....
<Riddell> Kamion: the kubunut m2 has the mouse tool but no on screen keyboard
<Kamion> I can't change the text at the moment thoughh
<jono> David: By the way Jono pass on my "oh my god this rocks" message to the ubuntu team would you Edgy is awesome way better than dapper was this far into it's development.
<jono> :)
<Kamion> heno: perhaps I could revert "On-Screen Keyboard" to more generic text? any suggestions?
<Riddell> Kamion: or I can just have the mouse tool on in m1 and not have an m2
<heno> Kamion: Virtual keyboard, alternative input ?
<mojo> heno: On-screen input?
<Kamion> what exactly is the mouse tool?
<Riddell> Kamion: it clicks the mouse if you hover over a button for some time
<heno> Useful if you cannot click. Some people with RSI use it as well
<heno> Riddell: does mousetool have other features than that?
<Riddell> heno: nope
<Riddell> I don't think it's worth having a confusing m2 text just so it fits both keyboard and mouse tools
<heno> I seem to remember that the Windows version did, but I could be wrong
<Riddell> Kamion: so I'd say don't have m2 for kubuntu and move the sed line from m2 to m1 in casper
<Kamion> Riddell: ok
<hunger_suse> Keybuk: What should I run again?
<Keybuk> hunger_suse: how far did you/it get?
<hunger_suse> Keybuk: The tty scripts all give a comment "expected 'on' or 'script'".
<hunger_suse> Keybuk: upstart dropped me into a root shell (without needing a password!).
<Keybuk> hmm, can you mount that filesystem from where you are now?
<pitti> Kamion: it's installed on the buildds for quite a while
<hunger_suse> Keybuk: I am online from another box.
<pitti> Kamion: infinity and I have a plan how to get them away from the buildds to people
<Keybuk> hunger_suse: ok, it sounds like you have a very old version of those config files installed
<hunger_suse> Keybuk: I got the upstart-ubuntu box running.
<Keybuk> ahh
<pitti> Kamion: until soyuz has proper support for them (!edgy)
<Keybuk> cat /etc/event.d/tty1
<Kamion> pitti: perhaps the spec should be updated to talk about the workaround rather than soyuz work
<pitti> Kamion: however, the cowboying should happen for edgy
<Keybuk> make sure it has "# tty1 - getty" at the top 
<pitti> Kamion: right, I'll update the whiteboard
<Kamion> thanks; is it beta-available now then, or not?
<hunger_suse> Keybuk: start when rc2 is stopping stop on shutdown stop on reboot respawn /sbin/...
<pitti> Kamion: not sure about the appropriate status; ddebs are built and thrown away, so ATM it's not even 'beta'
<Keybuk> hunger_suse: right, that's an old version of the script
<Keybuk> no wonder it fails :p
<Keybuk> did you modify them after installing originally, and then say "N" on upgrade?
<pitti> Kamion: as soon as we put them on people, it's implemented (well, in an ugly way, but still working)
<hunger_suse> I have then newest versions of everything installed.
<Kamion> pitti: oh. how much can happen before FF?
<Keybuk> hunger_suse: dpkg-query -W upstart upstart-compat-sysv
<hunger_suse> Keybuk: I have not modified anything and never was asked to upgrade the files.
<Keybuk> hunger_suse: which versions do you have?
<pitti> Kamion: the buildd scripting will happen afterwards, infinity is too busy ATM
<pitti> Kamion: but it doesn't affect the archive nor release in any way
<Kamion> pitti: ok, can we talk with mdz about that? the important factor is more going to be scheduling people's time after FF, I think
<pitti> Kamion: i. e. it's infrastructure and can happen independently from the release cycle
<hunger_suse> Keybuk: No such command.
<Kamion> to ensure you have enough time to fix bugs
<pitti> Kamion: sure, he will join tomorrow's distro team meeting I presume
<Kamion> yes, I believe so
<kagou> jenda: like zul, and also on www.debian.org/doc/manuals/maint-guide/
<Kamion> he said he'd be around this evening having crashed for a while
<pitti> Kamion: I guess we will use that to discuss spec statuses?
<Kamion> yes
<hunger_suse> Keybuk: dpkg info is not available anyway.
<giftnudel> hunger_suse: can't you mount your partitions?
<Keybuk> hunger_suse: why is dpkg info not available?
<hunger_suse> Because the partition that is on /var is not available.
<Keybuk> why is it not available?
<hunger_suse> Because upstart can not decrypt it.
<Keybuk> why not?
<Kamion> you can't mount it by hand?
* ogra didnt know upstart was supposed to be a decryption tool
* hunger_suse shrugs. It dowes not even try.
<Keybuk> hunger_suse: ok, can you please mount your /usr and /var (and any other FHS partitions) by hand at the root shell it gave you
<Keybuk> we'll need those for debugging
<thom> hunger_suse: /etc/init.d/cryptdisks start
<pitti> Kamion: I set it to 'deployment' and updated the whiteboard
<thom> if they're crypted disks
<Kamion> pitti: righto, sounds good
<Kamion> thanks
<pitti> thanks for the reminder
<Kamion>  7596 cjwatson  25   0  142m 121m 1884 R 99.9 12.1  31:09.77 gen_keymap
<Kamion> this really doesn't look good
<thom> um, is that for a keyboard with more keys than firefox has bugs?
<hunger_suse> Keybuk: Both upsatrt and the compat package are at 0.2.1-5
<Keybuk> hunger_suse: ok, thanks ... could you also cat /etc/event.d/rc2 for me
<Keybuk> it should begin "# rc2 - runlevel 2 compatibility", does it?
<Kamion> thom: that's ALL keymaps
<hunger_suse> Keybuk: That one has a script section.
<Keybuk> hunger_suse: does it have the first line I asked about?
<hunger_suse> Keybuk: It does.
<Keybuk> hunger_suse: ls /etc/event.d ... what files are in there?
<hunger_suse> rcS starts with the same line but with rcS in place of rc2.
<thom> Kamion: cripes
<hunger_suse> Keybuk: tty[1-6]  rc-default rc0-halt rc0-poweroff rc[1-6]  rcS
<Kamion> thom: (for the magic keymap detector in the installer)
<Keybuk> hunger_suse: ok
<Keybuk> hunger_suse: /etc/init.d/udev start ... with any luck that should bring the networking up ... then can you copy the /etc/event.d/tty1 script somewhere so you can paste it here
<hunger_suse> Keybuk: You won't get through the firewall or I would just give you an account on that box.
<Keybuk> I don't need to get through the firewall, I just need you to paste me a copy of that file :p
<hunger_suse> Keybuk: /etc/init.d/udev start fails.
<Keybuk> "fails" ?
<Keybuk> try "/etc/init.d/mountkernfs.sh start" then try again
<hunger_suse> Keybuk: Sorry, the ubuntu init scripts suck at error reporting... it just gives "[fail] ".
<Keybuk> hunger_suse: which message fails?
<hunger_suse> That works, udev start still fails.
<Keybuk> hunger_suse: which message fails?
<hunger_suse> Keybuk: "Starting kernel event manager... [fail] "
<Keybuk> ok, that means it's probably already running then
<Keybuk> "ifconfig -a" ... does that show an up interface?
<Keybuk> or, in fact, any interface?
<hunger_suse> Keybuk: eth0 is there but unconfigured.
<Keybuk> hunger_suse: ok, ifup eth0
<hunger_suse> Keybuk: ifup does not work (thanks to networkmanager), but I configured the interface manually.
<Keybuk> ok, cool, can you copy that /etc/event.d/tty1 file somewhere for me to see
<hunger_suse> Keybuk: Which files do you need?
<Keybuk> hunger_suse: all of them would be perfect, if not, just tty1
<bddebian> Howdy folks
* hunger_suse twiddles, waiting for pastebin.
<giftnudel> hunger_suse: didn't forget the route and the dns server?
<Kamion> Mithrandir: so at this point I'm having so much trouble getting gen_keymap to be useful that I'm close to giving up on sane-installer-keyboard
<hunger_suse> giftnudel: I am on another computer.
<hunger_suse> giftnudel: It is just the net being *sllooooowwww* again:-(
<Kamion> Mithrandir: I've got one more fallback plan, which is to run gen_keymap with a small list of keymaps borrowed from console-data, rather than everything-minus-exclusions
<giftnudel> hunger_suse: oh, ok, because these are the things I always foget, when I configure a network manually
<hunger_suse> giftnudel: So did I... but then we have onle IP adresses here anyway:-)
<hunger_suse> Keybuk: http://pastebin.ca/162350
<hunger_suse> That is tty1.
<hunger_suse> Keybuk: You want the rest as well?
<Kamion> but that will take a little hacking
<Keybuk> hunger_suse: no, that's fine
<Keybuk> hunger_suse: if you haven't done already, do mount -o rw,remount /
<Keybuk> hunger_suse: then dpkg --force-confnew --force-confmiss -i /var/cache/apt/archives/upstart_0.2.1-5_$ARCH.deb  (replace $ARCH)
<hunger_suse> Keybuk: That fails due to /usr being ro, but that is normal;-)
<hunger_suse> Keybuk: It installed sulogin.
<Keybuk> hunger_suse: could you make /usr be rw please
<hunger_suse> Keybuk: tty* scripts are unchanged.
<Keybuk> you need that to be installed
<hunger_suse> Keybuk: I did:-)
<Keybuk> not half-corrupted
<Keybuk> hmm
<Keybuk> unchanged ?!
<Keybuk> ok, brute force time
<Keybuk> rm /etc/event.d/tty*
<_ion> hunger: The files in your /etc/event.d are from upstart 0.1 i think.
<Keybuk> then run that dpkg command again
<hunger_suse> Keybuk: Yes.
<Keybuk> _ion: right; it's somewhat wacky that they haven't been replaced by the ones from 0.2
<hunger_suse> Reinstalling the sysv-compat does not change them either.
<Keybuk> did rm'ing them and installing again work?
<hunger_suse> Keybuk: Deleting the tty* and reinstalling them changed the files (some comments were added).
<Keybuk> hunger_suse: more pointedly, was "start when" removed ?
<Keybuk> should be just
<hunger_suse> Keybuk: Yes, that is gone, too.
<Keybuk> start on startup
<Keybuk> stop on shutdown
<Keybuk> ok
<Keybuk> dpkg is being freaky
<hunger_suse> spooky:-)
<Keybuk> edit /etc/event.d/rcS again, put "console output" back before the script line
<Keybuk> likewise for /etv/event.d/rc2
<Keybuk> (but spelled right :p)
<hunger_suse> Keybuk: I deleted everything in /etc/event.d and reinstalled the upstart and upstart compat debs.
<Keybuk> hunger_suse: ok
<Keybuk> you should have (sanity check) rc-default rc0-halt rc0-poweroff rc1 rc2 rc3 rc4 rc5 rc6 rcS sulogin tty1 tty2 tty3 tty4 tty5 tty6
* hunger_suse nods.
<Keybuk> ok
<hunger_suse> Got all of those.
<hunger_suse> Reboot?
<Keybuk> you've added console output to rcS and rc2 ?
<Keybuk> sync
<Keybuk> then "reboot -f"
<Kamion> Mithrandir: do you know if console-setup already has any notion of a mapping from old-style console keymap names to its names?
<Kamion> maybe I have to borrow xserver-xorg.config to do the mapping
<fschoep> dholbach: ping?
<hunger_suse> Keybuk: I am back in the root shell.
<Keybuk> hunger_suse: *blink*
<Keybuk> ok
<hunger_suse> Keybuk: Filesystem checks did not work out...
<hunger_suse> Keybuk: They are encrypted, so that is no surprise.
<Keybuk> right, this is just a normal failure mode now, yes?
<Keybuk> the rc scripts were being run normally?
<hunger_suse> Nope.
<Keybuk> how un-normally were they being run?
<hunger_suse> I got a login prompt and am asked for a password now.
<Keybuk> ok
<Keybuk> so it's booting
<hunger_suse> Both programs accept input from the same place...
<Keybuk> heh
<hunger_suse> REALLY confusing...
<Keybuk> alt+f2, login there, "sudo stop sulogin"
<Keybuk> that's a known bug (sulogin is, in fact, just /bin/sh at the moment)
<hunger_suse> Keybuk: Does not accept my root passwd:-(
<Keybuk> hunger_suse: what doesn't?
<Keybuk> that's between you and getty
<fschoep> Kamion: do you have a minute to troubleshoot a packaging problem?
<hunger_suse> Keybuk: Great.
<bddebian> OMFG, why can't I win the frickin' lottery or something so I can just work on Ubuntu the rest of my life instead of this Godforsaken job... aaarrrggghh
<Keybuk> it sounds like upstart is now running things the same way that sysvinit did
<Keybuk> I don't know why your conffiles weren't updated, you may want to speak to iwj about that
<hunger_suse> Keybuk: It does not run things the same way sysvinit did.
<Keybuk> what is it not running the same way?
<hunger_suse> Keybuk: It does NOT run cryptdisks before trying to mount partitions.
<Keybuk> hunger_suse: it just runs /etc/init.d/rc
<Keybuk> if it's mounting partitions at all, then that's working right
<hunger_suse> Keybuk: It brings up all ttys and then tries to be clever, bringing up filesystems and I have not seen a single init script being run.
<Keybuk> "tries to be clever" ?
<Keybuk> we haven't put any of the clever in
<hunger_suse> It definitly is not using the normal sysvinit boot sequence.
<Keybuk> yes, it definitely is
<Keybuk> could you edit /etc/event.d/tty* and change "start on startup" to "start on rc2"
<Keybuk> that might be masking the cryptsetup prompt
<hunger_suse> Keybuk: No I can not. I can not log into my system.
<Keybuk> reboot, use init=/bin/bash then :p
<Mithrandir> Kamion: I don't think it has a mapping, no.
<Mithrandir> Kamion: I'd actually be more inclined to drop the cdebconf-keystep widget and go with console-setup, but I see the point why not to do it.
<hunger_suse> Keybuk: It is not. It never starts cryptsetup
<Keybuk> hunger_suse: tell you what, you fix it then :p  seeing as you're so sure of how it all works
<Keybuk> personally, I know that I wrote no code to do any clever filesystem mounting
<Keybuk> and I know that it just runs "/etc/init.d/rcS"
<Keybuk> but if you think differently, go right ahead <g>
<cbx33> mjg59: ping
<hunger_suse> Keybuk: cryptdisks is not started. I do not know what you are doing, but this is not the normal boot sequence.
<mjg59> cbx33: Hi
<cbx33> what's the deal with usplash artwork
<mjg59> In what way?
<cbx33> heh
<cbx33> colours
<Spads> TEST PATTERN
<Keybuk> hunger_suse: did you try my suggestion yet?
<mjg59> You've got 256 of them now
<hunger_suse> Keybuk: Which suggestion?
<cbx33> is there a page about it
<mjg59> Dennis has been working on various aspects of the theming
<mjg59> Best bet is to talk to him
<Keybuk> hunger_suse: modify the tty event.d files to say "start on rc2" instead of "start on startup"
<hunger_suse> Keybuk: Sorry, I am concentrating on the other screen.
<hunger_suse> Keybuk: Yes, I did that.
<hunger_suse> Keybuk: Fixes the screen uglyness.
<cbx33> mjg59: what is his nick
<mjg59> seveas
<cbx33> ahhh
<Keybuk> hunger_suse: but you still don't get a cryptsetup prompt?
<hunger_suse> Keybuk: That script is never run.
<Keybuk> hunger_suse: can you ls /etc/rcS.d and make sure there's a symlink to it
<hunger_suse> Keybuk: I added lots of echos right after the script starts. No output.
<Keybuk> you see the normal boot output, with ok/fail?
<hunger_suse> Keybuk: Yes, mostly.
<Keybuk> "mostly" ?
<hunger_suse> Keybuk: But that damn thing is missing
<Keybuk> just that one script?
<hunger_suse> Keybuk: That is the only one I noticed missing so far:-(
<Keybuk> right
<Keybuk> ls /etc/rc".d
<Keybuk> uh
<Keybuk> ls /etc/rcS.d
<Keybuk> you see S26cryptsetup-early and S28cryptsetup ?
<hunger_suse> Keybuk: It is listed there as S28cryptdisk.
<Keybuk> "disk" ?
<thom> Keybuk: yeah, they're called cryptdisk{,-early}
<thom> disks, even
<Keybuk> right
<Keybuk> hunger_suse: confirm that it's "DISKS" please :p  not "disk"
<hunger_suse> It is disks. The script works fine in sysvinit:-(
<Keybuk> ok
<cbx33> ping Seveas 
<Keybuk> cat /etc/default/cryptdisks
<hunger_suse> Keybuk: I'll need to do some work... I'll try again later.
<Keybuk> make sure it's enabled
<Keybuk> thom: you use this stuff, it's working for you?
<hunger_suse> Keybuk: You are right, the upstart seems to do the right thing... it is /etc/init.d/rc S that does not what I want from it.
<thom> Keybuk: i've not had chance to reboot and check recently; will try and do so soon
<Keybuk> cryptdisks is a bit odd
<Keybuk> I don't see how you can use it to encrypt your /usr ... given it uses openssl :p
<Keybuk> which is in /usr/bin
<hunger_suse> Keybuk: I have to admit that I am using a custom cryptdisks:-)
<_ion> Please define "custom".
<hunger_suse> Anyway, Have to get some work done. I'll be back later.
<Keybuk> _ion: "broken" :p
<_ion> :-)
<Keybuk> thom: when you do, looking at this, you _may_ need to put "console owner" in /etc/event.d/rcS not "console output"
<Keybuk> it looks like cryptdisks reads from /dev/tty, which won't be set
<thom> ok
<Keybuk> I'd be happy if someone not totally freakishly insane can prove this works <g>
<Kamion> fschoep: sure
<thom> *smirk*
<Spads> zul: ping
* _ion wonders if hunger_suse was using a "custom" dpkg as well. ;-)
<zul> Spads: pong
<Spads> zul: mind a pm?
<thom> Keybuk: oh well, rebooting
<zul> Spads: sure
<Keybuk> _ion: I have a vague memory of him once complaining that he always says "N" to all conffile prompts and has it set to never update them
<Keybuk> and got very broken by the hotplug->udev transition as a result
<_ion> keybuk: ...
<fschoep> Kamion: do you see my PM?
<StevenK> Keybuk: Because asking any questions during an upgrade is just asking for trouble, surely.
<Kamion> yes
<fschoep> OK, just checking since I use a different IRC client.
<_ion> dpkg could use a better UI for merging new changes to conffiles. An example of a good implementation: dispatch-conf from gentoo.
<thom> Keybuk: console owner screws the pooch quite impressively
<thom> Keybuk: it gets horribly confused between the input for cryptdisks and the input for console login
<_ion> thom: You'll probably need to modify tty* to "start on rcS" instead of "startup".
<thom> ah, right
<thom> right, that works just peachily 
<thom> and ion has fonts again, for a double win
<ogra> iwj, http://pastebin.ca/162384 <- kills my firefox 
<iwj> Hmm.  It's done something to mine too.
<ogra> thats only a Xor.0.log ...
<iwj> Stuck spinning the cpu.
<ogra> *Xorg
<iwj> Ah, here it is.
<ogra> nothing spectacular big or so
<iwj> It just took a minute or two to render.
<_ion> thom: What fixed ion's fonts? They went broken, and i was too lazy/tired to trace the problem, so i just switched to metacity temporarily.
<gnomefreak> iwj: you have a minute?
* hunger is in an upstart enabled system. I had to start cryptdisks manually though.
<ogra> hmm, i left it open more than a minute before killing ff
* hunger will try to figure out why this does not work:-(
<iwj> Every line in that is a separate <li><div ... !
<thom> _ion: wish i knew
<thom> dist-upgraded this am, and that reboot just cured it
<Keybuk> thom: did you change the tty thing as well?
<iwj> And much of the time individual fragments are <span class=...
<iwj> gnomefreak: Possibly.  What can I do for you ?
<gnomefreak> iwj: ff b2 fixes i would say 80% or more of the crashing issues that people are having. i compiled b2 and havent had a problem yet. not sure if you updated it
<iwj> No, I haven't.
<thom> Keybuk: i changed tty1 to be start on rcS ; and rcS to be console owner
<Keybuk> ok
<iwj> I was going to wait with a new ff until after feature freeze, since there's stuff I want to get in first.
<Keybuk> thom: and did that work better?
<thom> Keybuk: worked perfectly
<gnomefreak> and im not sure if you are maintainer of thunderbird too but is that gonna be 2.0 also?
<iwj> ogra: So I conclude it's a stupid web page.  Unfortunately firefox isn't clever enough to replace it with a box saying `this web page is too stupid, please shoot the designer'.
<iwj> gnomefreak: thunderbird> No, sorry.
<gnomefreak> k
<ogra> iwj, right ... looks like you have a way faster machine there ;) after 5 mins it shows up for me as well :)
<Hobbsee> iwj: hehe, perhaps you need to patch it?
<iwj> It's not a hugely new machine.  Athlon 2G.
<iwj> Hobbsee: In my CFT.
<thom> Keybuk: now to work out why ath0 is brought up but doesn't get configured
<Hobbsee> iwj: CFT, sorry?
<iwj> Copious Free Time.  :-).
<Keybuk> thom: /etc/iftab, make sure you have "arp 1" ?
<Hobbsee> iwj: ahhh...yes
<thom> Keybuk: don't have an entry for ath0 at all
<Keybuk> hunger: changing tty1 to "start on rcS" and rcS to "console owner" (not output) seems to fix it for thom
<Keybuk> thom: ok, so it's not a rename bug
<Keybuk> thom: don't suppose you have a bootchart there?
<thom> Keybuk: remind me later and i'll generate you one
<Keybuk> ok
<doko> pitti, Kamion, ogra: I would need some testers for OOo on powerpc (just starting ...)
<ogra> doko, already built ? 
<ogra> my ppc is heavily outdated
<doko> deb http://people.ubuntu.com/~doko/ubuntu/ edgy/$(ARCH)/
<doko> deb http://people.ubuntu.com/~doko/ubuntu/ edgy/all/
<ogra> Kamion, i dont have awk... before i make a mistake again, do i have sed in d-i ?
<Kamion> ogra: yes
<ogra> thanks
<ogra> just wanted to be sure :)
<hunger> Keybuk: I think I might know what is going wrong.
<hunger> Keybuk: The next reboot will show.
<dholbach> fschoep: pong
<jdong> stop me before doing something stupid, but is it safe to rm -rf /usr/share/doc?
<jdong> on a system extremely limited in free space :)
<_ion> That depends on your definition of "safe". ;-)
<jdong> the only thing I think I'll be losing is the ubuntu/kubuntu start pages
<jdong> right?
<jdong> it's 200MB of space I wouldn't mind having back
<iwj> jdong: Delete only the files and not the directories.
<iwj> Otherwise you'll get complaints from update-alternatives and the like.
<jdong> iwj: k, will do
<iwj> Also there are possibly other problems (eg, programs that automatically read bits of docs).
<jdong> hmm
<iwj> And perhaps the odd maintscript will fail, so good luck.
<jdong> :-/
<iwj> Worth a try though and do let us know how you get on :-).
* jdong looks into a fuse compressed fs instead :)
<jdong> at least there's a partial chance in data preservation.... :)
<jdong> anyone know of any reliable fuse compressed filesystems?
<jdong> there's so many to choose from
* jdong even considers converting to reiserfs -o tail
<thom> i find reiserfs an excellent way to save a lot of disk space
<thom> generally the whole partition after a few days
<Mithrandir> mmm, eraserfs.
<zul> w/in 19
<zul> doh..
<jdong> thom: lol
<jdong> thom: it's not that bad.... unless you run reiserfsck... then it's bad :P
<thom> jdong: no, it _is_ that bad
<jdong> novell/suse has been defaulting to reiserfs for years now...
<jdong> and personally, I've only damaged one reiserfs partition... by shrinking it
<mjg59> The fact that reiser3 is unmaintained is a damn good reason not to default to it
<mjg59> Suse can get away with it to some extent because they have developers who understand it
<iwj> Can any other filesystem yet do both shrink (at all) and online grow ?
<jdong> no, that's ext2/3 and reiserfs3
<iwj> ext3 can do online grow ?
<Mithrandir> there are patches for it, at least, yes.
<jdong> yeah, at least in fedora/rhel4 it can
<mjg59> With patches, I believe
<iwj> With patches.  Riiiight.
<jdong> does ubuntu not have the online grow patches for ext3?
<jdong> I could've sworn I've lvm-grown ext3 online before
<jdong> maybe that was in fedora
<jdong> nvm
<iwj> There have been patches to do this for ages.  I don't know any of the details but I have to ask: why aren't they in mainline ?
<maswan> iwj: xfs possibly jfs (neither does online shrink though)
<_ion> AFAIK any new features will not be added to ext3, instead they're developing ext3dev (to be ext4).
<ajmitch> iwj: iirc some at least went into mainline in 2.6.10
<maswan> at least I think that was the case last time I looked at it, I've never had reason to shrink a filesystem myself
<jdong> I'm not impressed with ext3 or reiserfs's shrinking capabilities
<jdong> I've trashed both before by shrinking
<jdong> grow's safe enough
<jdong> but shrink.... no
<lamont> pitti: ping
<pitti> lamont: pong, but busy; will read scrollback
<lamont> pitti: tossed it in the other window for you to read later
<janimo> heno: is gok staying the keyboard tool for edgy?
<heno> janimo: no, we are moving to onBoard: https://wiki.ubuntu.com/Accessibility/Projects/onBoard
<cbx33> LaserJock: !!!!!!!!!!!!!!!!!!!!!!
<janimo> heno: ok, I asked since I did not see the latter in the archives and in the scrollback someone  mentioned gok
<jsgotangco> Mr. Mantha!
<LaserJock> heh
<heno> janimo: it's just uploaded to universe, still in NEW I guess
<Kamion> that can be rectified
<Kamion> heno: er, it's not in NEW
<Kamion> http://librarian.launchpad.net/4126254/3wpP6vZEOR10PTJ96thymFJtrOO.txt <-- weird
<heno> dholbach: any idea where onboard has wandered off to?
<Kamion> you need to expect a new/accept message following an upload
<Kamion> and complain if you don't get one
<Kamion> heno: it's (probably) not dholbach's problem - I'm investigating on the archive side
<dholbach> heno: chris jones should have got a mail, not me
<Kamion> no, the signer gets a mail too
<dholbach> oh, hum - maybe I deleted it
<janimo> heno: so for the xubuntu-at-sok metapckage I should depend on onboard at-spi and gnome-orca?
<dholbach> it should be the virtkey and onboard source package
<heno> tortoise_: did you get such an email? ^
<Kamion> stop flailing :)
<Kamion> soyuz broke, see the URL I posted above
<Kamion> I'm just going to try reprocessing the upload and see if it fails a second time
<Kamion> I love Soyuz
<heno> ah, that reading of 'wierd', ok :)
<Kamion> give it four minutes for the cron job to fire
<tortoise_> heno dholbach: nope
<heno> janimo: actually if by 'sok' package you mean for the onscrean keyboard, you only need python-virtkey and onboard
<heno> janimo: it doesn't need at-spi 
<G0SUB> pitti: I have fixed a lot of bugs today ... just trivial ones remaining
<heno> janimo: the Orca stuff on the other hand does
<Kamion> virtkey failed too
<Kamion> what's going on
<heno> janimo: btw, did I send you the link to this post of a guy using Xubuntu as a magnifier system? http://www.ubuntuforums.org/showthread.php?t=236401
<Kamion> well, I've dumped it back into incoming too - we'll see
<heno> It seems to work quite well for him
<janimo> heno, you did not, I am looking at the link now
<Kamion> there, that landed in NEW now
<janimo> heno, by sok package I mean one of the three packages (mag, speech, sok) mentyioned in the xubuntu a11y spec you drafted in paris. The other two ar e uploaded already
<heno> janimo: right, in that case my explanation above is correct. onboard does not need at-spi (and has changed name from sok). It needs gconf from gnome though (tortoise_ will know the details of where and why)
<Kamion> virtkey and onboard source both accepted
<dholbach> nice - thanks Kamion
<jdong_> where are my fancy charge/discharge graphs in gnome-power-manager
<jdong_> one of my laptops shows them, the other doesn't
<heno> thanks Kamion (/me adds them to the main inclusion queue)
<Kamion> woo, gen_keymap ran successfully
<pitti> G0SUB: niced
<thom> Kamion: after how long? :)
<Kamion> thom: once I brutally reduced the list of keymaps it was working on, not that long
<Kamion> it's taken me all day though
<Kamion> zul: around? (xen-edgy)
<carlos> seb128: hi, around?
<doko> ogra: are you currently upgrading for the OOo test on powerpc?
<zul> Kamion: yep
<Kamion> zul: I was wondering if you could elaborate on the "still blocked on the builds" comment in the spec's status whiteboard
<zul> Kamion: its not blocked anymore i think it was when it was sitting in new
<Kamion> zul: ok, could you update it then? is the spec basically Implemented, or is there more to do?
<janimo> heno, in that case does it make more sense to name the package xubuntu-at-keyboard?(onboard?)Or do you have a better suggestion?
<heno> janimo: xubuntu-at-keyboard sounds good
<zul> Kamion: its basically implemented i have to add some 3rd party drivers but thats what Im working on now
<zul> now/tonight
<Kamion> zul: ok, thanks
<_ion> Btw, what's the point of mounting /lib/modules/$(uname -r)/volatile as tmpfs and putting 18 megs of stuff in there?
<_ion> s/point/purpose/
* mjr has assumed that the binary-only modules can belinked there so that they work better across slightly different kernel vresions, or something
<mjr> don't really know tho
<jdong_> _ion: to make you buy more RAM?
<mjr> to make you create a swap partition? :] 
<zul> Kamion: done
<Kamion> zul: great, thanks
<bluefoxicy> damnit
<_ion> Sure, it can be swapped away, but that's still 18 MiB worth of RAM or swap space.
<bluefoxicy> OOo is broken.  Horribly.
<_ion> bluefoxicy: What else is new? ;-)
<bluefoxicy> _ion:  I mean more than usual.  Export to PDF; Open; and Save As cause crashes
<hunger> Keybuk: Still around?
<tortoise_> janimo: At the moment onboard needs gconf and the python bindings pull in most of gnome so i'm not sure if onboard is suitable for xubuntu at this point.  I'm hoping to change that though.
<bluefoxicy> aaargh.
<bluefoxicy> How do I convert .odt to Word XP with broken OOo
<seb128> carlos: pong
<carlos> seb128: hi, do you know why the network monitor applet takes a huge space of my panel when monitoring a wireless device?
* carlos speaks about Edgy
<kozz> Kamion: The DVD works on Pegasos now, nice :)
<seb128> carlos: you want to speak to dholbach, iz artwork bog
<dholbach> seb128: is not
<dholbach> seb128: the artwork didn't change
<dholbach> seb128: at least that part of it
<dholbach> i meant to look at it, but didn't do it yet
<seb128> dholbach: but it probably doesn't provide an icon to the required dimension
<seb128> you can then argue if the panel should manage
<seb128> or if we should ship the icon for it :p
<carlos> so it's a known bug
<dholbach> the code in netstatus applet changed - I'll look it up
<carlos> right?
<dholbach> there's a bug filed already, yes
<carlos> ok
<seb128> carlos: yep
<dholbach> thanks carlos
<carlos> dholbach: do you know the bug number?
* carlos wants to subscribe to it
<janimo> tortoise_: are you planning the change before edgy?
<janimo> which parts of gnome besides gconf are you using?
<tortoise_> I'm hoping to start it soon but I doubt it will be.  I only use gconf at the moment.
<janimo> I need to fix the pygconf pulls in whole gnome issue because it affects an increasing number of apps
<janimo> tortoise_: fixing that is easy in the python-gnome binding package, it only needs the agreement of the debian maintainers of that
<seb128> carlos: https://launchpad.net/distros/ubuntu/+source/gnome-netstatus/+bug/57626
<Ubugtu> Malone bug 57626 in gnome-netstatus "Network Monitor Icons look stretched out on 1280x768 resolution" [Untriaged,Confirmed]  
<carlos> seb128: thanks
<seb128> np
<Sp4rKy> hi
<Sp4rKy> please does anyone using edgy could paste me the result of apt-cache policy libxss1
<tortoise_> janimo:  True but I need to do it for Kubuntu too.  Gconf itself pulls in orbit etc.
<janimo> tortoise_: does your app use gcoinf keys which are visible/used by other apps in the desktop or just as a convenient way to store some private settings?
<janimo> if you need it to read system wide a11y settings I am not sure there's a better way
<janimo> if it
<janimo> is the latter though gconf can be avoided
<tortoise_> janimo: no I dont.  Just for storing private settings
<tortoise_> yeah
<janimo> tortoise_: then maybe ConfigParser or what it is called could be good enough, uses INI style config files
<tortoise_> Currently the settings and the keyboard are handled in separate apps so I would need to notify onboard of changes made by the settings app
<janimo> oh, so you use gconf notification api
<tortoise_> janimo: yep, it's very convenient.  Someone really needs to write a desktop neutral gconf that uses dbus.
* janimo wonders wheter there are dbus people around to jump with suggestions.
<janimo> tortoise_: there is such a gconf but was not in kainline I think nokia uses it
<janimo> s/kainline/mainline/
<jdub> tortoise_: gconf will eventually hit gtk+/glib anyway, most likely the d-bus version
<jdub> tortoise_: so all this effort going in to avoiding it is pretty wasteful
<janimo> tortoise_: anyway if it's convenient use it, I need to fix the gnome-python bindings anyway, can't expect all pygconf users to find other APIs
<jdub> tortoise_: particularly when you benefit from notification, etc.
<tortoise_> jdub: In the long time, yes
<tortoise_> */time/term
<seb128> Kamion, Mithrandir, mvo: what is the recommended way to change the default language on a ubuntu installe, changing /etc/environment by hand?
<jdub> might not be as long term as you think :-)
<janimo> jdub: you think it could be 2.12?
<jdub> probably not 2.12
<janimo> then that is long-term :). two gtk release cycles at least, and those are open source years ;)
<tortoise_> I was hoping to make onboard toolkit neutral too.  I do all the rendering in cairo so I was hoping to have the event handling pluggable qt/gtk.
<janimo> tortoise_: kde guys will probably not want cairo but you'd have to use qt/arthur
<tortoise_> doesn't kpdf use cairo?
<janimo> I don;t know
<Kamion> kozz: woo, glad to hear it
<janimo> kpdf uses poppler, so whatever poppler uses
<Kamion> seb128: language-selector, I thought; it ought to change /etc/environment and /etc/default/locale (if not, it's a bug)
<janimo> I think it has both cairo and arthur (at least experimental) in it
<seb128> Kamion: ok, thank you
<Riddell> tortoise_: no
<tortoise_> Riddell: Ok, scratch that then
<tortoise_> does Kubuntu ship gtk?
<jdub> tortoise_: you are entering a world of pain... :-)
<tortoise_> lol
<janimo> tortoise_: it doesn't, it has the 'k' in the wrong position
<jdong_> LOL
<Riddell> tortoise_: no
<Riddell> trappist: .ini style config files should be easy enough to read from both gnome and kde apps
<trappist> Riddell: that makes sense - this relates to a bug I commented on a long time ago?  I have a very vague recollection.
<mdz> morning
<_ion> Evening.
<zul> afternoon mdz
<mvo> hello mdz
<pitti> hey mdz
* jdong_ waves to mdz
<pygi> ho pitti :)
<mdz> the inbox hits!  the inbox hits!  you feel hemmed in.
<pygi> pitti, we've got first released app using libburn, whee :)
<pitti> pygi: \y/
<pygi> Brasero (aka old Bonfire)
<_ion> You die. Do you want your possessions identified?
<pygi> _ion, ahm? :)
<pygi> pitti, we need libburn package soon so we could make brasero package libburn-enabled
<pygi> and libisofs while we're at that :)
<Kamion> mdz: evening
<tseng> breezy had gtk+ with cairo right?
<jdub> tseng: yeah
<jdub> tseng: 2.8.6
<keescook> pitti: you seen this? http://www.suse.de/~krahmer/no-nx.pdf remote code execution even with nx bit.  :P
<tseng> jdub: cool
<pitti> keescook: ouch
<tseng> jdub: i just updated to dapper and xming windows clients are running slower
<pitti> keescook: hello, nice to see you again
<tseng> jdub: trying to think of why
<keescook> hiya!  :)
<janimo> pitti: what is till's nick?
<pitti> janimo: till
<pitti> janimo: he's not online ATM
<janimo> ok
<Kamion> Mithrandir: http://people.ubuntu.com/~cjwatson/tmp/console-setup-keymapper.diff
<Kamion> Mithrandir: first cut at gluing keymapper/cdebconf-keystep into console-setup; installer integration totally untested; review welcome
<Kamion> (this is for sane-installer-keyboard, for those playing along at home)
<Kamion> you'll need to wait for buildds to get around to keymapper 0.5.3-5 in order to build it
<HiddenWolf> Kamion: will that improve user experience or just reduce maintainer headaches? 
<Kamion> HiddenWolf: hopefully a bit of both
<Mithrandir> Kamion: it looks good to me, but I've read it, not tested it.
<Kamion> HiddenWolf: no more skew between console and X keymaps
<Kamion> there will likely be a certain amount of teething trouble of course - it's a big change
<Kamion> and it's still possible it won't make edgy - we're kind of close to the wire
<heno> Kamion: heh, looks like I need to do some fresh Live CD a11y testing :)  I can't remember how that works now
<heno> I swear I've tested ubiquity with at-poke in the past and that most stuff shows up though
<heno> But my memory is not always to be trusted ...
<Kamion> heno: I can't figure out how, that's all :)
<Kamion> I thought this was why you'd made livecd-access depend on sudo-admin-atspi
<janimo> heno, thinking more about it, I think the two keyboard apps could be installed by default in xubuntu w/o any metapackage for them
<janimo> as soon as I fix their python-gnome dep
<heno> Kamion: yep, and people have reported problems using it. (anyway I'll check later to make sure)
<heno> The good news is that people are happily using the Knot 2 CDs to test Ubuntu as a platform with screen reading, which is great in itself
<heno> janimo: that would be very cool!
<heno> janimo: I remember tortoise_ was looking into that as well
<heno> tortoise_: which part was it that pulled in most of gnome?
<Kamion> Mithrandir: any chance you could fix the way that xkeyboard-config is listed as a transitional package but yet contains all the data that should be in xkb-data? I think that's what's breaking the console-setup build.
<Kamion> bug 59220
<Ubugtu> Malone bug 59220 in xkeyboard-config "Falsely claims it can be safely removed" [High,Confirmed]  http://launchpad.net/bugs/59220
<Mithrandir> Kamion: oh, true dat, I need to fix it.
<janimo> heno: I talked to tortoise about it an hour ago
<janimo> it's only gconf but the rest of gnome libs come in via the python-gnome bindins
<janimo> I know how to fix this
<heno> janimo: ah ok, all in good hands then :)  Thanks for looking at this
<heno> Cool, that will help us for other DEs too
<heno> janimo: I guess removing gnome deps from gtk apps is one of your specialities :)
<Kamion> Mithrandir: should we be putting console-setup-fonts-udeb in the d-i initrd? I notice that console-setup-udeb doesn't depend on it
<janimo> heno, yeah :). The hard poart is talking to gnome people about it not the technical bits ;)
<Kamion> it doesn't seem necessarily required, since we have unifont for the installer UI
* Kamion -> dinner
<Mithrandir> Kamion: unsure, I think we might want it?
<dieman> ben collins rocks for getting custom kernel builds so easy now
<jdong> dieman: how easy is it?
<janimo> dieman: what changed besides dropping the various architecture flavours?
<dieman> the KernelCustomBuild wiki page has deets
<dieman> took me about 15 minutes to pull down his git archive, roll in a patch, and start compiling
<zyga> hey
<janimo> dieman: thanks for the link, indeed looks easier than it used to be
<jdong> yeah, looks promising for those blessed with the task of modifying edgy's kernel :)
<dieman> yeah, i need the web100 patch for a set of machines
<dieman> and netem, but netem was already there
* jdong wonders if reiser4 patches cleanly into edgy's kernel
<jdong> (probably not)
<G0SUB> pitti: I got two people to test the app and they found no bugs
<pitti> cool
<G0SUB> pitti: in fact they are still testing it as we speak
<Seveas> mjg59, (irl got in the way today -- final theming patches, including example theme will arrive in a few hours)
<mjg59> Seveas: No problem
<mjg59> Seveas: I uploaded a package with a 256 colour image, just to see if anyone would notice
<janimo> mvo: ping
<mvo> hello janimo
<janimo> mvo: hello
<janimo> at one point update-manager was using gamin directly?
<mvo> janimo: update-notifier? sort of, it used the fam interface. but I switched to gnome-vfs because gamin was not very reliable
<mvo> gnome-vfs uses inotify directly and I haven't had trouble since
<janimo> hmm ok. wasn't sure whether gvfs used gamin or inorify. thanks
<mvo> janimo: gnome-vfs is not ok for xubuntu?
<janimo> mvo, we tried avoiding it so far
<janimo> even though now it is somewhat leaner w/o bonobo
<mvo> janimo: I use basicly only gnome_vfs_monitor_add()
<janimo> mvo, right I rememebr checking out the code and wondering what was going wrong with gamin
<mvo> I had all sort of problem of it not detecting changes
<janimo> as thunar and xfce desktop use gamin directly we are porbbaly exposed already to whatever nastiness it holds :)
<janimo> I wonder how evil it would be to use inotify directlty. That would mean linux only though
<mdz> slomo: I saw a bunch of scrollkeeper errors from the current tomboy; do you know what the cause is?
<mvo> janimo: I looked into this for update-notifier, its not terrible bad, but a bit cumbersome
<mvo> janimo: while I have you here, do you know why "xubuntu-desktop" is in section: misc?
<mvo> kamion, mdz: what do you think about adding a "metapackage" section for the various "ubuntu-base,minimal," etc? this way we could enable --install-recommends by default for this section only and dodge the big "cleanup-recommends" work for now
<janimo> mvo: hmm I think there is no section for xfec like ther is for gnome and kde IIRC
<mdz> mvo: I like that idea
<zyga> did anyonce notice udev libsane problem at boot?
<mvo> mdz: the apt patch is ready, now I need to look into germinate
<jdong> zyga: yes, there is an error about it on bootup
<crimsun> jdong: it's a comment anyway, so it doesn't matter ultimately.
<ogra> grmbl ... db_subst doesnt like me :/
<crimsun> there's a bug reported on it
<jdong> crimsun: ok, that makes me feel better :)
<slomo> mdz: will  look at it later... but afaik they were there from the first version with scrollkeeper docs,i.e. 0.3.9 or something
<HiddenWolf> mjg59: and, did they notice? :)
<G0SUB> pitti: it'd be great if you do a review again tonight
<bluefoxicy> all that just to get UID 1000 on the LiveCD
<pitti> G0SUB: I'll try to manage
<G0SUB> pitti: if you tell me I will be there when you are free
<G0SUB> pitti: any way I am going to mail you in a while mentioning the changes made today
<mdz> slomo: I guess they're only visible because of the way that tomboy is running scrollkeeper in postinst
<janimo> heno: which are the main differences from an a11y user pov between a gnome and a gtk only app? For instance do gaim and abiword lack something because they do not use gome libs?
<jdong_> janimo: less ram usage? :)
<jdong_> maybe less integration with gnome
<janimo> jdong_: I am intersted in the psecifics, especially if there is some drawback with gtk only
<heno> janimo: I don't think there is much in it. Certainly gaim is known to work well with Orca
<heno> I have no idea if it relies on using any Gnome libs in doing that. I would think not
<janimo> heno, because one of the reasons some maintainers seem to stick to gnome deps is that gnome_program_init sets up some extra a11y stuff
<janimo> but I think I'll check out the source as this may not be as serious as it is said to be
<janimo> there is a libgail-gnome module which is only used in gnome apps
<janimo> and I think bonobo using apps rely on this initializations too. but most gnome apps are thankfully no longer using bonobo
<ogra> Kamion, http://people.ubuntu.com/~ogra/netscript.templates and http://people.ubuntu.com/~ogra/netscript, any hint why the interface selection doesnt work ?
<Surak> Hi guys
<janimo> heno, it seems that if apps use widgets defined in gnome libs as opposed to proper gtk ones they need that gnome_program_init otherwise not
<janimo> I am gathering ammo for fighting gnome_program_init you know ;)
<heno> janimo: I think bonobo is somehow part of the a11y chain though
<heno> heh, right
<heno> I just tested Abiword with Orca and it seems to work well
<janimo> heno: yes,  it is used by at-spi
<janimo> bonob that is
<Surak> I've noticed that sl-modem-daemon is not being shipped for amd64 both in ubuntu and debian. Anyone knows why? I've seen people at linmodems patching it for amd64...
<heno> janimo: so how do you get around that?
<janimo> the idea is if a11y can take advantage of these gnome bits _runtime_ there is no need for hard depending on them
<heno> I see
<janimo> heno: gtk_init() does all of program initialization which is needed by a gtk app
<janimo> most gnome apps still; use gnome_app_init though, because of historical reasons I guess
<janimo> it has the convenience of seting up bug buddy in case of crashes
<janimo> soem of the a11y stuff for apps that use custom gnome widgets and maybe some more
<janimo> instead of relying on bug buddy I'd rather keep the code leaner and hence less buggier :)
<heno> wise
<heno> From a a11y perspective, simple non-custom widgets are preferred to ensure that the AT apps know how to read them
<janimo> exactly, that is what most apps use anyway, so no extra a11y setup is needed besides having the environment set up
<Kamion> ogra: debconf choices need to be separated by comma-space, not just space
<Kamion> ogra: so:
<Kamion> db_subst ltsp-client-builder/dhcp-interface choices "$(echo "$IFACE_LIST" | sed 's/ /, /g')"
<ogra> yep 
<ogra> thats somethig i figured since i asked, but the choice still isnt presented
<Kamion> if that still doesn't work, I suggest capturing a trace with DEBCONF_DEBUG=5 set as a boot parameter
<jdong> any idea what would cause a usb mass storage device to give me " reset high speed USB device using ehci_hcd and address" errors?
<jdong> it happens only in linux on this laptop
<jdong> not in windows
<jdong> does not happen in linux on my desktop
<mdke> who has access to changing the html on cdimage.u.c?
<Kamion> ogra: 'set -x' wouldn't hurt either - you'd get most of the information from that, and you don't need to reboot to do that
<Kamion> mdke: me
<mdke> Kamion: can you take bug 59161 pls?
<Ubugtu> Malone bug 59161 in ubuntu-website "knot 2 page empty" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59161
<ogra> ooooh
<ogra> Kamion, thanks a lot ... ! works :)
<Kamion> mdke: send it over to the ubuntu-cdimage product
<Kamion> ogra: what was wrong?
<mdke> Kamion: ok. Ditto for bug 58800?
<Ubugtu> Malone bug 58800 in ubuntu-website "Release page should link to other derivatives" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58800
<Kamion> mdke: yeah
<mdke> okies
<mdke> thanks
<Kamion> that one's harder to fix quickly, it needs to be scripted in order to stay fixed
<ogra> i had the interfaces hardcoded with comma at the top *and* substituted the commas at the same time ...
<ogra> hmm, now the output is wrong ... but i'm getting there :)
<Kamion> ogra: ah, right
<jdong> hmm, after the usplash upgrade, my screen turns off during the Loading Hardware Drivers stage
<jdong> never to turn on again
<jdong> turning off splash makes everything work again
<Keybuk> Mithrandir: ping?
<Mithrandir> Keybuk: hi
<Keybuk> Mithrandir: odd mailman problem, you might know the answer
<Keybuk> it's base64-encoding someone's e-mails in the archive
<Mithrandir> you're using pipermail?
<Keybuk> http://lists.netsplit.com/pipermail/upstart-devel/2006-September/000046.html
<Keybuk> e.g.
<Keybuk> yes
<Keybuk> dapper packages
<Mithrandir> oh, special
<Mithrandir> what does it look like in the mbox?
<Keybuk> where do I look?
<_ion> The common things in the emails: they contain a character not representable by ISO-8859-1, and they are signed with PGP.
<Mithrandir> /var/lib/mailman/archives/private/upstart-devel.mbox, iir
<Mithrandir> +c
<Keybuk> they look normal in the mbox
<Keybuk> Content-Type: text/plain; charset=utf-8
<Keybuk> Content-Disposition: inline
<Keybuk> Content-Transfer-Encoding: quoted-printable
<Amaranth> It's not just that guy's emails
<Mithrandir> Keybuk: hmm, weird.  Looking
<Keybuk> I could try updating it to the edgy packages, and see if that works better?
<Mithrandir> they're the same, iirc
<Keybuk> 2.1.5 vs 2.1.8
<rodarvus> Keybuk, I tried to subscribe to upstart-devel a few days ago (using my @ubuntu.com mail address), but got no response from mailman
<Keybuk> rodarvus: try again
<rodarvus> *nods*, will do
<Keybuk> you're not in the list
<rodarvus> yes, I haven't even received the confirmation message from mailman
<Keybuk> rodarvus: how did you subscribe?
<rodarvus> via the web interface
<rodarvus> on lists.ubuntu.com
<rodarvus> I just retried so again, just for the sake of it
<_ion> Do you mean lists.netsplit.com?
<rodarvus> yeah.
<rodarvus> thinko
<Keybuk> Sep 06 21:37:07 2006 (28772) upstart-devel: pending Rodrigo Novo <rodavus@ubuntu.com>  200.146.22.15
<Keybuk> Sep 06 21:37:27 2006 (288
* Keybuk hands you a new 'r' key
<rodarvus> :D
<rodarvus> haha
<Keybuk> you made the same mistake on Friday too
<Mithrandir> Keybuk: sorry, I can't find any mention of it doing base64 encoding in the archiver at all
<Keybuk> Mithrandir: kooooky
<Keybuk> Mithrandir: md5 perhaps?
<rodarvus> Keybuk, I used autocompletion to fill the form today
<Keybuk> no, it's definitely base64 ... has the silly ==s
<Keybuk> not rot13, doesn't look like Welsh
<_ion> keybuk: It is base64. When decoded, it outputs the message plus some pipermail content.
<rodarvus> Keybuk, thanks
<Mithrandir> Keybuk: it decodes to:
<Mithrandir> Hi
<Mithrandir> Where (or by whom) is the process of migrating stuff from Ubuntu edgy
<Mithrandir> rcS to upstart jobs planned or coordinated?  I'd like to help where i
<Mithrandir> can, but i don't want to step on anyone's shoes.
<Keybuk> _ion: yeah, so it does
<Mithrandir> so it's certainly decodable and base64.
<mjg59> elmo: Are you guys doing Linuxworldexpolala this year?
<Mithrandir> Keybuk: can you put the list archive mbox somewhere I can get at it?
<Keybuk> Mithrandir: I can give you temporary root on the box, if you want :p
<elmo> mjg59: in the UK?
<Mithrandir> Keybuk: I'd rather just have the mbox, if I can't get anything useful out of that (and maybe getting the message bounced to me), I can't really get anything useful out of it.
<mjg59> elmo: Yeah
<Keybuk> Mithrandir: ok
<Keybuk> http://paperboy.netsplit.com/upstart-devel.mbox
<elmo> mjg59: I'm not sure, sorry - I can ask tomorrow
<mjg59> elmo: Ok, no problem
<slomo> mdz: right... but this should only happen when updating from 0.3.9+dfsg-0ubuntu1 or 0.3.9+dfsg-0ubuntu2. and iirc most of those errors were in scrollkeeper stuff not from tomboy. what shall i do about it? normally nobody would ever see this unless he had one of the two broken versions installed
<mdz> slomo: no worries
<ge_ubuntu> is upstart already in Dapper updates?
<Burgwork> ge_ubuntu, no
<ge_ubuntu> it will be first in Edgy?
<ogra_> Kamion, http://people.ubuntu.com/~ogra/netscript and http://people.ubuntu.com/~ogra/netscript.templates ... i think i'm done and will add it to the postinst if you dont find any blockers
<Burgwork> ge_ubuntu, yes
<ge_ubuntu> may I be little off topic?
<Burgwork> not really
<ge_ubuntu> this is about ubuntu still :)
<Burgwork> ok
<ge_ubuntu> I just don't know where to post, where Ubuntu team will hear
<ge_ubuntu> What will be your filling, if
<ge_ubuntu> Ubuntu will be chosen to be the OS in all the schools in the whole country?
<ge_ubuntu> the country is Georgia, a small country though. about 4 mln
<ge_ubuntu> with about 3000 schools
<Mithrandir> Keybuk: it doesn't really make any kind of sense.. :-/
<Keybuk> Mithrandir: to me neither :p
<Keybuk> does it do the same to you then?
<Mithrandir> Keybuk: I'm just trying to understand the code paths; it's been a while since I poked at mailman
<Kamion> ogra: yes, looks mostly ok. you should change Description to _Description in the .templates file; assuming you're just going to add that to ltsp-client-builder.templates (are you?), then run debconf-updatepo after you've done so to update the .pot and .po files
<ogra> yup
<ogra> its just for running it locally
<Kamion> ogra: "please select the interface you want to to use for the Thin Client Network." -> "Please select the interface you want to use for the thin client network", IMHO
<ogra> if i run it in terminal with the underscore debconf complains
<mjg59> Kamion: The new gparted stuff is much nicer, BTW
<ogra> ok
<Kamion> mjg59: 0.3?
<ogra> corrected locally
<Kamion> mjg59: and how so? I haven't played with it yet
<mjg59> Kamion: Uh, no, whatever's happening in the installer now
<mjg59> Rather than in dapper
<Kamion> ogra: right, debconf needs Description without underscore - po-debconf does the translation
<Kamion> mjg59: oh, right, good
<ogra> yup
<Kamion> it's not as good as I'd like (I'd like to kill gparted, but that's edgy+1 now), but it's a bit less rough
<ogra> mjg59, did you get my ping this morning ?
<Kamion> since ubiquity-advanced-partitioner is deferred, I'm going to have to add reiserfs support without libreiserfs to qtparted
<mjg59> ogra: Nope
<Kamion> how much fun
<ogra> the glowing consoles on my laptop are gone ... they are "no-chars and stripes" now 
<ogra> mjg59^^
<mjg59> ogra: I'm looking into that
<ogra> ok, so you know about it ... fine then :)
<mjg59> Kamion: So I've just booted an amd64 daily, and in the live environment I'm certainly not on sub-pixel
<mjg59> anti-aliasing
<Kamion> mjg59: ok, must be a fontconfig bug
<ogra> mjg59, start firefox .. thats even worse
<mjg59> Yeah
<mjg59> Oh, hurrah
<mjg59> Latest HP bios fixes the "My nx6125 runs REALLY REALLY SLOWLY" problem
<mvo> mdz: I just talked to cprov about the new metapackages section and he said it would be very easy to add this section to the database. we just need your ok :)
<mdz> mvo: "ok"
<ogra> heh
<mdke> hehe, with two simple letters, mdz sets wheels in motion
<mjg59> Kamion: Hmm. ubiquity crashed.
<mjg59> Filing a bug now.
<Seveas> mjg59, changes pushed to lp but will probably take some time to appear (LP builtin delay)
<Seveas> mjg59, to sum up: add a -v flag and suppress text by default, 'verbose' on the kernel command line will enable text. Split off a -dev package for out-of-tree theme building and added bling bling example theme with instructions on how to create a theme
<Seveas> I also changed INPUT to make sure text was displayed if usplash is runnign without -v :) 
<mjg59> Seveas: Rocking
<Seveas> is usplash_down actually used? If so, I'll fix that one up too
<mjg59> It's meant to be, isn't it?
<mjg59> I'm not sure offhand, though
<Seveas> because a) it doesn't yet use /etc/usplash so resolution on shutdown != resolution on startup and b_ it doesn't know about -v
<Seveas> mjg59, also, INPUT needs a bit more bling bling love, but that won't make feature freeze
<mjg59> Kamion: Looks like it's unhappy if the attempt to get security updates fails
<mjg59> Seveas: Yeah, no worries
<Seveas> anyway, artwork people will be happy
<pitti> mjg59: did you see my ftbfs fix patch? I hope it doesn't break on i386
<mjg59> pitti: Getting to that
<Kamion> mjg59: hmm, ok, I'll look later - buried in console-setup and friends right now
<mjg59> Sure, no problem
<Keybuk> Seveas: why "verbose", why not "remove quiet" ?
<Seveas> Keybuk, point
<Seveas> mjg59, I'll change it to Keybuks suggestion when fixing usplash_down (next on my list after grabbing something to drink)
<Keybuk> Seveas: which bzr archive is this in?
<mjg59> Seveas: Sure
<Seveas> bazaar.launchpad.net/~dennis/usplash/theming iirc
<Seveas> (bzr remembers push urls, so I don't have to :))
<Keybuk> ok, just wanted a look
<Keybuk> need to work out how to harmonise this with the usual boot messages
<Seveas> this probably isn't visible via lp yet
<Seveas> it has a dela
<Seveas> y
<Keybuk> Seveas: what are the main changes?
<Keybuk> mjg59: your branch still exhibits the "nukes the console" bug :p
<Seveas> Keybuk, since the current edgy package or everything I did in the past few days? (current edgy package already has the bling bling)
<Keybuk> Seveas: what's the bling bling?
<Seveas> mainly support for 256 colors in the code and themes being able to override drawing functions for text and progress bar
<Keybuk> what are the text changes ?
<Seveas> no text by default, usplash can handle text input (not my work), no other changes
<slomo> Seveas: as you're working on usplash... do you know if someone is working on fixing it for ppc? i still get bogl saying that it doesn't like my framebuffer (if you want the real output i'll write it down tomorrow)
<Keybuk> mjg59: meh, is there any particular reason you added "Edgy Eft Edition" to the usplash testcard?  The intent was that the testcard be completely neutral so that other distributions didn't need to fork the usplash package
<Keybuk> Seveas: what happens when it gets the TEXT message?
<Seveas> it scrolls existing text up and displays new text
<Seveas> (only if running as usplash -v)
<Keybuk> right, what happens if the TEXT is "Press ENTER to reboot." or "fsck failed", etc.?
<Seveas> you would want to change TEXT to INPUT 
<Seveas> or rather the still hypthetical INPUT_ENTER which doesn't echo anything
<mjg59> Keybuk: To provide evidence that something was actually happening in the development
<mjg59> Keybuk: Sorry, you never mentioned that feature
<mjg59> Keybuk: "My branch"?
<mjg59> I work on trunk...
<Keybuk> mjg59: the one you last committed to :p
<Keybuk> sladen and I did talk about making a new hi-res "C" testcard
<Trae> Keybuk, https://launchpad.net/distros/ubuntu/+source/acpi-support/+bug/22336/comments/55 see my comment re: fixed for Edgy?
<Ubugtu> Malone bug 22336 in acpi-support "laptop overheats when performing CPU intensive tasks." [High,Confirmed]  
<Keybuk> we'd need a blackboard, some chalk, a fluffy tux, a digital camera, and you for that though :p
<sladen> mjg59: testcard=unbranded and means that usplash never gets revved, only artwork
<Keybuk> Trae: still "Confirmed", so no, not fixed for edgy yet
<sladen> mjg59: mind if I roll it back?
<sladen> mjg59: (possibly replacing it with some overridden artwork?
<Trae> ahh ok...  My question is whether or not we should expect it to be fixed for Dapper or Edgy.  
<mjg59> sladen: Sure, no problem, but it would be nice to leave more than 16 colours in it
<Keybuk> Trae: and unless there's a patch that fixes it on that bug, there's no known way to fix it
<mjg59> Trae: Quite possibly fixed in edgy
<Trae> mjg59, k
<Keybuk> mjg59: what did you change?
<mjg59> But depends on what the failure is in your case
<mjg59> Keybuk: powernowd bails and uses ondemand where possible
<Keybuk> mjg59: yeah, that hasn't fully fixed it for Trae
<mjg59> Ok, then no, it's not fixed
<Trae> mjg59, my failure is a problem where the laptop shuts off when viewing a video.  I thought it was fixed one time.... but it came back later.
<Trae> Keybuk, did you ever see what I posted on the bug ?  about my /etc/rc.local 
<Trae> Keybuk, perhaps I put something in wrong.
<Trae> cause it only came back after the reboot
<Keybuk> Trae: oh
<Keybuk> yeah
<Keybuk> sh -c 'echo -n ondemand > sys/devices/system/cpu/cpu0/cpufreq/scaling_governor'
<Keybuk> should be just
<Keybuk> echo -n ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<Trae> Keybuk, heh, if that's the case then perhaps it _IS_ fixed.
<Keybuk> note the extra "/" :p
<Trae> OMG
<Trae> eye am sofa king we todd did
<Keybuk> (and you don't need the sh -c ' ' bit)
<Trae> Keybuk, let me try that again for grins
<mjg59> Keybuk: I think I've got a handle on the console restoration
<mjg59> At least, one that works here for me
<Keybuk> I'm guessing by the sudden requirement of an INPUT option that usplash somehow displays on something *other* than /dev/console ?
<Trae> Keybuk, should I need the path to echo ?
<Seveas> mjg59, when is usplash.conf created?
<mjg59> Seveas: On installation
<Keybuk> Trae: no, that's a builtin :p
<Trae> Keybuk, ok.. hehe
<mjg59> bzr: ERROR: Unsupported protocol for url "sftp://bazaar.launchpad.net/%7Eubuntu-core-dev/usplash/ubuntu/": Unable to import paramiko (required for sftp support): No module named paramiko
* mjg59 cries
<Kamion> install python-paramiko?
<mjg59> Yes
<sladen> Recommends:
<Kamion> well, paramiko isn't needed for e.g. bzr get http://
<mjg59> Yeah
<Trae> Keybuk, http://www.shorttext.com/3a6i7
<Kamion> I'm not sure, it's one of those difficult edge cases
<mjg59> Now, where was I...
<sladen> needs a Really-Recommends:
<Kamion> like syslinux and mtools
<Trae> Keybuk, can you triple check that for me please.
<Keybuk> sladen: Recommends is intended to be "really"
<Keybuk> Suggests is the "if you want"
#ubuntu-devel 2006-09-07
<Keybuk> Trae: that looks correct to me
<sladen> Keybuk: I was thinking of using /dev/input to draw a moveable mouse cursor.  The Mac has one and it's good UI feedback to the user that the system hasn't actually crashed
<Trae> Keybuk, nub nub :)  danke
<Keybuk> sladen: sick
<Trae> Keybuk, ok, let me reboot and try it... and see if I can get this thing to crash
<Trae> *chuckle*
<Keybuk> but yes
<sladen> Keybuk: Maclike!
<Keybuk> you can play "bounce the mouse cursor around the screen"
<Keybuk> which is my favourite hourglass game
<Trae> bbiab gang
<Keybuk> I'm guessing by the sudden requirement of an INPUT option that usplash somehow displays on something *other* than /dev/console ?
<Keybuk> mjg59, Seveas ^ ?
<Seveas> Keybuk, -ENOIDEA, the INPUT isn't my work
<mjg59> Keybuk: Nor mine
<Keybuk> who did the INPUT stuff?
<Seveas> (although I just patched it to support INPUTENTER for "Press enter to reboot" messages
<mjg59> But we've always run usplash with -c, which changes it away from the active terminal
<mjg59> Keybuk: Read the changelog :p
<Seveas> David Hrdeman implemented it according to debian/changelog
<Keybuk> mjg59: it's not mentioned
<Keybuk> mjg59: active terminal != /dev/console
<Kamion> gosh, d-i built with console-setup
<Kamion> now, will it even work a little bit
<Keybuk> mjg59: ah, yes it is, and it has your name by it
<mjg59> Keybuk: I really don't know what you're talking about
<Keybuk> revno 40
<mjg59> No, about /dev/console
<Keybuk> well
<Keybuk> what I'm trying to work out is why usplash suddenly needs an INPUT method
<Keybuk> why can't they just type as they always did, and whatever script was running get the key presses?
<mjg59> So that it can be done graphically
<Keybuk> "done graphically" ?  the typing bit
<mjg59> Yes
<Keybuk> right, but this is damned hard to deal with
<Keybuk> the script would have to do something like
<mjg59> Debian wanted it
<Keybuk> if usplash_is_running; then
<mjg59> We don't need to care
<Keybuk>    usplash_input ...
<Keybuk> else
<Keybuk>    read ...
<Keybuk> fi
<mjg59> But I still don't understand your comments about /dev/console
<_ion> . /some/file
<Seveas> Keybuk, or use someting like log_end_msg, but for inout
<_ion> read_maybe_usplash ...
<Seveas> where log_end_msg checks for usplash
<_ion> (Why am i still awake?)
<Keybuk> mjg59: so the old usplash ran in a virtual terminal (tty8)
<Keybuk> which happened to be framebuffered
<mjg59> Keybuk: It still does run in a virtual terminal
<Keybuk> right
<Kamion> if it's David Hrdeman, chances are it was for cryptsetup
<Keybuk> and usplash doesn't read() from that terminal?
<mjg59> No
<Keybuk> ok, it's probably fine then
<Seveas> I saw getchar() in the code
<Keybuk> that means any script read()ing from /dev/console (ie. any init script) would win and get the chars
* Keybuk wonders what usplash's stdin is
<Keybuk> probably /dev/console, not whatever-tty-it-changes-to :p
<Trae> ok.... let's give this joker a shot
<sladen> Keybuk: it may well be, ogra was having issues with it on ltsp machines?
<Seveas> Keybuk, sprintf(/dev/tty%d, vtnumber)
<Trae> hmm I get no volume.... I did fuser -k /dev/dsp
<Seveas> (if I interprete the code correctly)
<Keybuk> Seveas: ah yes, somebody's fixed that then
<Seveas> close(STDIN_FILENO);
<Seveas> open(foo)
<Seveas> will that open foo as stdin?
<Keybuk> yes
<ogra> sladen, my prob is rather the weird handling of start/stop in the usplash initscript
<Seveas> then it's indeed /dev/tty%d
<Keybuk> open always returns the lowest numbered unused file descriptor
<Keybuk> if you've just closed stdin, that will always be zero
<ogra> apart from that usplash is perfectly fine on ltsp
<Seveas> Keybuk, what's more useful: INPUTENTER, which waits specifically for \n or INPUTKEY which waits for the any key?
<Keybuk> where's the any key? :p
<Seveas> 
<Seveas> for cases like "press .... to reboot"
<_ion> keybuk: It's the : http://johan.kiviniemi.name/pictures/kb/naeppaeimistoe02.jpeg
<Trae> is there a reason why I would be able to play mp3 and ogg with Rhythmbox and not have sound with flash?  I don't have RB running, and I did fuser -k /dev/dsp
<Seveas> mjg59, new revision pushed (INPUTENTER and usplash_down)
<mjg59> Seveas: Thanks
<Trae> Keybuk I'm getting no audio, but I'll let it play to see what happens.
<Trae> that's a different problem for a different time
<Trae> heh
* Trae crosses his fingers
* Keybuk tries to decide what to do about console messages during boot
<Trae> Keybuk nope... it powered off
<Trae> :(
<Trae> Keybuk I like how gentoo does thekernel mesgs
<Trae> heh
<Trae> hmm
<Trae> maybe I'm thinking about something else
<Keybuk> how do gentoo do the kernel messages?
<mjg59> Keybuk: They have a hacked kernel
<mjg59> But anyway
<mjg59> Keybuk: Uhm. I'm not convinced that the problem you're describing "usplash results in my tty being invisible" is the same as "upstart doesn't always seem to start a getty on tty1"
<Seveas> I don't like "hey, let's put jpg decoding in the kernel" at all
<Keybuk> mjg59: the user reported the former 
<mjg59> Oh well
<Keybuk> I've just also seen the latter "go away" if usplash isn't used
<mjg59> Keybuk: Given that usplash is running on tty8, I really don't see how it could have any direct influence
<Keybuk> nonetheless, it seems to
<mjg59> Well, how is this usplash's fault?
<sladen> Keybuk: how just upstart /manage/ to fail to start a getty on tty1?
<Keybuk> I don't know, yet if you turn usplash off, it seems to work just fine
<mjg59> If upstart launches gettys on everything other than tty1, how is an application on tty8 influencing it?
<Keybuk> mjg59: ah, but getty is running on tty1 as well
<Keybuk> something nukes it
* mjg59 shrugs
<Seveas> mjg59, something in restore_console?
<Keybuk> and not in a "kill" way, but in a "fucks it up so it wedges" way
<mjg59> Doesn't happen with sysvinit
<Keybuk> I've seen it happen with sysvinit also
<Keybuk> which is where I stopped believing it was definitely upstart
<Seveas> usplash does nothing to tty1 but VT_GETSTATE and trying to switch back to it -- maybe svgalib or a video driver f*s up during the switch back?
<mjg59> Seveas: Wouldn't kill getty
<Seveas> <Keybuk> and not in a "kill" way, but in a "fucks it up so it wedges" way
<mjg59> Still won't matter
<Keybuk> mjg59: it doesn't _kill_ getty, is the point
<Keybuk> getty is still running
<Keybuk> and still select()ing on tty1
<Keybuk> just getting nothing
<mjg59> Seveas: FTBFS
<mjg59> helvB10.c:2:27: error: usplash-theme.h: No such file or directory
<mjg59> Looks like it needs a -I
<Seveas> odd
<Seveas> what were you trying to build?
<mjg59> dpkg-buildpackage
<Seveas> hmmm more
<Seveas> as that works here
<mjg59> Seveas: You've presumably got a usplash-theme.h in /usr/include?
<Seveas> urgh, yes
* Seveas shouts at self
<mjg59> Fixed here
<Seveas> if only pbuilder wasn't too slow to use it for all tests
<Seveas> ok, thanks
<Seveas> mjg59, would vga_setmode(TEXT); in usplash_done() hurt?
<mjg59> Seveas: Just added
<mjg59> It's actually slightly implicit due to the crack way that svgalib works, but
<mjg59> Seveas: Themes need to be built -fPIC
<Seveas> ok
<mjg59> Seveas: Other than that, all looks *very* good
<Seveas> good, that means my programming skills are still present
<Seveas> (/me actually does glibc ld.so hacking for work and graduation project)
<mjg59> Seveas: How's the different png sizes handled?
<Seveas> if no -x / -y given, it inspects the image struct to select a mode
<mjg59> Ok
<Seveas> if -x -y given, then usplash will fallback to testcard if image is too big
<mjg59> Right
<mjg59> Do we have support for images of multiple sizes?
<Seveas> if you call "create the same theme a few times" then yes ;)
<Seveas> but that would be a nice edgy+1 feature
<mjg59> Well, and have it as a single file on the filesystem?
<mjg59> Erm
<mjg59> I think it's actually an edgy *necessity* :)
<Seveas> hmm
<sladen> multiple images.  Just grab the biggest one that fits
<Seveas> shouldn't be too hard to implement (allow several struct_themes to be present in eg a linked list), but I need very strong coffee to finish that before FF
<Keybuk> especially if we could have 16:9 14:9 4:3 etc. in the same theme
<mjg59> Seveas: I've just uploaded this, so if on some machines it doesn't work properly, that's clearly a bug
<Seveas> mjg59, how about the ppc bits?
<mjg59> So we have time to fix it :)
<mjg59> Seveas: What about them?
<Seveas> well, they're not there yet (modesetting in bogl and having bogl put 256 colors on screen) unless either magic happened or I misunderstood you earlier
<mjg59> Oh, right
<mjg59> Well, that's just a matter of
<mjg59> a) Adding a bogl_setmode (just needs to ioctl the framebuffer)
<mjg59> b) Fixing bogl not to care about there being more than 16 colours
* Seveas would like not having to do that, given that I do not own a ppc to test it and I so far managed to avoid touching ioctls and touching bogl sources intimately
<mjg59> Yeah, I can probably manage that
<Seveas> although fixing bogl for more colors may have happened through magic
<Seveas> because I simply ripped out runlenght crack and made it not do &/| tricks on colors
<Seveas> (see the diff for the first commit on my branch)
<Seveas> I'll work on multiple-themes-per-file then adding a struct usplash_theme* next right after the version and code to figure out ratio (if x/y given on command line) and biggest fitting image. If no x-y given it will use first image available or lowest res (which would you prefer?)
<Seveas> s/then/then,/ for readability of that line
<mjg59> So it's not clear to me /why/, but
<mjg59> Running usplash now adds 40 seconds to my boot time
<sladen> t'fsck what
<sladen> that's almost up there with the 58 seconds that redsplash was adding to the Fedora boot process
<mjg59> Probably because it's using 100% of the CPU
* mjg59 investigates
<Seveas> mjg59, the setitimer/signal crack for animation?
<sladen> while(getchar(0))?
<mjg59> It's selecting insanely fast
<Seveas> hmm
<mjg59> select(4, [3] , NULL, NULL, {0, 0})      = 0 (Timeout)
<mjg59> Yeah, unsurprising
<Seveas> ah
<Seveas> lol
<Seveas> my bad, that should be an insanely high value
<Seveas> I set it to 0 to investigate an unrelated (and already fixed) bug
<sladen> ETIMEOUTTOOSMALL
<Seveas> ESTUPIDSEVEAS
<mjg59> Seveas: Hm. No, it seems to be 40000
<Seveas> 40000 microseconds
<mjg59> That's 1/25 of a second, isn't it?
<Seveas> yes
<Seveas> at first I tried to get the animation integrated with the select loop
<Seveas> horror
<mjg59> But it's firing much more often than that
* mjg59 tries to figure out why
<mjg59> Or is it just that the timeout is never reset?
<Seveas> it's set once
<Seveas> so inded
<mjg59> Ok
<Seveas> fallout of that horror attempt to not use signals
<mjg59> So what does it need to be?
<Seveas> 15
<Seveas> or actually: timeout
<mjg59> Right
<Seveas> because the TIMEOUT command changes it
<mjg59> And no framedelay?
<Seveas> there's another thing still missing
<Seveas> I'll create a quick patch and pastebin it
<Seveas> hang on
<mjg59> Seveas: Nah, sorted
<Seveas> could you poke me when you push to LP so I can merge again
<mjg59> Just done
<Seveas> ok, then I just need to wait for $launchpad_delay 
<mjg59> Seveas: Oh, you're using http to get it?
<Seveas> yes, I don't think I can reach it via sftp as I am not a member of core-dev (or dev for that matter)
<mjg59> Yeah
* mjg59 tries that again
<Keybuk> Seveas: yeah, it's a common "WTF?!" why you can't sftp-get things read-only if you have a LP account
<mjg59> Ok, that seems /much/ better
<Seveas> mjg59, did you see usplash-test.sh ?
<Seveas> I use that a lot to test shininess
<mjg59> Nope
<mjg59> I'll play now
<mjg59> So, the good news is, usplash appears to add no time to the boot
<Seveas> nice
<Seveas> btw: multi-theme themes is almost working (code is there and simple enough that it should just work, will add a few extra resolutions to the example theme
* gnomefreak loves the new usplash :)
<Seveas> hmm, I'm getting syntax errors in code of which I'm fairly sure that I didn't change since the last push
<Seveas> so either bzr is being weird or you didn't tell me about a few stupid bugs you found
<mjg59> Oh, yeah
<mjg59> I wasn't sure if they were merge bugs or not
<Seveas> missing (..) and extraneous }
<mjg59> Yup
<Seveas> so not bzr bugs
<Seveas> I thiught i did dpkg-buildpackage before pushing though
<mjg59> Ok
<mjg59> Seveas: The other thing that would be nice...
<mjg59> Seveas: Have some "squashed" artwork that we can use on widescreen machines
<mjg59> So it'll be stretched out to roughly the correct aspect
<Seveas> currently I'm doing the using the crude method of selecting the theme that covers the maximum area -- it's up to the artists to create themes for various resolutions 
<Seveas> and no stretching happens at all
<mjg59> Well, the stretching is implicit
<mjg59> 1024x768 on a 16:9 screen will be stretched
<Seveas> no
<mjg59> No?
<Seveas> if -x and -y are present on the command line, those x and y are used as resolution
<Seveas> the theme is centered in that resolution
<Seveas> assuming -x and -y are correct, no stretching should occur
<mjg59> No, I mean if you try to display a 4:3 screenmode on a 16:9 display, it'll be stretched out by the hardware
<mjg59> So your image needs to be squashed to take that into account
<jdub> worst is 640x400 vs. 640x480
<Seveas> ah right, only those screenmodes are supported
<mjg59> Seveas: Right, we have no widescreen video modes
<Seveas> hmm
<Seveas> would it be hard or not a good idea to add them?
<mjg59> We can't add them
<mjg59> VESA doesn't generally support it
<Seveas> ah
<Seveas> bummer
<Seveas> but -x and -y will still be 16:9 right?
* Seveas looks at postinst
<mjg59> Right
<Seveas> ok, some thinking needed
<Seveas> I really don't want to create 3 linked lists (a 4:3 one, a 16:9 and a 14:9(is taht really used?) one), so i'd suggest adding something in the theme struct to indicate whether it's squashed or not
<mjg59> Right
<Seveas> and the selection function should take that into account
<mjg59> Yeah
<Seveas> fair enough
<Seveas> let's just support 4:3 and 16:9 now and select the ration that's closest to -x:-y
<mjg59> Sure
* mjg59 tests the framebuffer code
<Chipzz> btw
<Chipzz> what happened to the graphical grub?
<mjg59> Theme incompatible with usplash_bogl
<mjg59> Hm
<Chipzz> I still have it on a few boxes here, but that's because I didn't run grub-install yet
<Seveas> mjg59, heh
<Chipzz> iirc it also had issues with widescreen?
<Seveas> usplash_bogl hardcodes "NONONO NO HIRES THEMES YET!" as safety measure
<Seveas> line 32, usplash_bogl.c
<mjg59> Ok, so that's a good start
<mjg59> Colours are utterly wrong, but still
<Seveas> are you ripping out my changelog entries after merging or am I misunderstanding what bzr is trying to do when I merge from your branch?
<mjg59> I'm leaving them there
<Seveas> hmm
<mjg59> Then adding a new version above
<Seveas> odd, in the changelog.OTHER there is no 0.4-16dennis 
<Seveas> maybe I merged before it was realy there
<mjg59> usplash (0.4-16dennis) edgy; urgency=low
<mjg59> Is what's in the tree
<Seveas> then something is confusing bzr 
<Keybuk> dennit? :p
<Seveas> that's a dch -i without paying attention ;)
<mjg59> Ha
<Seveas> hmm, I thin I merged too soon
<Seveas> reverting
<Seveas> yes, this merge is better
<mjg59> Wow.
<mjg59> That's an, uh, interesting effect.
<sladen> mm?
* mjg59 gets a *very* blue theme
<Keybuk> hmm
<Keybuk> ya know, this "make shutdown work with upstart and sysvinit" is actually damned hard
<mjg59> Thinking about it, that's hardly unexpected
<mjg59> I'm writing a one byte value without actually turning it into a useful colour
<mjg59> Wait, no
* mjg59 tries to work out what colourspace this is actually in
<mjg59> Ah, right, i see
* mjg59 will deal with this at some later stage
<Seveas> hmm, 14:9 is actually *exactly* between 16:9 and. Which one should be used for that resolution?
<Seveas> s/resolution/ratio/
<sladen> Keybuk: don't you just set each task goal to be 'stopped'.
<sladen> Keybuk: and the task that runs 'rc' calls the whole contents of rc6.d ?
<Keybuk> errr?
<Keybuk> sladen: explain?
<sladen> Keybuk: the sysv-compat is just a job that runs 'rc', yes?
<Keybuk> no
<sladen> Keybuk: (entirely possible the answer is not "yes", in which case you'll need to explain
<Keybuk> it's ~10 jobs that arrange for rc to be run
<sladen> Keybuk: I suspect you have a better handle on it too...
<Keybuk> oh, you're talking about shutdown?
<Keybuk> shutdown in upstart is easy, it sends out a "shutdown" event, waits for the system to go idle, then sends out whatever additional event you asked for
<Keybuk> usually you do "shutdown" ... "reboot"
<Keybuk> or "shutdown" ... "power-off"
<Keybuk> etc.
<Keybuk> so yes, it runs rc6, etc.
<Keybuk> but that's not the problem I have here
<sladen> Keybuk: so, 'this "make shutdown work with upstart and sysvinit" is actually damned hard' ?
<Keybuk> the problem is what happens when you were running dapper, upgraded to edgy
<Keybuk> you're running sysvinit
<Keybuk> but have upstart installed
<Keybuk> how do you tell sysvinit to shutdown? :p
<sladen> Keybuk: sync, umount, reboot -f
<Keybuk> lol
<infinity> There are people who may be unimpressed with that solution.
<infinity> And I'm using the word "solution" very liberally here. :)
<Seveas> Keybuk, keep some parts of sysvinit around in /tmp and use them? + Be windows lik and really force people to reboot
<sladen> Keybuk: my suspicion is that to provide compatibility with /dev/initctl you're going to have to copy a certian chunk of sysvinit into upstart
<infinity> And, for the record, even "reboot -f" didn't do a damned thing after I upgraded to upstart.
<Keybuk> infinity: it should do, that just does sync() reboot() :p
<infinity> Keybuk: It just sat there like a dumb shit.  I had to cut the power.
<Keybuk> how odd
<sladen> wonder whether '-f' causing sync is actually out of spec
<infinity> I thought so too.
<sladen> sync() can potentially hang.  In which case, the purpose of trying to purpose a 'reboot -f' has been defeated (yes, I've had machines in that state)
<sladen> s/purpose a/perform a/
<Seveas> what's a common 16:9 resolution?
* Seveas --> bed
<infinity> 1280x720
<Seveas> mjg59, I'll merge from you tomorrow and then push multi-res-themes support
<Seveas> infinity, thanks
<Keybuk> sladen: reboot -n -f
<Keybuk> sladen: aye, the general solution appears to be either
<Keybuk> a) stash the old /sbin/init somewhere on install and use it to shut down the running one
<Keybuk> b) copy enough from the old /sbin/init to send the initctl shutdown message ourselves
<infinity> Keybuk: http://librarian.launchpad.net/4160730/buildlog_ubuntu-edgy-sparc.linux-restricted-modules-2.6.17_2.6.17.5-1_CHROOTWAIT.txt.gz
<Keybuk> infinity: *sigh*  MVO!
<infinity> Keybuk: Have we really thought this through?
<Keybuk> it's not essential
<infinity> Keybuk: It is in the installed system.
<Keybuk> right, but it isn't in the archive
<infinity> Anyhow, I'll update all the chroots manually, but this needs ot be addressed (obviously) for dapper->edgy
<Keybuk> right
<Keybuk> Colin thought making upstart essential would "fix" it
<Keybuk> apparently not
<infinity> Just made it worse, in my case. :)
<infinity> Since nothing was forcing the upgrade in the chroots until that happened.
<Keybuk> yeah
<infinity> This misfeature is precisely the reason why we never make libraries Essential:yes
<infinity> I suspect no one had really thought that we'd be replacing init anytime soon.
<Keybuk> right
<Keybuk> it's why I didn't make upstart essential originally, as I remembered it being difficult to get them off again
<infinity> If we were willing to deal with not having an alternate init anymore, the easy way out would be to make sysvinit a transitional package.
<LaserJock> hmm, I seem to have a problem with postrm vs. prerm here
<infinity> What would that problem be?
<LaserJock> I want to do some stuff postrm, but it need to check a file that is being removed in the postrm
<Keybuk> infinity: the thought is increasingly occuring to me <g>
<Keybuk> I have one standing by, in fact
<Amaranth> Do it. :)
<LaserJock> but if I put it in prerm then it doesn't get run at --purge right?
<infinity> Only postrm remains when a package is removed but not purged, yes.
<infinity> Of course, the only other things left should be conffiles.
<infinity> So you can't rely on any non-conffile during the purge phase.
<infinity> http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails
<infinity> LaserJock: Policy is your friend.  It details how allof this works.
<LaserJock> infinity: ah, I was looking in 6.5 ;-)
<infinity> Well, all of section 6 is a good read. :)
<infinity> s/section/chapter/
<LaserJock> ok, well then I don't really need to worry about --purge then as I don't have any conf files
<infinity> Has anyone else been noticing weird keyboard-grabbing issues in edgy over the last week or two?
<infinity> Like, you'll focus a window, but it won't take keyboard input.  Switching VCs or even workspaces will fix it.
<Keybuk> yeah
<infinity> Oh good, I'm not alone.
<infinity> I thought I was going insane.
<Keybuk> usually x-chat vs gaim for me
<Keybuk> switch between the two and one won't take keyboard until you switch back and forth a bit
<infinity> gnome-terminal and GAIM being my two big keyboard-not-grabbers.
<Burgundavia> infinity: yep, I have noticed that as well
<infinity> Keybuk: A quick Ctrl-Alt-Right/Ctrl-Alt-Left always clears it up, BTW, if you don't want to much with Alt-Tabbing for a few minutes.
<infinity> s/much/muck/
<Keybuk> The "tags" portlet is my BEST FRIEND
* infinity wonders if there is a bug about this.. And on what package...
<infinity> Smells GTKish... Or even Xish.
<Keybuk> gtk :p
<Keybuk> or X, yes
<infinity> If KDE people aren't whining, I'll assume GTK.
<Keybuk> the KDE user is asleep
<Burgundavia> the have users? ;)
<Burgundavia> *hey
* Burgundavia gives up on spelling for the day
<infinity> Hobbsee should be awake.  Slacker.
<infinity> It's 11:30am, FFS.  Where's my token Australian Kubuntu user?
<Riddell> ahem
<infinity> Oh, hey.  I have a Scottish one.
<infinity> Riddell: Noticed any keyboard grabbing (or lack of grabbing) oddities recently?
<Riddell> infinity: nope
<infinity> Alright, I'll blame GTK then.  Thanks.
<Riddell> infinity, Keybuk: any thoughts on having KDE 4 packages in edgy, the files are installed to /usr/lib/kde4/{bin,lib,share,etc} as the only way to avoid them clashing with kde 3
<ajmitch> sweet, workaround for f-spot crasher works
<infinity> Riddell: In universe, co-installable, you mean?
<Riddell> infinity: yes
<infinity> Riddell: I'd probably be okay with that.  It's big enough that I'd recommend pinging mdz when he's done catching up on email, though.
<Riddell> maybe at the distro meeting tomorrow then, time for sleep now
<mdz> I'm able to poke my head above water from time to time at this point. what's up?
<infinity> mdz: 4 lines up.
<infinity> Or 6.  Or something.  Counting is hard.
<Riddell> mdz: KDE 4 in edgy, installed to /usr/lib/kde4/
<mdz> is the question about paths or about having the packages in edgy?
<mdz> the latter, no problem
<infinity> The latter.
<Riddell> mdz: mostly if having it in that path will be allowed in
<Riddell> since it's not really debian-policy compliant
<infinity> If it's in universe as a set of "experimental packages for testing", I say policy-be-damned, to a certain extent.
<Burgundavia> ajmitch: are there release notes for fspot 2.0?
<infinity> gcc-snapshot isn't all that policy-compliant either. :)
<ajmitch> Burgundavia: not really
<Riddell> infinity: that's just the answer I'm looking for :)
<Burgundavia> ajmitch: can you tell me in one sentence about what makes it 2.0?
<Keybuk> why not /opt/kde4?
<ajmitch> Burgundavia: 0.2.0, not 2.0
<Riddell> Keybuk: too suse-ish?
<infinity> Keybuk: Packaging systems messing in /opt is rather bad form.
<Burgundavia> ajmitch: right
<Keybuk> yeah, true
<Keybuk> it's a bit /usr/local
<Keybuk> unless you're Solaris of course
<ajmitch> Burgundavia: lots of fixes, 0.1.x was branched & left for SLED
<Keybuk> in which case /opt is the package manager's domain
<infinity> Yes, well.  Thankfully, we're not Solaris.
<ajmitch> when all the activity was on 0.2.0, which lewing recommended we have in edgy
<infinity> If we were, I'd see a long walk and a short cliff in my future.
<ajmitch> Burgundavia: though we're currently bitten by bug 59166 :)
<Ubugtu> Malone bug 59166 in f-spot "Mono segfaults in dbus_pending_call_get_completed()" [Unknown,Unknown]  http://launchpad.net/bugs/59166
<Burgundavia> ajmitch: right, this is for UWN
<mdz> Keybuk: FHS forbids us from installing it in /opt
<ajmitch> Burgundavia: I figured it would be
<mdz> I don't know that there's an FHS-blessed place to include sub-hierarchies a la /opt though
<mdz> I think their answer is "don't do that"
<Keybuk> infinity: hmm, making upstart not Essential means that APT just refuses to update ubuntu-minimal
<mdz> Riddell: what breaks if it just conflicts with kde3?  they shouldn't need to be parallel installable 
<infinity> Keybuk: Special.
<Burgundavia> Keybuk: system-services and startup-tasks are provided by upstart?
<Keybuk> Burgundavia: "provided by" ?
<Riddell> mdz: kde4 isn't stable enough to use as an actualy desktop yet, most developers will want the kde 4 libs for whatever app they're working on but still be running kde 3
<infinity> Keybuk: I suspect this conversation needs an mvo and a bit of a thinktank.
<Burgundavia> Keybuk: you just added those packages to ubuntu-desktop and I wondered where they came from
<Keybuk> Burgundavia: no, I added them to ubuntu-minimal
<Burgundavia> Keybuk: yes, I was about to point out my error
<Keybuk> :)
<Keybuk> they will be the upstart equivalent of "initscripts"
<Burgundavia> and they don't exist yet?
<Keybuk> they exist
<Burgundavia> oh, right, that was my bad reading
<Burgundavia> is it must me, or has performance when apt is loading the system quite bad?
<infinity> Burgundavia: That sentence is lacking a few crucial words, I think.
<jelmer> Keybuk: thanks for the quick reply. upstart seems like an interesting project; keep up the good work :-)
<Burgundavia> infinity: hmm, ok: When apt is busy grinding away updating packages, responsiveness decreases significantly
<infinity> Burgundavia: s/apt/dpkg/, surely.  And yes, it can be a bit evil. Not sure it's really gotten any worse, though.
<Keybuk> infinity: at least if everything's not Essential, the second time you run dist-upgrade, everything works
<Burgundavia> infinity: the break between apt and dpkg always confuses me, but yes
<Keybuk> the first time it holds ubuntu-minimal, but upgrades sysvinit (to the non-Essential one)
<Keybuk> then the second time it can upgrade ubuntu-minimal and install upstart
<infinity> Burgundavia: apt is just an acquisition tool.  It doesn't install anything.
<Burgundavia> infinity: ah, ok
<infinity> Keybuk: Well, I guess that could be worked around in update-manager by just doing two passes, so perhaps that's the best solution.
<infinity> Keybuk: And people doing it by hand have been long trained to keep trying to upgrade untilit "sticks" anyway. :)
<Keybuk> indeed
<Keybuk> #define INIT_MAGIC 0x03091969
* Keybuk hazards a guess that it was the author init's birthday a few days ago
* infinity still remembers the days of dselect and dpkg-ftp, and having to do 15 passes to make any upgrade go.
<Keybuk> or maybe he's American, and can't get dates right, and it was in March
<jdub> Keybuk: heh
<jdub> infinity: put in a proposal for lca yet?
<theCore> does GNOME removed the Shift-Ctrl-[Unicode]  shortcut?
<Keybuk> with any luck, this might work
<Keybuk> /lib/libc.so.6: version `GLIBC_2.4' not found
<Keybuk> grr
<Keybuk> \o/
<infinity> jdub: Give me something interesting to talk about, and I'll write something. :)
<infinity> jdub: I'm terrible at coming up with topics.
<infinity> Okay, migrating diversions from one package to another is a *pain*
<infinity> Doubly-so, when the diverted file is dpkg-deb.  *cough*
<mjg59> infinity: Maintaining a buildd network
<mjg59> How to avoid implementing specs
<infinity> mjg59: Yeah, I thought so too, then they cleverly assigned me specs that vaguely relate to buildds.
<infinity> mjg59: When mangling maintainer addresses, do you have any you'd like whitelisted?  (ie: LaMont requested that I not mangle lamont@debian.org to another contact, as he's happy to support his Ubuntu packages via that address)
<infinity> mjg59: Reference here: https://wiki.ubuntu.com/DebianMaintainerField
<infinity> mjg59: About halfway down the page, the mangling strategy (minus whitelists) is described.
<mjg59> Erm
<mjg59> I think all my debian maintainer entries are likely to go away soon
<infinity> Right.  Just looking for people to whitelist off the bat.
<infinity> I already have lamont, so one example in the config file is good enough.
<robertj> has anyone looked at this patch for adding an Empty Trash view to trash://? http://pages.cpsc.ucalgary.ca/~weckerl/nautilus_patch.html
<robertj> sorry, Emptry Trash widget
<cge> Is there some reason besides tradition that ed doesn't display any error messages by default? Would changing the behaviour break something?
<Burgundavia> cge: does anybody still use ed?
<StevenK> My boss does
<mneptok> dum dee dee
<cge> Burgundavia: Ed is THE editor!
* mneptok stares
<mneptok> that's bizarre. i popped in here to start a main inclusion discussion for another editor.
<cge> More seriously, I've used it a few times with scripts, like sed.
<Burgundavia> mneptok: which one?
<mneptok> ne
<Burgundavia> and what do you want done with it?
<mneptok> http://ne.dsi.unimi.it/
<cge> mneptok: ne is already in universe
<mneptok> Burgundavia: i thought "main inclusion" would be a giveaway there
<mneptok> :)
<Burgundavia> do you mean main inclusion or installation by deafult?
<mneptok> inclusion
<Burgundavia> right
<mneptok> installation would be nice, but space is tight.
<Burgundavia> what does it have over nano?
<Burgundavia> which is already both
<mneptok> ease of use for shell newbies
<cge> mneptok: Installation will never happen. There are even people who want to remove vim!
<Burgundavia> used nano? (not saying it is a bad idea, just want to see why it is good"
<Burgundavia> cge: vim is already gone, vim-tiny is in
<cge> Burgundavia: Yes, but there were those in that discussion who didn't want vim in at all.
<mneptok> Burgundavia: i'm a nano user. i want this in main so we can officially support it, and have it something we can recommend to more novice users.
<Burgundavia> cge: like myself
<Burgundavia> mneptok: to justify it, what does it have over nano?
<Burgundavia> better features? easier to use? smaller install?
<mneptok> 00:56 < mneptok> ease of use for shell newbies
<Burgundavia> in waht way?
<mneptok> i.e. an menu-driven command system that GUI users find more approachable.
<mneptok> s/an/a/
<cge> Burgundavia: ne is about twice as big when installed as nano
<Burgundavia> hmm
<cge> Burgundavia: around 500k
<mneptok> 260 here
<mneptok> -rwxr-xr-x 1 root root 267624 2005-10-25 09:43 /usr/bin/ne
<mneptok> ok, 270
<cge> ed is only 40 kilobytes, and I think that is a rather large implementation.
<mneptok> cge: i don't want to be put in the position of telling as new Linux user coming from a more GUI environment that they have to edit hidden or root-owned files with ed. they'll melt down.
<Burgundavia> right, that is why the default editor is nano
<mneptok> i have already dealt with people that find nano confusing, and want to try editing /etc stuff with gedit, which leaves foo.txt~ temp files all over /etc
<Burgundavia> according to packages.ubuntu.com, nano is 100k larger than ne
<mneptok> i'd like to be able to tell them we support a more GUI-like shell editor.
<Burgundavia> so here is what you need to do: create a spec talking about the reasons why we shoudl replace nano with ne
<mneptok> and if it's not in Main, we tend not to support it.
<Burgundavia> then get some people like myself to look voer it
<mneptok> (at least for the time being)
<mneptok> yeah, i'm going to be doing an inclusion report. but first stop is here.
<mneptok> https://wiki.ubuntu.com/UbuntuMainInclusionQueue?highlight=%28inclusion%29%7C%28main%29
<Burgundavia> I would do the spec first
<mneptok> figured i'd idle here until the lazy euro co-workers unidle :)
<Burgundavia> main inclusion is unlikely without a good rationale
<cge> mneptok: Have you considered that gedit's behaviour could be changed to not leave backup files around like that? Editing /etc/ things with gedit should be supported.
<infinity> mjg59: Still around?
<Seveas> isn't he in UTC+1?
<infinity> Yeah, but he was here not that long ago. :)
<infinity> Oh, perhaps longer thanI remember.
* infinity waits to tomorrow to NEW usplash-dev
<Burgundavia> infinity: mjg59 last spoke about 6 hours ago, just as I left work
<Seveas> no, he spoke arond 2:something here too
<Seveas> that's around 5h
<Seveas> and exactly the amount of sleep I've had 
<Burgundavia> hmm, have to be at work tomorrow at 6am
<Burgundavia> hmm, it appears we have lost Stephen Vaughan to SLED
<jdub> hopefully we never really had him :)
<mneptok> oy jdub
<Burgundavia> jdub: he does appear to write a lot
<jdub> Burgundavia: i suppose, being a journalist, he is somewhat compelled to.
<Burgundavia> jdub: there is a certain respectability that is gained from pure volume
* mneptok whispers "Dvorak"
<jdub> Burgundavia: you appear to be talking from the incorrect orifice.
<mneptok> although *why* anybody listens to that loon any more escapes me
<desrt> jdub; with popularity does come a certain degree of responsibility...
<infinity> Seveas: Actually, since you've been recently involved with usplash hacking, you may be able to answer this one for me.
<desrt> oh.   he said respectability
<desrt> no.  i don't agree with that at all :p
<infinity> Seveas: Is usplash-dev going to end up being a build-dep of anything in main in the near future, or should I send it to universe?
<jdub> sjvn hasn't really earned much of my respect
<Seveas> infinity, main -- I split it off of the main binary so artwork packages don't need to depend on usplash
<desrt> Burgundavia; did you do any more work on the mentorship thing?
<jdub> at one point, i pointed out that his description of portland was incorrect
<Seveas> it'll have to be a builddep of artwork packages
<Burgundavia> desrt: no, been insanely busy with work and a few personal projects
<Burgundavia> desrt: can you fire me an email to remind me?
<desrt> Burgundavia; it's cool.  i'll keep politely reminding you every week or so :)
<desrt> ok.  i can do that too.
<jdub> and he decided to disagree, assert even more outlandish ideas, and ignore the fact that i was a participant in the initial portland specification meeting
<infinity> Seveas: Okay, great.
<infinity> Seveas: Thanks.
<mneptok> jdub: cut him some slack. omniscience is a heavy burden.
<desrt> Burgundavia; ok sent.  i'm gonna go to bed now.  ciao.
<Seveas> mneptok, please don't do that when I am just drinking something
<Seveas> my keyboard doesn't like that
<jdub> willful ignorance is a heavy burden. :-)
<mneptok> Seveas: coffee | nose > keyboard
<infinity> I'd suspect that wouldn't do much harm without a 2>&1
<infinity> Surely, snorting coffee is a standard error.
<lifeless> IO overflow I think
<infinity> That nick gives me a headache...
<mneptok> infinity: try eating an aptly-named user
<pitti> Good morning
<tseng> hello pitti 
<jdub> ber, laptop still 'in production', before 'delivery prep'
<jdub> hello tseng and pitti
<Lathiat> jdub: which one did you get?
* tseng puts wv back in pitti's queue
<Lathiat> dell or the ibm?
<jdub> Dell D420
<jdub> + mediabase with DVI!
<Lathiat> ah nice
<Lathiat> for the 24"? :)
<jdub> saves getting an apple :)
<jdub> yeah
<pitti> tseng: hi
<pitti> tseng: yes, wv is fine with me, I was just concerned about code duplication
<tseng> pitti: ok, i put it back on the page, no need to look at it right now
<tseng> pitti: im on a business trip, anyway
<tseng> on that note, 3am, done working for the day
<tseng> good night
<jdub> night tseng!
<pitti> tseng: sleep well!
<pitti> jdub: pants off!
<mneptok> jdub: dunno about Oz, but in the US IBM shareholders get some nice shareholder discounts on Lenovo stuff. worth the price of one share to pay US$1299 for a laptop that is US$1899 retail. :)
<mneptok> (kinda late with the tip, but oh well)
<jdub> mneptok: a discount for being punched in the face?
<mneptok> uhhhh .... i'll just pretend i understood that and say "i guess so"
<jdub> mneptok: i am not a fan of the thinkpad keyboards (esc/f1, fn/ctrl)
<mneptok> ah, mine has a seperate <esc> and <fn> keys. the meta for the <fn> keys are all things like battery display, brightness, power savings, etc.
<jdub> i always hit f1 instead of esc on pia's
<jdub> and fn is toooootally in the wrong place
<mneptok> you could always remap the keys with software or epoxy. :)
<jdub> fn/ctrl isn't doable
<HiddenWolf> mneptok: and put stickers on the keys with the correct keycodes, yeah right. :P
<jdub> due to the nature of the fn key
<mneptok> hrmf
<mneptok> here's an ugly choice. sl-modem is in Multiverse. we can either move it to restricted and actually support it (*shudder*) or have no official support for any Winmodems.
<mneptok> ugh
<HiddenWolf> There is actually some software that can make those ugly hardware hacks work?
<mneptok> sl uses ALSA to communicate with the Winmodem (which basically a sound card)
<mneptok> apparently you just have to have a working ALSA and a Winmodem that actually exposes itself as a modem.
<mneptok> but the whole thing smells of dead hookers and vomit.
<lifeless> mneptok: we have a support department to wear such pain, no ? :)
<mneptok> i love you, too.
<lifeless> of course you do
<mneptok> *muah*
<jdub> lifeless: to wear the pain of dead hookers and vomit?
<dholbach> good morning
<cbx33> hi dholbach 
* mneptok goes to find some f00d
<dholbach> hi cbx33
<infinity> mneptok: slmodem has probably wanted some main love for ages now, but no one in core-dev uses a modem, so it keeps getting ignored.
<jsgotangco> mvo!
<mvo> jsgotangco: good morning!
<mneptok> infinity: are you using some Jedi mind trick to try to make *me* be the poor stooge that's submits Main inclusion for sl-modem?
<mneptok> huh huh huh huh. mettu steeny barana muddah Jedi mind trick d'vulus andaska.
<Kamion> ok, that's console-setup more or less working in d-i, anyway
<tepsipakki> why are cdroms mounted as noexec by default?
<tepsipakki> annoying
<mempf-edgy> any news on when the next kernel update will be?
<Seveas> mjg59, usplash -17 is messing up my consoles: nothing on the screen, getty stuck in read() according to strace
<ogra> Kamion, 
<ogra> Reading package lists...
<ogra> W: Couldn't stat source package list file: edgy/main Packages (/srv/cdimage.no-name-yet.com/scratch/edubuntu/daily/apt/edgy-powerpc/apt-state/list
<ogra> s/_srv_cdimage.no-name-yet.com_ftp_dists_edgy_main_binary-powerpc_Packages) - stat (2 No such file or directory)
<ogra> W: Couldn't stat source package list file: edgy/restricted Packages (/srv/cdimage.no-name-yet.com/scratch/edubuntu/daily/apt/edgy-powerpc/apt-stat
<ogra> e/lists/_srv_cdimage.no-name-yet.com_ftp_dists_edgy_restricted_binary-powerpc_Packages) - stat (2 No such file or directory)
<ogra> W: You may want to run apt-get update to correct these problems
<ogra> E: Some index files failed to download, they have been ignored, or old ones used instead.
<ogra> make: *** [apt-update]  Error 100
<ogra> seems lithium isnt well
<Kamion> Failed to fetch file:/srv/cdimage.no-name-yet.com/ftp/dists/edgy/main/binary-pow
<Kamion> erpc/Packages.gz  MD5Sum mismatch
<Kamion> Failed to fetch file:/srv/cdimage.no-name-yet.com/ftp/dists/edgy/restricted/bina
<Kamion> ry-powerpc/Packages.gz  MD5Sum mismatch
<Kamion> try again later
<Kamion> this happens sometimes when you get unlucky with the archive
<ogra> ah, ok
<Kamion> it's a soyuz bug of course - that shouldn't be possible
<ogra> i can wait till it sorted itself :)
<Kamion> if it hasn't sorted itself by the next publisher run, let me know
<ogra> yup
<Kamion> infinity: how're live-cd-stacked-filesystems/larger-livefs going?
<sivang> morning
<doko> ajmitch: there already are zope sync requests filed for zope
<mvo> Kamion: did you got my germinate mail?
<Kamion> mvo: yeah, haven't read the diff yet though
<Kamion> I'm battering through sane-installer-keyboard
<mvo> Kamion: ok, no problem
<Kamion> infinity: could you give-back console-data on all architectures please? I can't see why it failed but my guess is that it's transient ...
<Kamion> mvo: I'll try to get to it this morning thoug
<Kamion> h
<mvo> cool!
<Kamion> infinity: oh, maybe not
<Kamion> i386 was transient I think, but powerpc looks more substantial
<infinity> Kamion: So, no give-backs?
<Kamion> infinity: looks like I need to reupload anyway
<Kamion> so no, spoke too soon
<infinity> Kamion: Also, live-cd-whatever should be complete by the meeting, except for the whole "blocking on kernels on the buildd" thing.
<Kamion> infinity: can that be expedited somehow?
<infinity> Kamion: Indulging in a bit of evening wine right now, then back to work between now and the meeting to polish up.
<Kamion> right, but there's also the cdimage/ubiquity end, and I'd really like to be able to test that
<infinity> Well, royal is running a kernel with unionfs support, so when I'm done playing here, I could roll it out on powerpc.  I can't do amd64/i386 without elmo's team.
<Kamion> I've made a note to ping sysadmin about that
<Kamion> is it just unionfs, or squashfs too?
<infinity> Should be just unionfs, though squashfs would be nice to be able to do local testing without dragging the images elsewhere.
<Kamion> infinity: did you already file an RT request?
<Kamion> since they're gonna ask me. :)
<infinity> I think I did a month or so ago, and now I'm questioning that.  I know I spoke at length with elmo about it.
<infinity> I can always file another. :)
<Kamion> I've asked
* mneptok checks where thttpd lives
<zyga> mvo: hi, I hope you didn't waste your time on running that script
<mvo> zyga: I did, why? something wrong?
<mvo> zyga: it is still runing
<zyga> yeah, one fix broke sometime later
<zyga> some package in universe
<zyga> anyway I'm running the updated script since 9 CET
<mvo> zyga: ok, let me know when I can merge/re-run. not a big issue :)
<zyga> otherwise everything is great, data format is the same and it just works :)
<zyga> ok
<mvo> cool :)
<infinity> Why do I push so hard to get new kernels through the machinery and into the archives, and then spend 5 minutes fretting about whether or not I should reboot after installing them?
<infinity> Question for the ages, I'm sure.
<Fade> Mithrandir: did that xlib update get pushed out yesterday?
<jdub> infinity: sadism.
<mneptok> infinity: welcome to life inside the sausage factory. "yeah! new flavor! let's ship it!" :: later, in the men's room :: "Bob, we *did* clear up that botchelism thing, right?"
<Spads> botulism is a harsh mistress
<jdub> 'botulism'
<mneptok> roit
<Spads> jdub: but kernels have botchelism
<mneptok> very late in my day. i'm running on 2 pistons.
<jdub> Spads: infinity's do!
* Spads runs on a wenkell rotary
<Spads> NO PISTONS HERE!!!
<infinity> My kernels will not stand for this.
<thom> Spads: haven't you been recalled by mazda? :P
<jdub> Spads: enjoying the new gig?
<Spads> jdub: aye
<jdub> Spads: saw a great television interview with one of your colleagues -
<jdub> http://youtube.com/watch?v=AxW6-_Qx1JA
<jdub> absolutely priceless
* Spads weeps at the un-keepvidded youtube URL
<StevenK> jdub: Bwahaha
* jdub keepvids
<infinity> jdub: I'm disturbed that you watch Rove.
<Spads> http://www.youtube.com/get_video?video_id=AxW6-_Qx1JA&l=597&t=OEgsToPDskJTVZZ4VhY9GgyiVPAN2Tcf&nc=6724044
<Spads> of course, I'm in the office
<Spads> so I will not fall for this obvious troll
<mneptok> Spads: "Wankel" ;)
<jdub> Spads: he should see it
<mneptok> jdub: so what *is* your new gig? been owrking too hard to keep on top of such news.
<Spads> mneptok: Speak for yourself.
<jdub> my new gig is hitting reload on the dell shipping page
<jdub> so i can find out when my new laptop arrives
<Spads> ha ha dell
<mneptok> training for that must have taken a while.
<Spads> mneptok: he kept failing his back but
<Spads> button exams
<Seveas> mjg59, new usplash revisions uploaded: multi-variant themes, a fix against non-working TIMEOUT and some doc/copyright fixes
<Mithrandir> Fade: yes, it should.
<jdub> the website kept failing those exams!
<Spads> okay, when will ubuntu get the "disable middle click on touchpad that rests under the palm of your hand" gui control?
<mneptok> Spads: when you get a new laptop
<thom> touchpads are evil, kthx
<Spads> yeah they are
<Spads> I wouldn't mind if the clicktaps were disabled
* dholbach likes the middle click
<Gman> jdub, you bought a dell laptop? nutball.
<jdub> Spads: seems the only way to configure that stuff is via insecure shmem crack
<jdub> Gman: a good one. :)
<jdub> i had tough requirements
<mneptok> dholbach: only because someone labelled your middle-click "SEND HUGZ0RZ!!!!"
<infinity> jdub: So, it's an IBM with a Dell logo glued on it?
<thom> jdub: oxymoron. or just moron. which ever :-)
<Gman> jdub, one that will allow you to take on planes?
<dholbach> jdub: what? you replaced your quebecistani laptop?
<StevenK> infinity: Hah
<Spads> I have a button for middle click
<Gman> hey thom
<jdub> ibm lost, and i totally didn't want to get an apple
<dholbach> mneptok: :-)
<thom> Gman: dude :-)
<Spads> and I can chord either set of L/R buttons
* dholbach hugs mneptok
<Spads> I don't need the tapmiddle
<ogra> ENOSEB :(
<jdub> dholbach: hopefully, it will complete its duty when i visit the UK office later in the month.
<Fade> I saw thre libx11 updates, but no xlib.
<ogra> dholbach, do you have an idea how far seb is with the 2.16 gnome-session package  ?
<Gman> jdub, nod, ibm is ovely expensive, apple is evil :)
<Fade> s/thre/three
<dholbach> ogra: no, I'm sorry - why?
<jdub> dholbach: despite being a complete bastard of a laptop, it has been a trooper under demanding conditions.
<Fade> xemacs is still dying horribly.
* Spads buys used thinkpads, though that may have to change in future
<Fade> should I relink it?
<Seveas> <Fade> xemacs is still horrible.
<sladen> Spads: as jdub notes, it needs a (Safe) X-extension writing for runtime Synaptics configuration---or leaving the user to enable SHMConfig on themselves
<dholbach> jdub: demanding conditions like what? spilling water into the keyboard?
<Spads> ah
<ogra> dholbach, he told me to just upload a patch that disables fading on logout for ltsp clients, but i suspect he's working on the new package and dont want to come in his way 
<jdub> dholbach: being my laptop during and after canonical is a demanding condition. :)
<Seveas> dholbach, having beagle crapping ovr your FS during a presentation ;)
<dholbach> ogra: just send him the patch by mail and he'll integrate it with his upload
<dholbach> Seveas: right :)
<dholbach> jdub: I see :-)
<jdub> Seveas: that was pre-craptop :)
<Seveas> dholbach, or having jdub stp on it while searching for pants
<jdub> wasn't it?
<jdub> hrm
<Seveas> it was october last year
<Seveas> during eurooscon
<jdub> post ubz?
<Seveas> (btw: I'll be at eurooscon this year)
<jdub> yeah
<Seveas> pre-ubz
<jdub> oh
<jdub> yeah
<jdub> i'll be at eurooscon too
<jdub> should be fun
<thom> yeah, i'm thinking about euroscon
<jdub> dude! come!
<Seveas> sabdfl is coming too, accorfing to the agenda
<jdub> he's doing closing
<jdub> dholbach: interesting, gentoo ported all the rh admin tools :)
* mvo ponders about lunch
<pygi> sivang, poke? :)
<sivang> pygi: hi
<pygi> sivang, asero 0.4.9 with libburn/libisofs backend is out, and it rocks :)
<pygi> Brasero*
<Seveas> Kamion, ping
<dholbach> jdub: that's interesting
<mneptok> sivang: Jane pinged me last week about DB/2 progress. gave her an update, and she should have renewed Canonical's agreement with Big Blue.
<Kamion> Seveas: hi
<Seveas> Kamion, usplash uses /etc/usplash.conf which is generated by the usplash postinst -- is it regenerated after a ubiquity install to match the installed system?
<Kamion> Seveas: no - what about it is system-specific?
<Seveas> X-detected resolution is grabbed from debconf and stored in /etc/usplash.conf
<Kamion> file a ubiquity bug please, I'll make it do that
<Seveas> ok, will do -- I'll attach the postinst
<infinity> Seveas: Did you make the postinst less ugly, or is it still my hideous "It's 5am, and I don't care, I just want it to work" shell?
<Seveas> infinity, I didn't prettify it, don't know about mjg59
<sivang> mneptok: cool, great.
<infinity> Seveas: Just checked, it's still scary. :)
<Seveas> heh ;)
<zyga> pitti:ping
<zyga> pitti: some .desktop and .png files in langpacks have +x set, that doesn't make any sense
<infinity> Easily discoverable because I'ma backtick whore, and people keep slapping me, telling me that I'm living in 1975, and I should use $()
<ogra> infinity, we'll need to talk about https://features.launchpad.net/distros/ubuntu/+spec/ltsp-daily-image-tarballs soon
<StevenK> infinity: You're living in 1975, use $() *slap*
<infinity> StevenK: Thpt.
<StevenK> infinity: Just try and nest your backticks.
<Kamion> infinity: I suggested cut instead of sed
<pitti> zyga: oh, hmm; thanks for the hint
<mneptok> so, my biggest gripe about Jono thus far is ..... HEY HEY! hi!
<infinity> Kamion: I think there was a specific reason I didn't use cut, and it wasn't cause I wanted to waste CPU/RAM.
<jono> mneptok, hehe
* jono thwacks mneptok :P
<infinity> Kamion: Damned if I can remember why now.
<sladen> mneptok: we should have a voice-o-meter competition between jdub and jono to see who's the loudest :)
<mneptok> aha! physically assaulting me! now you really *are* a Canonical employee!
<infinity> ogra: Yes, we should.  You're certainly leaving it to the wire, though. :P
<Seveas> sladen, please distribute ear protectioin generously before doing that
<jono> sladen, I will kick his ass, and he knows it :P
<infinity> ogra: It may end up having to happen shortly after FF, since I'm flat out right now on getting my own stuff done.
<mneptok> sladen: in the end it doesn't matter. i have bigger boobs.
<jono> mneptok, haha
<ogra> infinity, i'm fine with that, the scripts are done and lie under http://people.ubuntu.com/~ogra/ltsp-tarballs/
<ogra> (in the bzr archive)
<ogra> so you can grab them any time yu ike 
<ogra> *you like
<pygi> pitti, poke, I wanna bug you ;)
<pitti> pygi: I'm a bit busy ATM, but feel free to /msg me, I'll read scrollback
<pygi> pitti, just poke me when you're free 
<dholbach> Kamion: can you have a look at  http://daniel.holba.ch/temp/debhelper-pngcrush.patch ? (my attempt to let dh_compress make use of pngcrush) - if I could do it cleverer, I'd be happy to do so
<zyga> mvo: better kill it, it loops on template.extract for some reason and eats all memory
<zyga> s/template.extract/template.substitute/
<mvo> zyga: hm, ok
<mvo> zyga: killed
<Kamion> dholbach: TBH I'd rather we did that by hand for now in the few packages that really benefit, and send that patch up to Joey to comment
<dholbach> Kamion: Ok. I'll follow up on the post on ubuntu-devel@ saying so.
<Kamion> dholbach: I'm not sure I like the extra dependency
<dholbach> Kamion: I knew it was going to be controversial :/
<Kamion> maybe it would be better for dh_compress to use pngcrush if it's there and require packages that want to use it to build-depend on it themselves? or make it a command-line option? I really don't know, and it seems like the sort of thing that would best be discussed in a Debian debhelper bug
<infinity> pngcrush as a debhelper dependency does seem somewhat unacceptable to me as well.
<infinity> I do like the idea of the "if it's there" option, though.
<dholbach> I'm not sure that it makes sense for package to build-dep on pngcrush - it's the same amount of work to just run pngcrush on your stuff or prod upstream to do it and then happily live on
<Kamion> only trouble with that is that it's a bit nondeterministic
<infinity> Not nondeterminstic in a way that really matters.
<Kamion> true
<Kamion> still, I think it's worth discussing
<Kamion> dholbach: oh also, pngcrush is in universe right now
<dholbach> Kamion: I'm aware of that.
<infinity> Hrm, pngcrush, libpng12-0, zlib1g... That's not SO bad.  I was expecting a longer chain.
<dholbach> Kamion: I just thought it'd be better to get it into main as opposed to let debhelper depend on imagemagick. :-)
<Kamion> dholbach: can we just crush the artwork manually for now?
<dholbach> Kamion: It's not only about artwork
<dholbach> Kamion: documentation, icons, etc etc
<dholbach> but I can do it for artwork, yes
<Kamion> sure, but a lot of those are small enough not to matter
<pitti> pygi: ok, next part of interview just finished, go ahead
<pygi> pitti, well, it was about creating a libburn, libisofs and cdrskin package
<pygi> since sivang probably won't have time to create them, I would like to aks you if you could do it
<pygi> ask*
<pitti> pygi: I'm afraid I won't have time in the next days
<pitti> pygi: you don't want to do it yourself?
<pygi> pitti, busy with hacking on libburn, and I ain't MOTU so won't be able to maintain 
<pygi> I could probably become MOTU If I had someone for key signing, but this way I'll never be MOTU :)
<pitti> pygi: maybe you can remind me again next week; this week I have a lot of other stuff going on
<pygi> pitti, no worries, all god
<pygi> good*
<mneptok> eeek! a cr3!
<pitti> hey sabdfl, how's it going?
<sabdfl> pitti: happily so far, though my own bed is looking more and more attractive! just got to tokyo
<Fujitsu> Hi, sabdfl.
<pitti> big in Japan :)
<sivang> sabdfl: woo, tokyo :-)
<sabdfl> hi Fujitsu, sivang
<sivang> pitti++
<cbx33> hey sabdfl 
<sabdfl> good work on the sounds, cbx33
<cbx33> thanks you're happy with them
<cbx33> ?
<cbx33> I just got SCP finished up too :D
<cbx33> Pessulus is now integrated :D
<sabdfl> cbx33: some concern about length, but nonetheless happy to have someone on it!
<cbx33> sabdfl: well we're gonna put them on Knot3 - I'll just add on this AMD64 machine as soon as the sound finishes....the desktop appears :p
<cbx33> so we can get feedback on them after that
* StevenK sighs, and ponders shredding this textbook.
<sivang> ah damn, mistakengly uploaded bin pkg :-/
* sivang hopes they are discarded automatically
<pitti> sivang: they will
<sivang> pitti: good
<pitti> hi till 
<pitti> tillkamppeter_: maybe freenode requires you to use a nick for half an hour before you can register it?
<cbx33> I'm just hoping SCP can make it into main
<cbx33> but i doubt it will now....
<sivang> pitti: do I need to reupload ?
<pitti> sivang: yes
* mvo takes a small break
<tillkamppeter_> pitti, I succeeded to register tillkamppeter now (seems really to be needed to be logged in for 30 min, they should write this in the FAQ) and I am trying to link tillkamppeter_ to it.
<pitti> tillkamppeter_: great
<tillkamppeter_>  /msg nickserv link tillkamppeter NISfra#3
<pitti> tillkamppeter_: ouch
* StevenK would suggest a different password now. :-)
<_ion> Hmm. /me put "splash" back to the kernel command line. Usplash didn't break the resolution of the virtual consoles anymore, but it didn't show any splash either. How should i debug this?
<tillkamppeter_> pitti, so this wa the test and now I will start over with everything new, as the system is full of traps. Probably I am now better off to take a nick without till and kamppeter and another password.
<tillkamppeter_> Or is there a possibility to change the password?\
<Fujitsu> You can change it.
<tillkamppeter_> Or can I unregister and then start over on another day?
<Fujitsu> Why would you want to?
<jdong> oh keybuk.... where are you.... I think we need to have a talk about the meaning of /sbin/halt... :)
<_ion> jdong: What do you mean?
<jdong> as in, it quite literally performs a halt, instead of the poweroff we're all used to
<jdong> so performing a shutdown from kde/kdm performs a halt
<jdong> leaving my laptop batteries draining all night :)
<Fujitsu> KDE/KDM shouldn't be using /sbin/halt, should it?
<jdong> _ion: bug 59134
<Ubug2> Malone bug 59134 in upstart "upstart fails to power off my system" [Untriaged,Confirmed]  http://launchpad.net/bugs/59134
<jdong> Fujitsu: I don't know what mechanism kdm uses to shut down, but with upstart it's broken :)
<jdong> with sysvinit it worked
<jdong> heck with sysvinit, init 0 worked just fine, too :)
<_ion> Hmm, sysvinit's shutdown(8) says:        -h     Halt or poweroff after shutdown.
<robertj> has anyone seen the patch I mentioned in bug #59327 previously?
<Ubug2> Malone bug 59327 in nautilus "please include this patch to add an Empty Trash button to trash:/// simila to 'Write CD' in Burn://" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59327
<_ion> The use of "or" is interesting. :-)
<jdong> in the 21st century, we tend to power off systems instead of halt them :)
<jdong> isn't upstart supposed to be futuristic? :)
<pygi> jdong, !!!
<jdong> pygi: !!!
<robertj> jdong: we need to to add a nice mechnical halting sound on shutdown :)
<jdong> lol
<Fujitsu_> A lot of machines have one anyway :P
<Treenaks> robertj: or a nice, mechanical crash sound on crashing :)
<jdong> or put up the Windows 95 brown "It's now safe to turn off your computer" via usplash :)
<Spads> screeeeeeeeeCRUNCH
<jdong> that'd be great for april fools
<Fujitsu_> Yup, sounds good, Spads.
* Fujitsu_ runs away from jdong.
<Fujitsu_> No Windows!
<jdong> but it's brown :)
<Spads> jdong: the SF lugs tried to promote "It is now safe to turn ON your computer" as a Linux slogan, few years back.
<Fujitsu_> True.
<robertj> Treenaks: if the sound system was still up we could have a national geographic style announcer "Watch as the program pounces on the process and brings it to the ground, dead in its jaws"
<cbx33> "It's now safe to plug and play" 
<Treenaks> robertj: too bad Keybuk is speeding up shutdown as well as startup :P
<robertj> hehe
<Fujitsu_> Yeah, shutdown is really quick!
<_ion> if (is_april_1st) shutdown_sound = SOUNDS_CRASH;
<robertj> "How quick is it!"
<Fujitsu_> Sorry, teardown.
<robertj> I wonder how long it takes before most soundcards will be online with upstart
<robertj> I've just not got enough guts (nor time) to try it out just yet
<robertj> Ride of the Valkyries
<robertj> hrmm, silly paste buffer, silly xchat-aqua :(
<_ion> jdong: Strange, from a quick look at sysvinit's halt.c it looks like it shouldn't poweroff either if it's called as "halt" without -p. I might be reading it wrong, though.
<jdong> _ion: well, I'm not sure of the explanation, but kdm used to power down my system before upstart, and now it doesn't
<jdong> so I'm blaming it on keybuk :D
<_ion> jdong: Is there a reason for instead of "halt -p" or "poweroff" calling "halt"?
<jdong> _ion: I'm not sure how kdm shuts down... I'm not sure it even uses halt
<jdong> _ion: I'm just observing that halt with sysv did poweroff
<jdong> even with no arguments
<Kamion> halt calls shutdown to shut down properly - halt -p just tells the kernel to die NOW
<Kamion> kdm is right to call halt
<Mithrandir> halt should just halt the system, not power it off, iirc.
<jdong> Mithrandir: not from my experience... it powers down 
<jdong> Mithrandir: but upstart seems to agree with you :)
<_ion> kamion: I thought it was -f, not -p.
<Fade> Mithrandir -- what is the package/revision of the xlibs you sent up?
<Mithrandir> jdong: *shrug*; you probably had buggy hardware or something, then.  It shouldn't.
<Kamion> _ion: oh, hmm, you're right
<jdong> lol
<jdong> so... the verdict... upstart bug or kdm bug? :)
<Kamion> _ion: but see /etc/default/halt, which controls whether /etc/rc0.d/S90halt uses -p
<Mithrandir> Fade: libx11 (2:1.0.3-0ubuntu3) edgy; urgency=low
<Kamion> _ion: kdm still shouldn't use halt -p
<Kamion> jdong: upstart
<mneptok> IIRC, halt only halts the OS, but the BIOS can have a function to power-off on system halt.
<Fade> oh, yeah, I got those. xemacs and gnuemacs are still bjorked.
<mneptok> thus, a hlat effectively is a power down on such machines.
<robertj> btw, can someone enlighten me on what circumstances can leave ext3 requiring a fsck?
<jdong> well, either way, kdm is not turning off my computer :)
<Kamion> Mithrandir: halt with no arguments should power-down if /etc/default/halt says "poweroff".
<mneptok> jdong: check the BIOS
<ogra> jdong, get a new one 
<jdong> mneptok: it's not a bios problem
<Kamion> the chain is quite twisty but that's what it's meant to do
<jdong> if I switch back to sysvinit, kdm happily shuts off my computer
<robertj> I thought the whole idea of these fancy-pants new file-systems was that if the power does go off, you shouldn't need to fsck the drive?
<jdong> robertj: hardware failure
<jdong> robertj: IDE write cache
<jdong> robertj: mount-count/day-count fscking set via tune2fs
<jdong> robertj: the user typing in fsck.ext3 /dev/hda1
<robertj> jdong: hehe :)
<Kamion> jdong: my guess is that upstart's halt's option processing is subtly wrong
<Kamion> it doesn't *look* wrong to me, but that's the only explanation I can think of
<jdong> k
<jdong> you gnome users say that gdm powers down correctly?
<mempf-edgy> hey guys
<jdong> kdm doesn't power down on two of my systems, both using upstart :-/
<jdong> so that leads me to believe it's pretty hardware independent
<mempf-edgy> i read that Texis insterment card readers were going to be fixed in next kernel update
<mempf-edgy> im running the nw kernel but it still doesent ork
<jdong> mempf-edgy: what kind of TI card readers, though?
<Spads> robertj: http://teh.entar.net/~nick/mail/why-reiserfs-is-teh-sukc has some comments from ted t'so about where many jfses introduce errors
<mempf-edgy> Texas Instruments PCIxx21/x515 Cardbus Controller
<jdong> mempf-edgy: TI FlashMedia is pretty depressing
<robertj> Spads: thanks
<mempf-edgy> it was working in dapper....
<jdong> mempf-edgy: cardbus or x-in-1 card readers?
<mempf-edgy> x-in-1
<jdong> and it worked in dapper???
<robertj> is the scheduled fsck off in edgy?
<mempf-edgy> yes
<robertj> because quite simply, that scares the living daylights out of people
<mempf-edgy> perfectly
<jdong> 0a:09.2 Mass storage controller: Texas Instruments Unknown device 803b
<jdong> nvm, mine is different
<jdong> mempf-edgy: I'm not sure then... I got a different TI card reader, and it requires the tifm21xx drivers
<jdong> robertj: isn't it considered healthy paranoia though?
<robertj> nop
<robertj> its my mom "whats wrong with my computer"
<Fujitsu> robertj, yeah.
<robertj> in fact, the black screen being normal is so bad, it vastly outweighs any eror message that might be given
<shenki> I can confirm that; the pci id is 0180: 104c:8033, and it used to work with dapper - today discovered it wasn't working with edgy
<mempf-edgy> wait hold on
<mempf-edgy> when i put a card in it
<mempf-edgy> the light goes on for a split second
<mempf-edgy> it did not before
<Fujitsu> mempf-edgy, can you check syslog?
<robertj> if you tell your mom that the black screen is normal, she is likely to not call you if it says you have bad this, or bad that
<mempf-edgy> where is it?
<Kamion> jdong: the bug is probably that upstart's halt/poweroff implementation doesn't do reboot(RB_ENABLE_CAD) first
<robertj> when SMART status would likely be a much better indicator
<Fujitsu> tail /var/log/syslog
<shenki> Fujitsu, there was nothing in the syslog on insertion for me
<Kamion> which sysvinit does
<shenki> but I haven't rebooted since installing (todays?) new kernel
<Fujitsu> shenki, my Ricoh doesn't mount in Edgy any more, but I get an entry in syslog from the reader.
<mempf-edgy> where do you want it?
<Fujitsu> (when I insert it)
<jdong> Kamion: you want to comment in the bug report?
* jdong has no idea what kamion just said :)
<Fujitsu> mempf-edgy, is there anything regarding the card in there?
<mempf-edgy> yep
<mempf-edgy> Sep  7 05:42:39 Mempftop kernel: [17180242.956000]  tifm_7xx1: sd card detected in socket 3
<mempf-edgy> Sep  7 05:42:39 Mempftop kernel: [17180243.436000]  tifm_7xx1: demand removing card from socket 3
<mempf-edgy> Sep  7 05:42:40 Mempftop kernel: [17180244.132000]  tifm_7xx1: sd card detected in socket 3
<Kamion> jdong: yes, I'm just doing so
<jdong> robertj: smart doesn't say everything....
<robertj> jdong: indeed but the current situation just isn't useful to most end users
<jdong> holy crap, tifm is in the ubuntu kernel?
<jdong> robertj: I'm all for the ext3 periodic fsck, just we need some nicer way of presenting it to the user
<robertj> they don't know what the implications of these errors are non-clear to alot of people
<jdong> i.e. an explanation of what's going on
<jdong> I have seen periodic fscks pick up stuff on ext3 volumes
<jdong> especially on older hardware
<jdong> and smart did not trigger or come close to triggering
<robertj> jdong: it may happen, but people don't want it on by default
<robertj> jdong: its dumb
<jdong> umm, I suppose most people also want their data?
<Kamion> jdong: hmm, actually, may not be quite that, there are a few things involved. I'll comment, anyway
<robertj> jdong: how many back it up?
<jdong> not that many to be honest
<robertj> jdong: not many, ergo they really don't
<jdong> why not switch everyone to reiserfs or xfs while we're at it?
<robertj> jdong: that's the proof that their time is worth more to their data to them
<jdong> heck let's get BenC to add the reiser4 patch to the kernel :)
<mempf-edgy> so now the card is being detected
<mempf-edgy> but not mounted?
<robertj> jdong: what do you think of the windows-way of giving them option to skip?
<pygi> anyone willing to test libburn in an application? :)
<jdong> robertj: I've got no problem with that
<jdong> robertj: right now, doesn't ctrl+c skip the check?
<mempf-edgy> oh, there is another line here in lspci
<mempf-edgy> 05:09.4 Class 0805: Texas Instruments PCI6411, PCI6421, PCI6611, PCI6621, PCI7411, PCI7421, PCI7611, PCI7621 Secure Digital (SD) Controller
<mempf-edgy> not there before
<robertj> jdong: I think it mounts it read-only and halts the boot
<jdong> ugh :-/
<robertj> jdong: I feel like scheduled fscks is a band-aid for an underlying problem
<jdong> robertj: yes. x86's are cheap.
<jdong> the fix would be a battery-backed-up storage controller
<jdong> but who has one of those? ;)
<robertj> jdong: but you only need to do that on dirty right?
<jdong> well, would you rather fsck on every dirty boot? :)
<robertj> jdong: yes
<robertj> jdong: that's the way it works on windows
<robertj> its good for a number of reasons
<robertj> 1. you have limited control over that except for power, etc
<jdong> no it's not... ntfs doesn't fsck ever :)
<robertj> jdong: it's doing some kind of disk checkup
<jdong> not ntfs....
<robertj> yes
<jdong> it doesn't check unless it gets marked dirty
<robertj> jdong: I know
<jdong> and that's only when the fs encounters an error
<jdong> ext3 has that feature too
<jdong> but the problem is, by the time that gets triggered, you've built up enough errors for substantial data loss
<robertj> jdong: it seems to happen 100% of the time if I turn off while Windows is running
<robertj> jdong: so apparently it is pretty effective in whatever metric it's using
<jdong> then something's wrong with your computer
<Amaranth> that reminds me, windows seems to check fat32 partitions every 3 boots
<jdong> I regularly zap power to my ntfs'es, and they never chkdsk
<jdong> Amaranth: huh? it shouldn't
<jdong> fat32 is checked on every dirty mount
<jdong> what we need is a fsck capable of operating online
<robertj> jdong: maybe its because I usually only hard power-off during boot?
<jdong> that could do it
<jdong> but I've damaged my indexes doing that before
<jdong> the worst time to hard-power-off windows is during boot
<robertj> jdong: no
<robertj> while your installing SP2 is the worst
<robertj> (stupid cat)
<jdong> lol
<jdong> but I do see your point, robertj... the way the periodic fsck is presented to the user currently is anything but user friendly :)
<jdong> and while I wish I had the authority to do something about it, I really don't :P
<jdong> launchpad is probably gonna be the best place to complain about this one
* robertj heads out, I'll grape about it there this afternoon
<_ion> jdong: I found the culprit. /etc/event.d/rc0-halt contains "env INIT_HALT=HALT", which (in rc0.d/S90halt) overrides the setting in /etc/default/halt.
<Spads> When FreeBSD got softupdates, they added hooks to fsck so that it would snapshot the filesystem during the fsck and release after.  Don't people have tools to do something like this for ext3?
<jdong> _ion: aha
<jdong> Spads: not without lvm and free space
<Spads> a friend of mine ran fsck from cron.monthly, as I recall
<Spads> ah, lvm...
<jdong> Spads: that doesn't work though
<jdong> Spads: you must snapshot it while it's mounted ro
<jdong> then mount it rw and continue bootup
<jdong> but once you're booted, you can't put it back to ro easily
<jdong> without disrupting everyone
<Mithrandir> that only works if you don't get any errors.
<jdong> and fscking an rw'ed ext3 partition will always get errors
<Spads> because of smearing
<Spads> yeah
<jdong> and softupdates are not magical on x86 either
<jdong> I've had cases where after a 2nd reboot FreeBSD went ahead and did a full fsck
<jdong> and found problems, too
<Spads> oh, believe me, I've no illusions about softupdates
<jdong> I am guessing the ide write cache is the culprit there, too
<Spads> I took Kirk McKusick's kernel class during a period where he'd pretty much come to the realization that the tradeoffs for SU vs a JFS just plain weren't worth it
* jdong goes and eats breakfast
<mempf-edgy> il file a bug if you guys can tell me what logs and stuff  i should include
<jdong> _ion: you gonna put what you found in the bug report?
<jdong> _ion: 59134
<_ion> jdong: Done.
<mempf-edgy> how do i manully mount a sd card?
<cbx33> hey seb128 
<synic> How does one go about getting an app into the repos?
<Kamion> mvo_: ok, I've been looking over that branch. Just from inspection, it looks mostly correct, although the control flow with regard to whether '?' was seen in front of a seed entry is a little confusing; I don't know if anything can be done about that. Maybe add a comment
<Kamion> mvo_: have you been able to test it at all?
<Hobbsee> synic: see the /topic - ask in #ubuntu-motu
<mneptok> synic: all repo modifications are delivered via Jarts
<Hobbsee> mneptok: jarts?
<mneptok> http://mowabb.com/aimages/images/07-06-04.jpg
<Hobbsee> ah
<mneptok> and here's a set - http://tonova.typepad.com/thesuddencurve/images/Jarts-thumb.jpg
<mneptok> lawn darts. now illegal in the US, iirc.
<Spads> illegal how?
<zul> probably you cant take them on airplanes for one
<seb128> cbx33: hi
<dholbach> re
<seb128> hi dholbach
<cbx33> hi again dholbach 
<mneptok> Spads: illegal as in "you cannot manufacture or sell them new"
* dholbach hugs seb128 and cbx33
* seb128 hugs dholbach
<Spads> hmmm
* cbx33 hugs seb128 and dholbach 
<mneptok> Spads: i doubt the FBI would kick your door in for owning Jarts, but then this is 2006 ....
<Spads> right
<cbx33> we used to make warts!
<cbx33> wall-darts
<Spads> it's just that saying "these are illegal in the US" makes it sound like they're contraband items across the country
<cbx33> drawing pin and a little origami, mixed with some blu-tack !
<Spads> saying "these were recalled by court order due to infant injury claims" or whatever is something else
<mneptok> Spads: if you take off your tin-foil hat the sentences sound pretty similar. :)
<mneptok> but then, this is 2006 ...
<Spads> mneptok: so you're saying that if you allow in the government elf-rays, your brain interprets only two levels of legality?
<Spads> I would say that you are a conspiracy nut!
<mneptok> Spads: i would say you are either entirely correct, or should be shipped to Guantanamo Bay
<mneptok> mmm .... binary.
<Spads> you're either with us or you're with the aliens
<mneptok> i'm with you. i tried the aliens, and the hours sucked. and they have crazy unions.
<sladen> mneptok: crazier hours than Canonical?
<mneptok> touche.
<Whoopie> Hi, did anybody look at the issue that some packages don't arrive in dapper-backports or dapper-proposed although they were build successfully? e.g. xchat in dapper-backports or openoffice.org-l10n in dapper-proposed.
<jdong_> Whoopie: it's an effect of bug 58144, last I heard
<Ubug2> Malone bug 58144 in soyuz "Backport is rejected if an older backport is already there" [Critical,In progress]  http://launchpad.net/bugs/58144
<Whoopie> jdong_: ok, thanks.
<Whoopie> jdong_: strange, that it also affects dapper-proposed
<jdong_> Whoopie: I'm not sure about proposed, though
<jdong_> Whoopie: I wouldn't be surprised if it's the same bug though
<Kamion> jdong_: no, it's not
<Kamion> er, well, would need to check but it seems unlikely
<Kamion> oh, it's easy
<Kamion> Whoopie: openoffice.org-l10n is just in NEW, that's all - it built binaries which weren't previously in dapper
<jdong_> hehe
<Kamion> xchat is as jdong says, an entirely different issue; those were rejected
<pitti> Kamion: can you please approve the hoary-updates langpacks?
<Whoopie> Kamion: so openoffice-org-l10n needs to be approved?
<Kamion> to be precise, openoffice.org-help-pl was added
<Kamion> Whoopie: yes; I'm doing it now
<Whoopie> cool, thanks.
<Kamion> pitti: I'm reluctant to do (non-proposed) stable release updates until we've finished doing the post-mortem of the X update
<Kamion> pitti: mdz explicitly asked me not to process dapper-updates until that was done, and while he wasn't explicit about hoary-updates, I'd rather be conservative
<pitti> Kamion: alright
<pitti> Kamion: post-mortem means, the exercise how to quickly disable an -updates version by adding a fake version into *-security Packages.gz?
<bluefoxicy> sweet, compressed caching for 2.6.18-rc6 has page cache compression
<Mithrandir> pitti: more like "what went wrong and how are we going to prevent it from happening in the future".
<bluefoxicy> Too bad Nitan doesn't want to shoot this at mainline when it's done.
<Kamion> pitti: what Mithrandir said. A post-mortem (colloquially) is a study you do after something went wrong to find out what Mithrandir said.
<Kamion> wow, running setupcon from within ubiquity is rather fun
<Kamion> especially the screen flicker as it switches from tty to tty
<Kamion> must fix that
<Mithrandir> Kamion: just don't load the font in ubiquity?
<Kamion> whoa, and it's totally buggered my keymap
<Kamion> Mithrandir: surely loadkeys needs to change tty as well
<Mithrandir> Kamion: hmm, maybe.
<Hobbsee> who's working on usplash, and do they know that it's not displaying boot messages at all now, since 0.4-17?
<Hobbsee> or should i just file a bug over this?
<Hobbsee> mjg59 it looks like
<mvo_> Kamion: thanks for looking over it. I did did it and marked openoffice as a recommend. that worked nicely. I also rebuild ubuntu-meta and it produce correct new relations. I have not tested apt yet with it because we would need the new section "metapackages" first. but I did test the apt behaviour for other packages
<mjg59> Hobbsee: That's correct behaviour
<mjg59> Remove quiet if you want messages
<Hobbsee> mjg59: ah right, so what's the point of the black box then?  just artwork?
<mjg59> Yes
<Hobbsee> gotcha.  cool :)
<seb128> infinity: did you plan to try getting a new samba version of edgy? nautilus-share (which is a cool tool to share folders on smb from nautilus) requires 3.0.23 and we have 3.0.22 
<gnomefreak> Hobbsee: i just filed bug on that :)
<gnomefreak> ill close it
<Hobbsee> gnomefreak: guess you'd better reject it.  you must have only just done it, as when i checked a min or so ago, there was nothing there
<gnomefreak> i did
<Hobbsee> gnomefreak: maybe with an explanation - that's one that's likely to get plenty of dupes
<mvo_> Kamion: one issue with the "?" is that filterPackages support shell-like globing for packages and "?" is than not a good choice. me have have to use something else
<gnomefreak> true
<Kamion> mvo_: let's just do "optional: package"
<Kamion> oh, no, let's not
<Kamion> that syntax is used for fields
<Kamion> mvo_: "(package)"?
<mvo_> maybe "weak:"? "~"
<mvo_> I like the "(pkg)" idea!
<Kamion> yeah, feels right
<giftnudel> is there a known reason (upstart?) that my laptop doesn't try to resume from my swap partition after hibernate?
<Kamion> Mithrandir: hmm, setupcon isn't even supposed to do anything unless it's run from a console ...
<madduck> giftnudel: cat /etc/initramfs-tools/conf.d/resume
<mvo_> Kamion: ok, added. I will do some more testing now. how should I proceed? just upload it if I think its fine? or wait for you to merge and upload?
<giftnudel> madduck: no such file
<Kamion> mvo_: upload it as 0.21ubuntu1, please - I'll sort out the rest later
<madduck> create it ("RESUME=/dev/sdb2" here), then update-initramfs -u
<madduck> the try again
<giftnudel> madduck: thanks, will try that
<madduck> giftnudel: at least this is what Debian does
<Kamion> mvo_: fortunately in this case it isn't important to have it installed on DC systems
<Kamion> madduck: yes, same for Ubuntu
<giftnudel> hmm, why don't I have that file then
<giftnudel> and I don't have it in dapper either
<Kamion> giftnudel: it's created on installation; upgrades from older systems may not have it
<Kamion> or you may not have had swap around during installation
<giftnudel> funny, but it always worked ....
<Kamion> there are several possible reason
<Kamion> s
<giftnudel> hmm
<Kamion> or there's a bug and something removed it, or or or ...
<Mithrandir> Kamion: true, but it's explicitly given one from the config script.
<Kamion> Mithrandir: OH
<Mithrandir> Kamion: maybe that's a bit too big a sledgehammer
<Kamion> nadgers
<Kamion> let me ponder that over late lunch
<Mithrandir> the evil solution is have ubiquity set UBIQUITY_RUNNING=1 or something and then poke that.
<bddebian> Hello
<Kamion> Mithrandir: I think the right answer is to have rootskel's /etc/profile call setupcon (it already sets the console to UTF-8 mode) and remove that change from console-setup.postinst.
<Mithrandir> Kamion: ok
<doko> Kamion: please could you process #59049, translate-toolkit sync request. needed for the next OOo upload
<netdur> guys!!! you forgot to release ubuntu preview!!!!!!
<mdz> Kamion: yes, that applies to *-updates
<Mithrandir> netdur: hm?
<bluefoxicy> Cool, you can request feedback on specifications.
<netdur> you used to release ubuntu preview the same day gnome release
* bluefoxicy ponders if he should bug BenC or mdz...
<Mithrandir> netdur: betarelease isn't until sept 28th
<Kamion> Mithrandir: it does mean that if you have a running shell then it won't be reconfigured, but I think that's ok
<Mithrandir> Kamion: agreed
<jdong> netdur, go grab a nightly :)
<mdz> bluefoxicy: you can, but it doesn't email the person, and as such isn't very useful
<bluefoxicy> mdz:  ah, so it's just until you happen to click the spec and see "hey this guy wants feedback from you"?  bleh :P
<netdur> jdong, sweet
<bluefoxicy> I don't have a real reason anyway, I'm just fooling around
<mjg59> Right
<mjg59> So
<mjg59> usplash should now be happier
<bluefoxicy> mjg59:  did you teach it to not arserape my screen?
<mjg59> I believe so
<jdong> mjg59: you mean it'll stop turning off my screen and/or corrupting all my vt's? :)
<bluefoxicy> I'm tired of shutting down and going from gnome desktop to a pink screen
<jdong> at least the former masks the latter :)
<mjg59> It works on the hardware I have here
<jdong> wow, when have we heard that before....
<jdong> *cough* xorg * cough*
<mjg59> I would expect it to work elsewhere, but it's hard to be certain
<mjg59> Oh, unless you're using vga=. Then you lose.
<jdong> lol
<jdong> nope
<mjg59> I'll worry about that at some later date
<bluefoxicy> jdong:  I suggested kdrive before but :>  The overhead of bringing up a fully functional vesa X server is probably insurmountable.
<mjg59> What would kdrive buy us?
<jdong> well, when -18 comes rolling in, I'll test out usplash
<bluefoxicy> Fedora does that but uses full out Xorg and it takes 42 seconds longer to boot because of it I hear
<mjg59> usplash overhead is between 0 and a second, based on my measurements
<bluefoxicy> mjg59:  it's an actual X server, rather than an attempt to write on the frame buffer console or use of svgalib etc; I doubt it'd buy you anything aside from being able to say you're incredibly lazy.
<bluefoxicy> Probably slow, like with Fedora
<jdong> lol
<mjg59> bluefoxicy: It's an actual X server that makes vesa calls in an identical manner to svgalib
<mjg59> Anyway. svgalib is much nicer now that I've thrown out all the crack.
<bluefoxicy> as long as it's behaving now I'm happy.
<bluefoxicy> oh, what the hell
<bluefoxicy> I should find out what happened to xscreen
<jdong> hey, anyone knows what it takes to get those cool discharge graphs in gnome-power-manager?
<bluefoxicy> that was a google SoC this year
<Kamion> Mithrandir: actually, hmm, running setupcon at shell startup will do the vt switch thing, which will be annoying; I guess it would be ok to check whether we're really in d-i by means of checking some other path
<jdong> my core duo doesn't show em, while my toshiba does
<Kamion> e.g. /lib/debian-installer
<mjg59> jdong: Is your core duo a laptop?
<jdong> mjg59: yes...
<jdong> I get a device information and event log tab
<mjg59> And if you run on battery, does something appear under "current rate" in /proc/acpi/battery/whatever?
<bluefoxicy> http://code.google.com/soc/xorg/appinfo.html?csaid=73A89F18E7770493
<bluefoxicy> There we go.
<jdong> mjg59: present rate, yes...
<mjg59> jdong: Unsure, then
<mjg59> I'll take a look at some stage
<Spads> IS CHICAGO
<Spads> IS NOT CHICAGO
* bluefoxicy knots jdong?
<sladen> mjg59: is svgalib working okay on amd64?
<mjg59> sladen: In general
<iwj> seb128: AYT?
<mjg59> May die horribly on some nvidias
<mjg59> Someone needs to debug that
<mjg59> It's x86emu, not svgalib as such
<bluefoxicy> hmm.  on i386 it looks like I have "generic kernel for x86-64"
<knot_jdong> bluefoxicy: shh.... mornfall is looking for me....
<iwj> seb128: You seem to have dropped my patch for SuggestedPackagesForFiletypesSpec from nautilus.  Why ?
<mdz> doko: ping
<thom> Keybuk: http://www.clearairturbulence.org/edgy-20060907-1.png as requested
<doko> mdz: pong
<thom> Keybuk: (for ath0 not coming up correctly)
<seb128> iwj: ups
<Keybuk> thom: thanks
<iwj> seb128: It's strange because you left the entry in the changelog.
<seb128> iwj: because you didn't put it to debian/patches as we do for GNOME packages usually
<seb128> iwj: yeah, and I just copy debian/ over from one version to the new one
<iwj> That's not a sound approach.
<seb128> iwj: we don't package changes out of the debian dir usually
<iwj> Because people (like all Ubuntu developers) are entitled to dpkg-source -x, edit, upload.
<seb128> changes to the .diff.gz are evil
<iwj> And we don't have time to learn how this package does its stuff.
<iwj> If you really think that then you can turn it into a stupid debian/patches thing.
<seb128> iwj: simple, drop the diff to debian/patches
<Keybuk> iwj: I'd disagree ... if you edit a source, you should take 5s to figure out how to apply a patch to it
<Keybuk> that's basic common sense
<mjg59> And then figure out if it needs numbers at the front, if it needs to end in .patch, if it needs to be listed in 00files...
<iwj> seb128: There are THOUSANDS of packages.  It's NOT ON to require weirdshit knowledge of specific package build systems.
<mvo_> iwj: I'm with seb128 here, there is a pretty consitent style over all gnome packages
* zyga goes home
<iwj> Keybuk: There is a standard way to apply patches to sources.  dpkg-source -x; edit; upload.
<mvo_> bye zyga
<seb128> iwj: so send the patch on launchpad next time and somebody knowing the package will apply it
<Keybuk> iwj: that has not been standard for quite a while
<zyga> mvo_: bye, talk to you in the evening :)
<Keybuk> iwj: by numbers, debian/patches is now the standard
<iwj> Only because of idiocy.
<Keybuk> *shrug*
<mvo_> *cough*
<HiddenWolf> !coc
<seb128> iwj: yeah, and 5 people do that with different changes and then you can't figure what changeset is doing what
<iwj> seb128: Perhaps you and gnome upstream can't.
<seb128> yeah, and I'm maintaining that package
<iwj> I and Mike Hommy have been doing firefox like this and figuring out which patch is what is _not_ the problem.
<iwj> dpkg-source -x should produce the source code ready for editing.
<iwj> That's what it's for.
<seb128> debian/patches allow to make clear separation of changes you apply
<seb128> and dropping a patch to it is not that hard
<iwj> Anyway, edits in the .diff.gz are easy to spot.  If you don't like them you can write some tool to include them in debian/patches or something.
<seb128> anyway, I'll fix that one
<seb128> if you prefer just mail me the patch next time
<seb128> or attach it to a bug
<iwj> Yay!  The Maintainer Lock is back!
<seb128> yeah, I just didn't think somebody went to change the diff.gz when I updated
<seb128> no, it's not
<pitti> iwj: personally I consider the lack of a standard patch system a bug in Debianish source packages; that's the sole reason why we do have so many patch systems
<Keybuk> iwj: there's no need for a maintainer lock if you take the minimum of care when changing source
<iwj> Of course no-one would edit a package in the normal way that packages are edited.
<seb128> I was just trying why I dropped your patch by mistake
<mvo> iwj: please, as I said, gnome is having a consitent policy for those things. it makes maintaing the big amount of packages eaiser
<Kamion> sure it is, if you're not even bothering to check for updates!
<Keybuk> iwj: you wouldn't patch C code with a different coding-style to the one upstream used
<Kamion> that might as well be a maintainer lock
<Keybuk> so why patch packages with a different patch-style differently?
<pitti> iwj: I don't consider inline diff.gz patches the 'normal way' either - it's evil, it's hard work to upgrade to a new upstream version, it's hard to check patches and send them around, etc.
<gnomefreak> mjg59: you have a sec?
<iwj> hard> I don't find it so.
<iwj> See rants on debian-devel passim.
<Keybuk> seb128: you should really check the package before just copying the debian/ dir out though
<iwj> Patch systems are for people who can't grok code.
* mvo agrees
<seb128> Keybuk: I did a mistake, no big deal
<seb128> I'm going to fix it now ;)
<Keybuk> seb128: in fact, I seem to recall you once didn't even check for a new version of the package in the archive before doing an updated version
<seb128> Keybuk: doesn't ring a bell to me
<iwj> Keybuk: That happens sometimes too; it's because we have no machinery to prevent it.
<pitti> iwj: 'Patch systems are for people who can't grok code.' -> heavy NACK; that might be your personal opinion, but it's not common sense
<dholbach> seb128 does no mistakes
<seb128> Keybuk: maybe that was "somebody uploaded while I was working on the update and I didn't check again"
<iwj> In Debian the maintainer lock prevents it but in Ubuntu you can do it by mistake because the process is racey.
<iwj> Anyway:
<Keybuk> yes, yes, the process sucks
<Keybuk> NEWS AT 11
<iwj> seb128: Thanks for fixing it up.
<Keybuk> :p
<seb128> iwj: np, sorry for dropping it
<iwj> I'll try to remember that gnome packages have patch nightmares.
<pitti> NoMoreSourcePackages!!!11!one!
<pitti> :)
<mvo> yeah!
<iwj> Do you need any help ?  I have lots of diffs and old versions and stuff lying around here.
<Keybuk> pitti: mmmm, vapourware :-/
<seb128> I would no call "putting a diff to debian/patches" a nightmare ;)
<pitti> Keybuk: 'import future'
* mvo finds cdbs-edit-patch realy convinient to use
<iwj> We'll just have to disagree about the patches but obviously I can try to remember for these packages.
* mvo hugs pitti for it
<pitti> iwj: in general, the existance of debian/patches/ dir indicates a patch system; and IMHO it's not hard to check for that dir
<seb128> iwj: no, that's fine, I've the previous version on the disk and the change is fairly trivial
<seb128> thank you 
<_ion> mvo: Yeah, cdbs-edit-patch is very handy.
<iwj> Keybuk: Soyuz should check that the previous ubuntu version is mentioned in the changelog (with a full-text grap).
<iwj> s/grap/grep/
<Keybuk> iwj: write a spec ;)
* Kamion has to go out to play chauffeur; back in a bit
<iwj> Keybuk: I might do :-).
<pitti> Keybuk: NoMoreSourcePackages would make this spec obsolete, too, right?
<iwj> seb128: Could you pass me the new .diff/.dsc under the table ?
<iwj> I want to do some last-minute faff :-).
<Keybuk> pitti: in theory
<mjg59> gnomefreak: Hi
<gnomefreak> mjg59: hi. is it usplash that has to do with tty?
<mjg59> No
<Hobbsee> gnomefreak: what about tty?
<gnomefreak> it doesnt work
<gnomefreak> none of them
<Hobbsee> sigh.
<Hobbsee> "doesnt work" is useless.
* Hobbsee just found that the fonts are much, much bigger, which makes them unusable.
<mjg59> Hobbsee: Should be fixed
<Hobbsee> mjg59: cool, okay, i'll try rebooting later today.
* Hobbsee should go sleep
<mjg59> Hobbsee: -18 has saner code
<Hobbsee> yay :)
<gnomefreak> blinking cursers depending what tty you use depends where curser is
* Hobbsee waits for it
* jdong|laptop breaks out pbuilder and builds it himself
<Hobbsee> mjg59: any ETA on when that will hit the archives?
<jdong|laptop> Hobbsee: it'll hit my archives in around 45 seconds :)
<mjg59> It's uploaded
<Hobbsee> mjg59: cant see it on LP
<Hobbsee> maybe i'm blind
<jdong|laptop> Hobbsee: usually lp lags a few hours
* jdong|laptop knows from staring at fresh backports
* jdong|laptop really has no life
<Hobbsee> right
<seb128> iwj: http://people.ubuntu.com/~seb128/nautilus-update/
<Kamion> back
<iwj> seb128: Thanks a lot.
<jordi> jono: haha, cool pic :)
<jono> jordi, :P
<seb128> iwj: np
<iwj> seb128: dpkg-source: error: file nautilus_2.16.0-0ubuntu2.diff.gz has size 740219 instead of expected 114796
<iwj> !
<seb128> iwj: weird
<iwj> Strange.
<iwj> My w3m downloaded a huge version.
<iwj> wget worked.
<seb128> it has the correct size on rookery
<seb128> k
<seb128> weird
<Seveas> mjg59, ping
<Kamion> doko: translate-toolkit done
<lemsx1> i'm glad to see StickyNotes applet again! 
<jordi> heya Huahua 
<Huahua> hey, jordi 
<Amaranth> iwj: ping
<iwj> Amaranth: ponb
<iwj> Amaranth: pong even
<Amaranth> iwj: I'm trying to find a way to force firefox to use a specific proxy (and not let users turn it off), http://in-cider.spaces.live.com/blog/cns!1F17474AB1F2CE52!338.entry is all I've found on it so far. Does that look like a bad solution?
<lemsx1> Amaranth: this is not the right place for those questions. but what you need to do is learn to use user_prefs in the .js file. put the proxy information there and make the file read-only (or use a global file from /etc)
<Amaranth> lemsx1: Sure it is, I'm trying to make a package do it. :P
<lemsx1> Amaranth: in Windows you can do other things like a pseudo-encryption of the .js file after you set the settings as you want. google it
<iwj> What stops the user downloading ff from the official site and installing it in their filespace ?
<Amaranth> Nothing. :/
<Amaranth> I hate firefox.
<iwj> So use a firewall.
<lemsx1> Amaranth: all apps in UNIX would go through the same issues. not just Fx
<Amaranth> Well, one thing stops them: I'm blocking port 80 out for everyone except the daemon user
<ogra> iwj, the iptables rule we talked about before wont let them browse unless they set their proxy settings right
<ogra> it wont be intercepting, but port 80 will surely be blocked
<kristog> ogra: hey :) did you read my query ?
<lemsx1> Amaranth: iptables allows redirect to 3128 for transparent proxies
<iwj> ogra: Right.
<ogra> so even if the install in ~/ it will work 
<iwj> Amaranth: So why do you care if the user finds some way to override the proxy settings and breaks their own web browsing ?
<lemsx1> Amaranth: it's actually really easy to do with shorewall
<Amaranth> iwj: Well, ok, forcing it isn't required.
<iwj> lemsx1: Intercepting proxies are Evil, Bad and Wrong.
<ogra> he wants it fully automatic
<lemsx1> iwj: but it works
<iwj> Amaranth: So just drop it in /etc/firefox/pref or whatever the dir is.
<iwj> lemsx1: No it doesn't.  RTFRFC.
<Amaranth> I just want to automatically set it without touching the user profile.
<ogra> lemsx1, it doesnt ... dont start that discussion again pease 
<lemsx1> iwj: I've done that setup at home. it works. use shorewall
<ogra> *please
<lemsx1> ok
<ogra> thanks :)
<lemsx1> iwj: you are right. it doesn't work
<iwj> lemsx1: Come back when you've read and understood the RFC which explains how it fails.
<Amaranth> Well, it does work 99% of the time.
<Amaranth> That 1% will kill you though.
<iwj> Of course the web is randomly flakey anyway so you probably don't notice an increase in flakiness.
<iwj> Amaranth: Sure.  /etc/firefox/pref, create a file called your-thing.js containing appropriate pref() things.
<Amaranth> alright
<Amaranth> now the fun part is boosting the proxy to root to install that file then dropping again :)
<ogra> Amaranth, probably keep that for edgy+1 ?
<mvo> Kamion: I uploaded germinate and will upload ubuntu-meta next with the support for recommends (no seed changes yet,) just so that the next ./update will do the right thing(tm)
<Amaranth> ogra: I suppose
<ogra> smells a bit like suid hell
<Amaranth> i'll upload the package i have now then
<Amaranth> i'll work on that in a separate branch or something
<iwj> Amaranth: Why not ship the file as part of the proxy package or the config package or something ?
<ogra> right
<ogra> iwj, the gui has a checkbox ...
<Amaranth> iwj: Well, the configuration GUI for the proxy has this little checkbox to turn the rules on/off
<ogra> it will en/disable the proxy
<iwj> Ahh.  userv is the answer :-).
<Kamion> mvo: ok; please bump the versioned build-dependency on germinate
<ogra> hehe
* iwj plugs shamelessly.
<mvo> Kamion: right, will do
<ogra> iwj, so why isnt it in main then ? :P
<iwj> Nothing in main is using it and we don't care enough about server admins who are weirdos enough about security to want it.
<iwj> Yay, seb128's new nautilus breaks it totally as I expected, by exposing the gnome-app-install breakage.
<iwj> So excellent, my test case has arrived.
<seb128> iwj: break what?
<seb128> the feature?
<iwj> You unbroke the attempt to use the feature.
<iwj> But gnome-app-install is broken too.
<iwj> Don't worry about it, it's not your fault :-).
<seb128> pfiouuu ;)
<seb128> we can blame mvo then :p
<iwj> I go away for a week and look what happens ...
<gnomefreak> what is the package to file a bug on the alternate installer?
<Kamion> gnomefreak: the catch-all package is debian-installer
<gnomefreak> ok ty
* mvo blushes and mumbles something incomprehensible
<iwj> Woah, bzr blame is actually called bzr blame.
<Spads> haha
* mvo always uses bzr praise
<iwj> I tried `bzr ann' and that didn't work, and I didn't fancy typing `annotate' every time ...
* jdong|laptop suggests setting up an aliase
<jdong|laptop> alias*
<dholbach> or add it to bash completion :)
<LarstiQ> Isn't ann aliased?
<LarstiQ> it is in bzr.dev at least
<LarstiQ> and also 0.9
<doko> seb128, dholbach: is gtk-clearlooks-gperfection2-theme the replacement for gtk2-engines-clearlooks?
<dholbach> doko: no
<dholbach> doko: gtk2-engines has the "real thing"
<Kamion> Keybuk: any idea why udevinfo -q name -p /block/loop0 says that there's no record for /block/loop0 in the database?
<Kamion> sorry, make that loop1, better example
<Keybuk> Kamion: because nothing interesting happened to it, usually
<Kamion> I know udev knows about the device because:
<Kamion> brw-rw---- 1 root disk 7, 1 2006-09-07 17:46 /dev/loop1
<Kamion> which is about when I did 'modprobe loop'
<Keybuk> right
<Kamion> Keybuk: shouldn't it be able to tell me the associated device name?
<Keybuk> no symlinks, no programs, etc
<Keybuk> Kamion: if udevinfo returns no information, then the device name is the kernel name
<Kamion> oh, I guess this is why casper has an ||
<Kamion> ok, fair enough
<Keybuk> it's an odd "optimisation" that udev doesn't store things in its database if it didn't rename them
<Keybuk> if udevinfo doesn't return a name, assume basename of the DEVPATH basically
<Kamion> ok, thanks
<Keybuk> it increasingly rarely comes up these days, because we have so many little helper programs that look at block devices
<Keybuk> but it still can come up when it's just a plain device with no interesting features
<Keybuk> udevinfo -q name -p /class/mem/null
<Keybuk> ^ e.g. :p
<jdong|laptop> Keybuk: are you gonna make upstart shut down right? ;-)
<Keybuk> jdong|laptop: I think we've figured that bug out :p
<jdong|laptop> Keybuk: rc0-halt's envirnment override?
<Keybuk> indeed
<jdong|laptop> *rephrases* Keybuk: are you gonna upload a new upstart that fixes that problem?
<jdong|laptop> <g>
<Keybuk> I always assumed "halt" did what it said on the tin, and halted the machine
<Keybuk> so I implemented it that way <g>
<jdong|laptop> lol, make sense :)
<Keybuk> yeah, there will be a new upstart today that fixes most, if not all, of the open bugs
* mvo is away for ~2h
<Keybuk> it's a bit kooky that kdm calls "halt" instead of "shutdown" though :-/
<Keybuk> on most UNIXen that will literally just halt the machine
<jdong|laptop> heh, don't blame me for that one :)
<jdong|laptop> it's kdm... what can I say? :)
<pitti> G0SUB: ping?
<G0SUB> pitti: hello
<Riddell> ogra: is willowng the edubuntu web filter thing?
<doko> Kamion, mdz: I would like to upload OOo 2.0.4 release candidate 1; I don't see major problems on i386, amd64 (ia32) and powerpc.
<ogra> Riddell, yep
<Amaranth> Riddell: yeah
<Amaranth> now with KDE frontend ;)
<Riddell> Amaranth: that's what I just noticed
<Riddell> Amaranth: written by you?
<lamont> pitti: ping
<pitti> lamont: pong
<Amaranth> actually, no, i never even tried it :P
<Riddell> Amaranth: who made it?
<Amaranth> LaserJock pointed me to a repo, said it works for him, i merged :)
<lamont> pitti: wondering why you didn't just sync bind9 from sid like I suggested for edgy....
<Amaranth> Robert Ray is his name, I think
<Amaranth> i've never seen him on irc
<Riddell> Amaranth: interesting
<Kamion> doko: I'd like to leave that decision to mdz
<pitti> lamont: we can still do that if we can drop the ubuntu changes; I didn't check
<LaserJock> Robert Day
<pitti> lamont: I just uploaded the same version to dapper-security and edgy
<Riddell> Amaranth: got a URL?
<lamont> the ubuntu changes were all obsoleted by switching to lsb functions in 9.3.2-2
<pitti> ah, cool
<lamont> pitti: ah, ok
<lamont> I guess I'll forgive you then
<doko> Kamion: I need just an ok, not a discussion ;-)
<Amaranth> the one in the 0.3 package is ugly codewise, i have new patches from him that fix it
<pitti> lamont: I'll file a sync request
<Amaranth> Riddell: Nope, I only know of him through LaserJock and one email
<Riddell> crazy
<LaserJock> Riddell: I'm putting willowng on a Kubuntu 6.06.1 project I'm working with with raphink
<Amaranth> LaserJock: The KDE GUI will need to be patched to remove the entire first tab for that
<dholbach> pitti, iwj: did you hear of http://www.g2zero.com/2006/09/examining_defects_in_the_firef.html already? :-)
<Kamion> doko: I'm just telling you it won't be from me
<_ion> keybuk: kdm probably calls halt to poweroff because halt has done exactly that forever, at least on Debian and Ubuntu. :-)
<LaserJock> Amaranth: really? for the domain filtering, or is that a different tab
<zyga> re
<pitti> dholbach: ouch
<Riddell> LaserJock: is this written using pykde3?
<LaserJock> Riddell: it might be pyqt3 actually
<LaserJock> I think
<lamont> pitti: the debian version is 9.3.2-P1-1....
<LaserJock> Riddell and Amaranth: rkd is the guy that wrote it
<rkd> hey
<lamont> pitti: so yeah, you can sync that
<pitti> nice
<zyga> bah
<zyga> gaim deadlocks when I drag a buddy from one group to another
<mjg59> Seveas: Hi
<lamont> pitti: oh right.  9.3.2-2ubuntu1 was doko dropping the gcc-3.3 build-dep for powerpc.  that's incorporated in my upload
<Amaranth> hey rkd
<Seveas> mjg59, did you merge from my branch today?
<lamont> pitti: 9.3.2-P1-1 also has a little bit of low hanging (and low risk) changes
<rkd> Amaranth, was my cleaned-up willowng-config-kde code ok?
<mjg59> Seveas: Earlier on, yes
<Amaranth> haven't tried it yet but it looks nice
<rkd> great
<Seveas> mjg59, including the multi-variant themes and the fix for the rather silly timeout bug?
<Amaranth> rkd: Any chance you could just load the .ui file instead of doing code generation?
<mjg59> Yup
<Riddell> hi rkd, thanks for doing the KDE williowng
<Seveas> great -- then my usplash work is done for now 
<Seveas> artwork people will probably poke me for theme creation though
<sladen> Seveas: out of interest, do all of your lines end to Japanese unicode?
<mjg59> Seveas: I wasn't quite clear on the use of the term "cropped"
<rkd> Amaranth: it's possible, i guess, but i'm not experienced enough with QtDesigner to know if you can; currently after every UI change I have to manually add in a fair bit of init code to load modules, set up DBUS etc.
<Seveas> mjg59, the term cropped is wrong
<rkd> Riddell: no problem
<Riddell> Amaranth: that's possible but there's a bug which means you can only do it from the same directory
<Seveas> my english isn't always 100% -- it should be 'scaled'
<_ion> sladen: Yes. 
<Amaranth> Riddell: yuck
<mjg59> Seveas: Ah, ok
<jdong|laptop> god! the unicode! I can't take the unicode!
<Seveas> 
<Seveas> hi jdong|laptop !
<Amaranth> 
<jdong|laptop> lol
* jdong|laptop looks over at unhappy Gentoo ASCII box
* jdong|laptop pops in Edgy Knot 2 CD
<janimo> seb128, pitti: you know which irc chan is most likely to have gnome-cups commiters?
<pitti> janimo: no, sorry
<Amaranth> Seveas: That would almost look like a homestar runner thing if the font used for katakana had antialiasing
<seb128> janimo: nobody is working on it, bugzilla
<seb128> janimo: you can try #gnome-hackers but don't expect too much
<janimo> seb128: their bugzilla has >60 open bugs so not a good idea I think.
<janimo> I saw hub committed at least once 
<seb128> 60 open bugs is nothing
<janimo> seb128: nautilus is not a benchmark :)
<LaserJock> heh
<seb128> still, 60 bugs is nothing for an upstream product
<seb128> nautilus has almost 1000
<janimo> see what I said above re nautilus
<zyga> lol :)
<jdong|laptop> Seveas: do you think your freenx packages would work in edgy?
<jdong|laptop> (yes, I am that lazy)
<zyga> nautilus bug benchmark systedm 
<Amaranth> 60 open bugs is small
<seb128> janimo: http://bugzilla.gnome.org/reports/weekly-bug-summary.html
<Seveas> jdong, only if you set bash as /bin/sh -- I need to fix freenx
<seb128> janimo: look the top 15
<Seveas> but NX is in a horrible condition
<jdong|laptop> Seveas: k, does setting bash as /bin/sh break anything else?
<jdong|laptop> and hell why isn't that default?
<seb128> janimo: I was not saying that nautilus doesn't has lot of bug, just that 60 is really low
<Seveas> because dash is a lot faster
<jdong|laptop> ah, ok
<seb128> janimo: anyway when there is no activate maintainer not easy to get somebody to commit
<_ion> seveas: A quick solution would be modifying the scripts to have #!/bin/bash
<Seveas> indeed
<seb128> janimo: IRC will not make it better than bugzilla
<_ion> Or "solution" at least.
<Seveas> patches apprecitated
<jdong|laptop> Seveas: is it ok just to symlink bash to sh, or is there a debianish way of doing it?
<Seveas> or time
<seb128> janimo: hub decided to commit his patch because nobody was replying, I'm not sure he's wanting to commit patches for other people too, that would be taking over the product
<janimo> seb128: we should just branch it in LP and go with our own version
<_ion> jdong: I'd recommend against changing the symlink, but patching the package instead. :-) Anyway, probably sudo dpkg-reconfigure dash
<seb128> janimo: that's sort of what we do with adding all those patches to debian/patches directory, no? ;)
<janimo> seb128: this means maintainers took the lock and went away. Not nice
<seb128> janimo: nobody "took the lock"
<janimo> seb128: yes but it's a lot more work
<seb128> janimo: the lock is free if you want to be maintainer
<janimo> seb128: really? hmm whero do I apply for that?
<janimo> I am not joking
<jdong|laptop> _ion: the thing is, a lot of other things are broken by dash, too.... ati, dvd-slideshow, etc etc etc
<seb128> janimo: write the previous maintainer and say you are wanting to take over
<jdong|laptop> _ion: my core duo can take some bash slowness :P
<Kamion> jdong|laptop: it's not that many, and they're all bugs that were present before
<Kamion> they should all be fixed
<janimo> seb128: you see, when the previous mainatiner is MIA that is hard.
<seb128> maybe show a bunch of patches so they can juge if you fit for the job ;)
<Kamion> fixing bashisms isn't hard
<jdong|laptop> Kamion: yes... fix them :)
<jdong|laptop> lol
<Kamion> ha ha ha plonk
<seb128> janimo: he's not MIA, he just has willing to work on the product or is busy
<Kamion> (hint: I've fixed lots)
<seb128> s/willing/no willing
<janimo> seb128: who is he? fejj? jody?
<seb128> janimo: jody
<_ion> * cmdline/apt-get.cc: - always show auto-removable packages and give a hint how to remove them
<_ion> Rules! Thanks mvo. :-)
<jdong|laptop> Kamion: fix them all. I expect my edgy to be rock solid :)
<janimo> seb128: anyway the whole point of bzr is not not get locked upon such bottlenecks
<seb128> janimo: feel free to branch from it
<Kamion> jdong|laptop: then you're crazy ... edgy was never meant to be rock-solid
<janimo> I'll see if I can make a bzr branch then
<jdong|laptop> Kamion: I'm joking :)
<seb128> janimo: then you have to convince people that they should use your brancj
<seb128> branch
<Kamion> yes, it's not that funny I'm afraid
<tkamppeter> Hi,
<Kamion> not given the hours we're all currently doing
<tkamppeter> I have a problem with my Samsung X10plus laptop.
<tkamppeter> I am trying to run the knot-2 live CD, so that I can start with my work here at Ubuntu
<tkamppeter> It seems that there is a problem with the NVidia GeForce FX Go 5200
<tkamppeter> When it tries to switch into the X display the screen stays simply blank.
<jdong|laptop> tkamppeter: does pressing ALT+F7 help?
<Mithrandir> tkamppeter: and the failsafe X option doesn't work?
<tkamppeter> Thank you for the tips, I have currently booted my laptop with Mandriva to run this session.
<tkamppeter> How do I activate the "failsafe X"? Is this the second entry in the main menu of the boot spalsh screen?
<jdong|laptop> yes
<tkamppeter> This second option I tried and it did not help. I did not try Alt+F7 though, when do I have to press Alt+F7
<jdong|laptop> tkamppeter: after the system has "finished booting"
<jdong|laptop> sometimes I find that the livecd finishes booting , but doesn't actually switch into X, rather sitting on an empty console
<tkamppeter> There I Have tried Ctrl+Alt+F1 (F2, F3?) and then I saw a boot sequence in text mode scrolling, with a lot of "chdir: No such file or directory"
<Kamion> that does rather sound like a broken live CD ...
<jdong|laptop> tkamppeter: you might want to do a media check
<jdong|laptop> also from the bootup menu
<Kamion> have you tried the usual things like burning at a lower speed and cleaning the drive lens?
<Kamion> since you're using knot-2, an image problem like that would have come up in testing - chdir failing doesn't sound graphics-card-specific
<Mithrandir> it sounds like it failed to mount the cdrom
<Mithrandir> casper's not always bright enough to see that's what happens and error out.
<janimo> mvo: do I need the changes you uploaded in xubuntu-meta as well?
<tkamppeter> I have successfully booted the CD on another PC (with ATI graphics card), there it worked, but there was no space for installing it.
<_ion> mvo: "The following packages where automatically installed and are no longer required:"
<Kamion> tkamppeter: that would suggest a dodgy drive to me, then
<Kamion> sadly it's a very common problem
<Kamion> we do suggest it to the user in various places, but there are a huge number of different possible failure modes, from the sublime to the ridiculous
<Kamion> we need a try/except around the entire operating system, and we need to put the except bit in code that doesn't come from the CD ;-)
<tkamppeter> I have now tried on a third PC with Intel i810. There it seems really to be the graphics card.
<tkamppeter> Prompts on Ctrl+Alt+F1, F2, F3, but no X screen on F7.
<ogra> Kamion, now thats a cool idea
<Kamion> tkamppeter: try the VESA safe mode on that machine?
<Kamion> might also be worth trying the alternate install CD, and see if it gets any further
<tkamppeter> AFAIR Intel i810 has no VESA framebuffer, but I can try.
<Kamion> sometimes squashfs seems to exacerbate transient CD read errors
<tkamppeter> I am burning the alternate now. I hope it will work.
<tkamppeter> While burning the alternate I am now booting the i810 PC with the VESA safe mode (second choice in boot splash menu).
<tkamppeter> VESA safe mode does not help on the i810 box.
<tkamppeter> What are the differences between the standard and the alternate boot CD?
<Treenaks> doesn't work on my HP NW8240 either
<Kamion> the standard one is one giant live (squashfs/unionfs) filesystem; the alternate one is a pool of .debs with a small installation image
<Kamion> they're about as different as it's possible to get
<Kamion> the alternate image is what you'd probably call the traditional Debian/Ubuntu installer
<ogra> its the edubuntu installer :)
<Treenaks> alternate is what was 'normal' before dapper
<Treenaks> afaik :)
<Kamion> yes
<tkamppeter> So the alternate is the classical way to provide Linux. You boot a CD to directly install.
<Kamion> right
<jdong|laptop> ooh, freenx now does single-window sessions
<jdong|laptop> *thud*
<Kamion> the reason the desktop CD was brought to prominence was that many people wanted us to provide a live CD, and it saves us (Canonical) a considerable amount of money to be able to ship a live CD that can be installed as well
<tkamppeter> This I will not be able to test on the i810 box, as my co-worker needs Mandriva on it.
<tkamppeter> It is like Mandriva One, this is also a live CD which can be installed by an automated copy onto the hard disk. Mandriva 2007 will also be presented this way.
<Kamion> Four hours to feature freeze. Better not need more than about 20 or so installs to get this right, then ...
<tkamppeter> Will come back from another box, so that I can try again with my laptop.
<Kamion> ubiquity 1.1.13. lucky for some
<tkamppeter> Now my laptop has booted finally from the life CD. I have only chosen the safe VESA mode. Probably I did not wait long enough the first time. Thanks for all the tips.
<geser> what are the chances to get an updated krb5 (main) into edgy?
<geser> the current package doesn't contain the latest security fixes?
<geser> s/?//
<Mithrandir> geser: if so, quite big.
<geser> should krb5 1.4.3-9 (current is 1.4.3-5) go in or the latest from debian unstable (1.4.4-1)?
<mdz> doko: ooo 2.0.4 -> please send details via email as usual
<jdong> ooh, the new startup sound is really jungle-ish :)
<LarstiQ> jdong: forest or music genre wise?
<jdong> forest :)
<bluefoxicy> the /exec command in xchat is awesome.
* bluefoxicy gets a terminal to kill broken gnome-panel
<bluefoxicy> damn thing keeps freezing and if there's no icon on the desktop for a terminal or no existing terminal you can't kill it.
<jdong> anyone else get really blurry rendering of OOo?
<jdong> my eyes hurt looking at the menus
<Kamion> ubiquity 1.1.13> and the verdict is ... unlucky
* Kamion tries to unbreak it
<tkamppeter> Finally, I have knot-2 up and running,
<tkamppeter> but already a bug:
<tkamppeter> Thunderbird is in the menu, but not on the system.
<tkamppeter> Are the menu entries coming from each package, or is there one package with all menu entries?
<ivoks> from packages
<ivoks> that's odd
<ivoks> tkamppeter: is there /usr/share/applications/*thunderbird*.desktop
<ivoks> ?
<Keybuk> mjg59: a moment of your time?
<tkamppeter> I installed from the live CD
<jdong> hmm, powernowd is not loading the ondemand governor
<tkamppeter> Now I cannot check any more, as now my "apt-get install mozilla-thunderbird" has finished.
<ivoks> heh
<mjg59> Keybuk: Sure
<mjg59> jdong: Why not?
<jdong> mjg59: I'm trying to figure that out... only performance is loaded
<jdong>  * Starting powernowd...                                                        /etc/init.d/powernowd: line 86: echo: write error: Invalid argument
<jdong> as stated by that ^^
<mjg59> jdong: What hardware?
<jdong> intel core duo
<jdong> speedstep_centrino
<Keybuk> mjg59: clear > /dev/tty1
<Keybuk> mjg59: why? :p
<Keybuk> mjg59: (in the S98usplash script)
<mjg59> Keybuk: Christ knows
<mjg59> Nothing to do with me
<Keybuk> that's why tty1 vanishes if you're running usplash
<mjg59> jdong: Ok, that's a touch concerning
<mjg59> jdong: It means that it's not getting the latency guarantees it wants
<jdong> :( hmm
<jdong> mjg59: is there any way to get that info for debugging purposes?
<mjg59> Probably not trivially
<Tonio_> sladen: ping ?
<Keybuk> mjg59: mind if I make an upload to fix that?
<Keybuk> mjg59: or do you have one planned?
<mjg59> Keybuk: Go ahead
<mjg59> Just check it in afterwards
<Keybuk> yup
<jdong> mjg59: cpufreq-detect.sh does identify speedstep-centrino as the MODULE.
<jdong> hmm
<jdong> mjg59: if I modprobe cpufreq-ondemand then start powernowd, it's happy
<mjg59> Oh
<mjg59> Hm.
<mjg59> So.
<mjg59> powernowd-early is supposed to load that automatically
<jdong> so it would appear powernowd is failing to modprobe the right modules
<jdong> mjg59: powernowd-early is a broken symlink here?
<jdong> hmm
<mjg59> That would probably be your problem, then
<jdong> I don't have powernowd.early
<jdong> what package is that in?
<mjg59> powernowd
<mjg59> If you've ever deleted it, it won't be recreated
<jdong> hmm, I don't think I would've deleted it
<jdong> alright, restored it...
* jdong shrugs and goes back to his usual routine
<jdong> thanks for your help, mjg59 
<jdong> mjg59: now, one of these days you're gonna have to help me get those shiny graphs in g-p-m
<mjg59> Keybuk: Ah - is it possibly so that the tty is clear when usplash flicks back there briefly?
<Keybuk> mjg59: why does usplash flick back there?
<mjg59> Keybuk: Because it needs to restore text mode somewhere
<Keybuk> oh, for the console reset stuff
<Keybuk> why can't it restore text mode on tty8 ?
<mjg59> Actually, it's possible that it does
<mjg59> Hm
<Chipzz> Keybuk: it doesn't restore console 1 for me either; but when I press enter it does
<Keybuk> this isn't "restore text mode" stuff
<mjg59> Oh, maybe it was from back when we didn't run usplash on its own vt
<Chipzz> it's just /etc/issue that's not being shown in my case
<Keybuk> this is "when we stop usplash, run console-screen.sh"
<Keybuk> mjg59: right, so this code does
<Keybuk> - clear tty1
<Keybuk> - quit usplash (which I assume chvt's to tty1)
<Keybuk> - run console-screen.sh
<Keybuk> - clear tty1 (again!)
<Keybuk> - chvt 1
<Keybuk> (the latter if the console is 8)
<mjg59> Right
<mjg59> I'm afraid I never wrote any of that code
<_ion> The _only_ time the usplash splash is visible is during shutdown, from S20sendsigs i think. I wonder how to start debugging this?
<Keybuk> mjg59: sending QUIT to usplash does chvt to 1, yes?
<mjg59> Keybuk: To whatever vt usplash was started from
<Keybuk> mjg59: tty1, as that's the only one that exists in initramfs
<crimsun> iiii
<crimsun> sorry, stuck keyboard
<Seveas> jdub, ping
<sladen> does a chvt 1 while on vt1 cause the wrong set of vt-switching signals to be sent?
<trappist> do my comments on bug 59402 look right to you guys?  if so, is there somebody I should assign it to?
<Ubug2> Malone bug 59402 in libxxf86vm "Cant't build against libxxf86vm-dev" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59402
<Keybuk> sladen: how do you mean?
<sladen> Keybuk: what is the effect of  chvt 1; chvt 1  and svgalib restoring the state of the console "on switch"
<Keybuk> no idea
<Keybuk> by the time the second chvt 1 is run, usplash isn't running
<Keybuk> the issue is more that tty1 is cleared in the first place
<Keybuk> clearing anything important that was on the screen before
<Keybuk> including getty :p
<sladen> Keybuk: so it's doing  clear; chvt 8;  rather than  chvt 8; clear
<Keybuk> eh?
<Keybuk> it's doing exactly what I said
<Keybuk> it clears tty1
<Keybuk> (on a related topic; I still don't understand why console-screen needs to actually, physically, change the vt ... why can't it just reset the vts while usplash is running - but hey-ho)
<Keybuk> probably bugs/features in the vt layer
<Keybuk> or a bad script
<sladen> Keybuk: "it" clears?
<Keybuk> S98usplash
<Keybuk> has "clear > /dev/tty1"
<Keybuk> which is why getty vanishes
<sladen> Keybuk: I suggest you strike down on it with great vengeance
<zyga> mvo: back
<zyga> mvo: I know what is going on but I kind of don't understand why... the template expanding code explodes into infinity (no pun intended)
<LaserJock> is it intentional to have update manager only use archive.u.c?
<zyga> mvo: there is also a pretty bad problem of $(ls) treated like variable substitution
<mvo> zyga: hm ...
<mvo> LaserJock: what do you mean? 
<zyga> mvo: I can reproduce the crash using one liner, just a sec
<mvo> zyga: ok
<LaserJock> mvo: sorry, that wasn't very clear. I'm using update-manager to upgrade to edgy
<LaserJock> mvo: it appears as if it is replacing any mirror with archive.u.c in the sources.list
<mvo> LaserJock: that would be a bug then, it really should not touch the mirror url
<mvo> just rewrite the distribution section
<LaserJock> it leaves the components
<LaserJock> it just adds a new line with archive.u.c
<zyga> (that one liner is a particularly long one *g*)
<zyga> 1.9MB long line really hogs vim...
<lemsx1> zyga: try vile
<zyga> lemsx1: gosh, that's emacs?
<zyga> well anything that works ...
<lemsx1> zyga: nah
<lemsx1> zyga: vi for big files
<zyga> woooah!!!
<zyga> it's just fast!
<lemsx1> vile?
<zyga> yeah
<zyga> hmm, no insert mode/
<Kamion> turn off syntax highlighting and vim should behave better
<lemsx1> good to know. i never use it myself :-P
<lemsx1> vile is just like vi
<zyga> oh, true
<lemsx1> you might want to use vim in read-only mode or something... like: view foo.txt
<Kamion> that won't particularly help
<Kamion> IME
<lemsx1> Kamion: i wonder if there is an easy way to tell vim to turn off all extra stuff
<Kamion> use vim-tiny and run it as vi ...
<Kamion> or vi -C
<Kamion> hmm, no
<lemsx1> Kamion: ah, removing ~/.vimrc and launching vim as vi: ln -s /usr/bin/vim /usr/bin/vi ... or so
<zyga> vim in read only mode still dies on that file
<zyga> but vile is quite usable
<Kamion> try 'view -u NONE'
<lemsx1> zyga: vim should do it as well, but the highlighting, syntax detect, and completion really kills you at times
<Kamion> behaves much better on big files IME
<zyga> I kind of know what crashes in my code now, somehow I the list of iterable variables expanded and expanded into one *BIG* list of variables, I don't know how it did that on small postinst file
<lemsx1> Kamion: in vi mode, yes. but in vim/gvim it's very slow
<zyga> OTOH anyone who wrote mailman.postinst should DIE ;-)
<Kamion> lemsx1: works fine for me in vim mode
<Kamion> (I use vim, not vim-tiny, so I don't really *have* a vi mode)
<lemsx1> zyga: lol
<Kamion> -u NONE turns off all initialisations, including syntax highlighting etc.
<lemsx1> Kamion: i have a spiffy .vimrc/.vim/.gvimrc setup... sometimes i hit one of those huge (gigabytes in size) files who really mess up vim
<lemsx1> Kamion: any XML file over 20mb is a killer for me
<lemsx1> somebody should write a Howto in howtoforge on the "perfect vim setup" :-P
<zyga> lemsx1: nah, ubuntu should ship one :)
<lemsx1> zyga: you got a point there... but, vim will read your own $HOME settings after the system-wide ones... 
<zyga> lemsx1: so/
<zyga> there is no .vimrc in skel
<_ion> I'm sure ubuntu wouldn't ship my perfect vim setup, which e.g. contains "set guioptions=Lacir" to hide the menubar and the toolbar in gvim. :-)
<lemsx1> zyga: it will screw up things
<zyga> lemsx1: anyone who uses vim knows how to get past that ;-)
<lemsx1> zyga: yeah, but i mean people who already customize their $HOMEs (or use NFS-mounted home's)
<zyga> I'm for removing vim/emacs off the CD for that case :)
<zyga> they are not user tools in any way
<Kamion> emacs is not on the CD
<jdong_> hmm, how does g-p-m determine whether or not to hide its power graphs? is that a hal thing?
<lemsx1> zyga: no. that's not true
<Kamion> only vim-tiny is on the CD, and I will vehemently oppose removing that
<Kamion> the small amount of space it takes up is well worth avoiding the WTF factor for any long-time Unix user upon finding that there's no vi installed
<lemsx1> zyga: you need vi in all CDs no matter what. and vim is the best vi implementation on the planet ;-)
<zyga> lemsx1: and you need them for what?
<jdong_>   system.formfactor = 'unknown'  (string)
<jdong_> hmm :(
<lemsx1> zyga: in UNIX all config files are plain text
<zyga> lemsx1: just think - anyone can install vim, no user uses vim (where user = grandma user)
<lemsx1> zyga: adding users is one
<zyga> lemsx1: we already ship a good number of editors by default
<zyga> lemsx1: I am only referring to the default ubuntu desktop install
<lemsx1> zyga: i know newbies and what have you, are a totally different thing... vi takes like 1mb of space
<zyga> OTOH ubuntu should be added to all dictionaries :P
<jdong_> how do I force hal to believe I have a laptop??
<Amaranth> zyga: Removing vi(m) is blasphemous
<zyga> lemsx1: hmm, I are oyu sure?
<zyga> Amaranth: not removing, moving off the precious CD to the internet archive
<lemsx1> jdong_: install laptop-mode scripts ?
<Amaranth> zyga: That's removing from the CD
<Amaranth> from the default install, rather
<zyga> lemsx1: apt-cache show vim | grep Size
<zyga> hmm/
<Amaranth> 700k
<jdong_> lemsx1: does that actually work?
<lemsx1> zyga: think networking and you will understand why vi can't be removed. transfering data on slow links is painful and remote management on somebody else's system is done usually on a console running some text editor that's lite
<jdong_> lemsx1:   system.formfactor = 'unknown'  (string)
<lemsx1> zyga: i was refering to just the app
<lemsx1> zyga: $> du -s /usr/bin/vim.tiny 
<lemsx1> 868K    /usr/bin/vim.tiny
<Amaranth> vim-tiny is 470750 package size
<lemsx1> jdong_: i use the laptop mode scripts. they work for me
<zyga> lemsx1: you have nano for remote access, and if you have remote access you might as well just install vim-tiny :)
<jdong_> lemonade: hal doesn't believe my laptop is a laptop, so g-p-m doesn't show the discharge graphs and such
<Amaranth> so we're talking about 460k
<jdong_> err lemsx1 
<lemsx1> Amaranth: the package is compressed right. gzip'd
<zyga> Amaranth: hmm, true
<Amaranth> lemsx1: Size is the package size
<lemsx1> zyga: and you then will remember to type nano? vi is EVERYWHERE. i'm a solaris admin as well
<zyga> I still kind-of think that it's like build-essential, it should not be on a desktop CD
<zyga> lemsx1: I'm not telling anyone to remove vi. altogether, I'm just suggesting it's not needed on the desktop CD
<Amaranth> zyga: You risk pissing off/confusing a lot of people to save 460k
<LaserJock> mvo: bug #59410
<Ubugtu> Malone bug 59410 in update-manager "[dist-upgrader]  new a.u.c deb line in sources.list" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59410
<lemsx1> Amaranth: package size after install? isn't that "installed size"
<zyga> Amaranth: hmm, maybe but with command-not-found it's not that much of an issue really :D
<mvo> LaserJock: thanks!
<lemsx1> Amaranth: Installed-Size: 1392
<Amaranth> oh yeah, installed size is what we want since it's the desktop cd
<Amaranth> although even then it's squashfs compressed
<Amaranth> lemsx1: vim-tiny is what you want to look at
<lemsx1> zyga: the desktop CD is "live" right? and it also allows you to install the OS. so, if i use it to troubleshoot a system, you expect me to remember to type all known text editors until i hit one. or just use "vi" ?
<lemsx1> zyga: there are other ways to save space on the CD... vi is 1.x mb...
<trappist> I sure don't want to be the first *nix in history to not be able to find room for vi
<zyga> lemsx1: to troubleshoot anything use the alternate CD IMHO that's more appropriate
<zyga> trappist: again, I'm only for removing them from the default install - nobody is hurting vi :)
<Amaranth> lemsx1: it's 940k
<Amaranth> lemsx1: vim-tiny is what's installed right now
<lemsx1> zyga: well. let's just say that you win. we won't change the distrib today anyway
<Amaranth> you want to look at it
<trappist> zyga: vi is probably the 1st thing I use on a default install, to edit sources.list
<zyga> lemsx1: that's okay, there is a spec about that, might just as well happen for edgy+1 :)
<Amaranth> 940k before it's compressed in the squashfs (or whatever is used)
<lemsx1> trappist: me too, but not just that, /etc/network/interfaces and what have you
<zyga> trappist: me too
<zyga> trappist: but you can, on a default install type apt-get install vim-$flavor (and you probably do that by default too)
<zyga> right?
<lemsx1> zyga: i betcha that when vi gets removed from the desktop CD there will be somebody offering their own CDs "done right" which includes vi
<trappist> I do
<lemsx1> zyga: if you have networking, yes
<zyga> lemsx1: I say, let them :)
<zyga> I'm sure slashdot and digg will make it front page stories too ;)
<lemsx1> zyga: if you are in an enterprise, you might not have that choice (firewalls)
<trappist> but man, if there's one thing that's always been guaranteed to be on any linux/unix box, it's vi
<zyga> lemsx1: if you don't you can use nano, it's there too :)
<Amaranth> trappist: exactly
<zyga> oh guys - but first off 
<zyga> there is no remote access without ssh-server, we don't ship it installed by default
<lemsx1> zyga: instead of Nano it should be evi (vim in easy mode)
<Amaranth> i'm not talking about remote access
<zyga> any server will have vim/vi on the cd and in default install
<lemsx1> zyga: don't see the point on changing vim with anything else
<zyga> IMHO one trivial text mode editor is enough, how many we put today? 5 or something?
<Amaranth> i'm talking about 'vi' existing on every Unix/Linux in existance
<LarstiQ> zyga: fsvo "use nano"
<trappist> not all desktop users are gedit/kate people.  I don't want to alienate the people who have come to accept the availability of vi as a matter of faith.
<zyga> Amaranth: that's true if you notice that most of those installations are not desktop systems now, think different as some company used to say
<Amaranth> zyga: Does that company include 'vi' on their systems? :)
<zyga> Amaranth: yeah, but they ship them on DVD's you know ;-)
<zyga> :D
<trappist> I've used *floppy* distros that saw fit to include at least ye olde vi
<zyga> and besides, they do not have apt-get like system that would get you one with one line of shell
<LarstiQ> if your sources.list is working
<zyga> trappist: it's not about getting every last bit of space, think about purpose of vim on the desktop - I see none :)
* LarstiQ has been stuck without a way to update anything for several days
<zyga> LarstiQ: again, there are many editors in the default install that just work and are far easier to save and quit
<LarstiQ> zyga: on a totally installed system? It's the only editor a lot of people use, including the desktop
<trappist> zyga: see my previous comment - not all desktop users are consolephobes.  I think it would be a mistake to alienate the old-school linux-desktop console users
<zyga> LarstiQ: stop thinking about people = ubuntu developers, you are wrong in that assumption
<trappist> LarstiQ: +1
<LarstiQ> zyga: I'm not even an ubuntu developer
<trappist> zyga: people = windows users is also a bad assumption
* pitti thinks that we should ship at least nvi
<pitti> having *any* vi-ish editor available is really a must
<zyga> trappist: both are wrong, but statistics wins over my case
<lemsx1> zyga: don't be a hater. if you don't want to use vi, use nano. but let vi exist in the CD for the rest of us
<LarstiQ> pitti: agreed, I can live with pure vi
<zyga> lemsx1: don't get me wrong - I love vim
<pitti> but vim users are generally the kind of people who know how to install the fully version, I'd assume
<zyga> guys guys
<zyga> pitti: +1
<zyga> 1) I love vim, i never use nano
<trappist> zyga: 90% of people probably wouldn't notice if we dropped vim, but the 10% who would, would be seriously unimpressed, and potential contributors are kind of concentrated into that 10%
* pitti solely uses vim everywhere, too, so I'm not speaking as a vim enemy either
<zyga> 2) space is not that important, true but it might be someday or when we want to make a sub 700MB CD
<zyga> 3) there is *no reason* to ship half a dozen of text only editors for a desktop CD
<lemsx1> zyga: then make people vote
<LarstiQ> while I agree on the half dozen part, I see no connection between 'text only' and desktop
<zyga> trappist: I agree, so we should do this in a way that they understand is correct
<lemsx1> zyga: there is no way nano would win over vi
<LarstiQ> or rather, reason not to
<zyga> LarstiQ: the connection is: there is at least (not to mention another half a dozen probably) graphical text editors available by default that can be used instead, I'm not alientating console or anything
<LarstiQ> zyga: are any of those vi?
<zyga> lemsx1: nano is just an example: it could be vi but then let's drop nano
<zyga> (nano is better for users that *need* to use the console but never used vi to edit their broken /etc/X11/xorg.conf 
<lemsx1> zyga: now you are talking
<zyga> but my claim that nano is better for that case still holds
<lemsx1> zyga: there is easy vim for that
<zyga> lemsx1: how is it called?
<lemsx1> zyga: if symlink as evi, it just work like nano
<zyga> oh :)
<zyga> funny - I don't have evi
<lemsx1> zyga: evim in the current ubuntu setup
<zyga> evim :)
<zyga> right
<lemsx1> and you don't need to know anything about edit mode visual mode and whatever
<zyga> looks decent :)
<LarstiQ> funny, I don't know how to exit evi :)
<zyga> hehehe
<lemsx1> lol
<zyga> me either :D
<lemsx1> no ESC for you
<zyga> fortunatly that was gevim :D
<trappist> yeah, I think evi kinda defeats the purpose of keeping vi
<zyga> so I clicked quit
<zyga> boy that was odd
<zyga> trappist: +1
<LarstiQ> trappist: it's just argv[0] 
<lemsx1> zyga: same here. it opens in gevim
<zyga> I'm glad I have shown you my point of view :)
<_ion> ^O:q<enter> seems to quit it. :-)
<jdong> there. hal is happily forced into believing that I have a laptop. :)
<LarstiQ> _ion: thanks!
<trappist> I don't know if we have anything besides nano and vim on the cd, but I think we need nano for new users and vim for old schoolers, neither of whom we want to alienate.  I think they're both crucial.
<_ion> (Every vim user should learn ^O)
<lemsx1> _ion: ah, i didn't know about ^O
<bluefoxicy> weird
<bluefoxicy> when I rebooted the splash screen didn't print anything about what tasks were starting
<zyga> _ion: I didn't knew that either
* lemsx1 :q's the day
<lemsx1> ttyt guys. nice chat!
<zyga> (vim is an amazing editor, every day you learn something new)
<bluefoxicy> also the crash reporter's dialog-to-the-face is starting to seriously piss me off.
<_ion> Also :g and :norm
<bluefoxicy> it bitches about every little thing, and then keeps saying whatever the first thing that ever crashed was has died
<jdong> bluefoxicy: likewise; here it always thinks gaim has crashed for some reason
<jdong> bluefoxicy: it tells me about it on every login
<bluefoxicy> jdong:  I spewed a half a dozen specs based on pitti's crash reporter, one of them mentioned something about throwing dialogs in users' faces being a bad idea
<bluefoxicy> I think I said the user would just click through
<jdong> yeah, no kidding.... it's just plain annoying
<bluefoxicy> I didn't predict that it would aggitate the hell out of me/anyone
<jdong> like the windows XP thing
* _ion would like a systray item. Clicking it would show the dialog that currently opens automatically.
<bluefoxicy> the XP one isn't agitating
<bluefoxicy> amusingly enough it doesn't come back on every boot or every illicit program close and throw the same crap in your face.
<jdong> well, that's a bug I suppose :)
<_ion> s/systray/notification area/ ;-)
<jdong> I hope
<jdong> I pray
<zyga> DAMN is the new artwork pretty! :)
<jdong> new sounds are sweet, too
<zyga> I broke my sound card :/
<zyga> anyway
<zyga> could we make the gdm background remain there untill the panel shows up?
<bluefoxicy> jdong: https://wiki.ubuntu.com/AutomatedProblemReportsNotification in case you're interested
<zyga> I'm not talking about fading the background or anything but just waiting for the panel to show up so that the whole process is more fluid
<bluefoxicy> jdong:  not that I'd ever write a single line of code in that direction.
<Trewas> btw will edgy have networkmanager by default, or what is used for managing network connections?
* bluefoxicy is more of a security guy but he's strayed the path as of late; he's been looking into performance-increasing compiler/linker hacks and rewriting the memory allocator, as well as compressed memory
<bluefoxicy> https://features.launchpad.net/distros/ubuntu/+spec/compressed-memory I'm hoping this is stable by Edgy+1 because I freaking love it (I used the 2.4 one back in the day)
<bluefoxicy> anyway *does other stuff*
<_ion> bluefoxicy: Hmm, a very interesting concept.
<bluefoxicy> _ion:  memory compression?  It's old, but good.
<Keybuk> tsk
<Keybuk> what's wrong with this?
<Keybuk> pid = fork ();
<Keybuk> if (fork > 0)
<Keybuk>     exit (0);
<bluefoxicy> Keybuk:  fork?  what the hell?
<bluefoxicy> Keybuk:  s/if (fork/if (pid/
<Keybuk> yes :p
* Keybuk gives himself the "duh" award
<thom> heh
<bluefoxicy> (hint:  you are checking if fork()'s entry point is at an address > NULL)
<thom> maybe testing the correct variables would help? :-P
<bluefoxicy> Keybuk:  coding while drunk/tired/surrounded by real life cute guys that actually aren't straight/etc?
<Keybuk> coding until a deadline
<Keybuk> sadly David's buggered off back to work
<bluefoxicy> ah, coding under pressure.
<_ion> Something upstart-related, btw?
<Keybuk> _ion: nah, just testing why usplash fucks the console
<bluefoxicy> Keybuk: perhaps because its condoms are reaching their expiration date?
<cbx33> hey seb128 
<seb128> hi
<cbx33> did you get a chance to see my pessulus patch?
<Keybuk> bluefoxicy: heh, never use them myself ... and soooo off-topic :p
<bluefoxicy> you missed the joke I see :P
<Keybuk> yes, I did
<seb128> cbx33: not yet
<sladen> Keybuk: bugger off as in ->USA ?
<cbx33> seb128, think it'll make FF?
<sladen> Keybuk: buggered
<Keybuk> sladen: hmm?
<bluefoxicy> Keybuk: the latex eventually breaks down and they expire; hence occasionally the issue of ... finding a way to use the rest of the box up quickly ... comes up :P
<seb128> cbx33: if people stopping pinging me on IRC every 5s maybe :p
<cbx33> hahah
<sladen> Keybuk: "disappeared off to work" == "flown to the US"?
<cbx33> sorry
<seb128> np
<bluefoxicy> anyway
* cbx33 goes back to work
<seb128> I'll have a look on it next
<cbx33> ty
<Keybuk> sladen: no, just back home to the Cotswolds ?
<seb128> but I've been very busy this week
<cbx33> I know
<seb128> with GNOME 2.16, feature freeze, etc
<cbx33> which is why I havn't buged you
<cbx33> this is just a curious...do you think it'll get in
<cbx33> not a pressue push :p
<cbx33> I don;t do those
<cbx33> ;)
<seb128> ok, so I think there will be no issue if the patch is correct ;)
<seb128> :)
<cbx33> ;)
<robertj_> should we add Trashes to the places side-bar in Nautilus?
<robertj_> (or I guess just Trash:/// since it encompases all .Trash entries now)
<seb128> robertj_: no
<seb128> we already have it on the panel
<seb128> and it's easy to delete from the menu or the keyboard
<seb128> no need to clutter places too
<robertj_> seb128: I was viewing the applet as the clutter :)
* Kamion wonders how to migrate from console-tools to console-setup if X isn't configured
<robertj_> because Nautilus is only on-screen while I'm managing files
<Kamion> only way I can see to do it is to hope that debian-installer/keymap is there, I think
<seb128> robertj_: nautilus manages your desktop too
<seb128> robertj_: and some people use a different sidebar or the spatial mode
<robertj_> seb128: spatial is more problematic though
<seb128> ?
<robertj_> seb128: removing trash applet for spatial users
<seb128> robertj_: why it's not for people using a different sidebar to browser mode?
<robertj_> seb128: because then puting it in the sidebar is an obvious solution
<seb128> places sidebar
<robertj_> well indeed, I suppose it should be in Tree as well..but still
<seb128> what is your issue with the very few pixel it takes on the panel?
<robertj_> seb128: im a one-panel heretic
<robertj_> seb128: recent convert though, within 7 days every screen I had in the house went from 4x3 to 16x9
<robertj_> and then I decided I might should fiddle with my layout a bit
<seb128> adding a bookmark to trash:/// is easy enough if you customize your whole desktop anyway
* _ion uses a single panel, it's about 60% of the screen's width, and still there's enough space in it for the trash applet. :-)
#ubuntu-devel 2006-09-08
<robertj_> seb128: I rather dislike panel-do-dads in general though
* robertj_ glares at ekiga
* robertj_ also has a general disdain for Trash
<Kamion> Keybuk: so what's usplash doing with console-screen.sh?
<Kamion> Keybuk: I ask because, err, I'm kind of superseding it
<Keybuk> Kamion: it runs it to make sure that the console state is set (ie all the utf-8 stuff)
<Keybuk> because that didn't work while usplash was running
<Keybuk> probably because the script was buggy
<sladen> echoing escape codes onto a vt in graphics mode cause corruption or somesuch
<Kamion> ok, so console-setup should be able to do that too
<Kamion> could you please check if setupcon is on $PATH, and if so call it instead?
<Kamion> dear god I have a lot of patches to send to Anton once the code-to-a-deadline period has passed
<mvo> console-screen.sh is going away? great
<Kamion> it may not actually go away, but I'm just changing it now to exit 0 if setupcon is present
<Kamion> because setupcon does the same job, and is called by a console-setup init script
<bluefoxicy> AGHHELP
<Kamion> well ... roughly the same job. I think a few edge cases may still be missing
* bluefoxicy kills 50,000 "epiphany has crashed" dialogs
<Kamion> oh, hey, usplash is bzr-maintained, I can just do it myself
<mjg59> Kamion: Feel free
<mjg59> I'm trying to track down suspend regressions
<Kamion> ta
<Keybuk> Kamion: does setupcon change vts at all?
* Hobbsee tries to remember if her suspend is working now.
<Hobbsee> hey dholbach 
<AlinuxOS> mjg59, hello, here ?
<Kamion> Keybuk: yes
<dholbach> hi Hobbsee
<AlinuxOS> mjg59, can I disturb you ?
<Kamion> Keybuk: actually it's the tools it calls that do it
<Kamion> Keybuk: AFAIK setting the font involves a vt switch to get the ioctls to work right
<pitti> slomo: do you particularly care for wireshark? if so, do you fancy merging it again to kill two tons of vulnerabilities?
<mvo> IIRC it was not possible to set the fonts while in graphics mode
<Hobbsee> pitti: i'll do it, it seems to be on my list
<Kamion> Keybuk: I could be wrong about that, but all I know is that neither console-screen.sh nor setupcon change VT directly - it's one of the tools they call
<Keybuk> Kamion: or the author of the code that sets the font thought it might require a vt switch
<Keybuk> and if one rewrote that code, it might not :-/
<Keybuk> and, frankly, if there's an ioctl that cares that a tty is the active one in order to change it, we can fix the kernel <g>
<Kamion> I certainly wouldn't complain - just don't know exactly which bit of code it is
<Keybuk> but short-term (in the next 5 mins), I would say the usplash init script should be changed to call your new script
<Kamion> exactly what I'm doing
<Keybuk> good man
<AlinuxOS> mjg59, https://launchpad.net/distros/ubuntu/+source/ttf-bpg-georgian-fonts/+bug/55966 finally a solution found! now fonts have perfect outline in user and root mode. is it possible to have the same update for dapper and edgy and debian unstable in the same time ? Thank You again.
<Ubugtu> Malone bug 55966 in ttf-bpg-georgian-fonts "ttf-bpg-georgian-fonts.conf problem." [Untriaged,Confirmed]  
<pitti> Hobbsee: yay
<AlinuxOS> pitti, hello ;) nad have a nice hacking night :) or maybe simply good night.
<pitti> hi AlinuxOS 
<pitti> AlinuxOS: late night meeting today :)
<Hobbsee> pitti: seeing as it's got my name listed against it, perhaps i'd better, you know :P
* AlinuxOS is very happy couse finally a solution for georgian fonts problem exist!
<Kamion> Keybuk: did you forget to check in usplash-testcard.c?
<sladen> to remove the brandingness?
<Keybuk> Kamion: that's generated
<Kamion> oh, it showed up in debdiff
<Kamion> as being in the 0.4-19 source
<Keybuk> odd
<Kamion> I guess somebody forgot to clean?
<AlinuxOS> pitti, I'm in Italy now...I was in Karlsruhe for a month...It was really great...now a little bit sad. (sorry for OT)
* Keybuk uses dpkg-buildpackage
<Keybuk> I guess clean isn't perfect
<Kamion> Keybuk: I don't see where it's generated?
<Keybuk> Kamion: heh, maybe it's just cruft in my bzr directory :p
<Kamion> but the Makefile mentions it
<Kamion> ./Makefile:29:libusplash_OBJECTS = libusplash.o usplash-testcard.o usplash-testcard-theme.o $(usplash_BACKEND) bogl/helvB10.o
<Keybuk> Kamion: weird
<Keybuk> Kamion: it's generated by the .png.c rule
<Kamion> oh, right, yeah - just found that
<Kamion> right, good, signing and uploading
<dholbach> if launchpad says there was a "chroot problem" - will it be automatically retried?
<pitti> Mithrandir: l-c-w-a-y-g?
<Mithrandir> pitti: live-cd-write-as-you-go
<pitti> Mithrandir: thanks *hug*
<madduck> q/l
<madduck> sorry
<administrator> Kamion: may i have a word with you in pm?
<Kamion> administrator: sure, although I'm in a meeting so will not be paying full attention I'm afraid
<administrator> Kamion: oh ok, when is the meeting over?
<Kamion> administrator: half an hour to an hour, but then I'm going straight to sleep
<Kamion> let me know whatever it is now and I'll reply when I get a chance
<administrator> alright
<ogra_> pitti, the student-control-panel MIR is missing, but its quite big so i didnt assume it will hit main before FF
<pitti> ogra_: if you need it, I can do it tomorrow, but I didn't hear any pokes about it so far, so I just postponed MIR in favor of some high urgency stuff
<ogra_> pitti, it would rock if it could go on the CD 
<ogra_> (so to main)
<ogra_> but i didnt count on it anymore ... anyway, so do as you have time 
<pitti> ogra_: then it'll take a while; really, you have to urge me according to the goals
<ogra_> pitti, my problem is that i have an implemented spec that has never got the final approval by mdz ...
<pitti> uh
<ogra_> well, cbx33 jumped on it and implemented it ...
<ogra_> i had already given it up since mdz said i should give it the lowes prio
<mdz> pitti,ogra_: edgy targets get priority
<ogra_> SCP was an edgy target initially ...
<ogra_> it slipped down the list with every review ...
<ogra_> i dont mind if SCP stays in universe for edgy and moves to main in edgy+1 ... its just that its really done so pete would deserve that it ends up on the CD
<ogra_> he has put plenty of nightshifts into it
<ogra_> (aside from making new ubuntu sounds and edubuntu artwork and patching pessulus etc ... he's a hard worker)
<pitti> ogra_: ok, I'll try to process MIR tomorrow
<ogra_> that will make him very happy :)
<ogra_> LaserJock, no upload to universe yet ? 
<LaserJock> it is
<LaserJock> sitting in NEW
<ogra_> ah cool !
<ogra_> :))
<ogra_> edubuntu edgy will become sooo sexy :D
<seb128> doko: that gnome-vfs changes has been made weeks ago, nothing to do with "our gnome law"
<seb128> doko: and it doesn't break any app afaik
<seb128> doko: a meeting is not the place to raise an issue for the first time
<doko> seb128: it wouldn't be a problem if somebody of the desktop team would check OOo and gnome after gnome upgrades
<seb128> doko: we can't check every single function of every single app
<seb128> I did test GNOME
<seb128> and lot of people did
<seb128> and nobody opened a bug in weeks now
<dholbach> it's strange that a rebuild doesn't seem to help
<dholbach> doko: does the backtrace indicate gnomevfs problems?
<pitti> the linker does not pick up libbonobo then?
<Keybuk> thom: hmm
<doko> dholbach: the OOo file selectors point into that direction
<doko> seb128: no, I just ask to start OOo *once* and edit a document / write it.
<seb128> doko: openoffice is broken for weeks and you just noticed today?
<bluefoxicy> gah.
<bluefoxicy> I can't get anything to not crash if I try to preload libhoard.
<dholbach> seb128: no, it's broken for a while and it's known
* bluefoxicy is exploring use of non-glibc allocators because of bloat; a couple sources seem to confirm that ptmalloc likes to allocate a lot more memory than is actually used
<dholbach> seb128: it works with the std fileselector, but not with the gnome one
<seb128> dholbach: and why it has not been mentionned before?
<doko> seb128: no, it's long known, but the recent discussion on debian-release pointed into that direction
<seb128> doko: I'm not on that chan, list, or whatever media the discussion was on
<pitti> mvo: I just discovered the software sources GUI and about three bugs :)
<doko> seb128: but apparently you did know about this issue
<seb128> doko: no
<seb128> doko: I didn't know that's an issue
<mvo> pitti: *ick* can you file bugs about them please? 
<pitti> mvo: I wil
<pitti> l
<seb128> I know they moved symbols from gnome-vfs to libbonobo
<doko> <seb128> doko: it's a discutable "ABI change" then ;)
<doko> <mdz> seb128: are you and dholbach the only ones forwarding bugs upstream, or do others help as well?
<doko> <seb128> doko: they moved some function from gnome-vfs to libbonobo which the linux linker handle fine
<seb128> and that the linker manages fine
<seb128> yeah
<seb128> it's a "non issue" to upstream and to me
<seb128> since it works fine
<doko> even when dlopen'ing the libraries?
<Keybuk> seb128: does gnome-vfs DT_NEEDED libbonobo?
<Keybuk> or does it rely on the app doing that?
<seb128> Keybuk: rely on app
<Keybuk> then that's an ABI change
<Keybuk> and is broken
<Keybuk> you should add a DT_NEEDED otherwise you just dropped symbols
<dholbach> hum
<dholbach> doko: on which arch is it broken?
<seb128> Keybuk: apps linked with gnome-vfs were linked with libbonobo too so upstream argue that's not a breakage
<Keybuk> seb128: clearly that is not true
<Keybuk> as gnome-vfs does not link to libbonobo
<seb128> no, but it doesn't use it neither
<seb128> it uses dbus now
<Keybuk> if it doesn't use it, how come openoffice is having problems?
<seb128> I don't know
<seb128> we are making conjoncture that's due to that move
<Keybuk> doko: what bonobo symbols does openoffice use from gnome-vfs ?
<seb128> I've no detail about the bug
<Keybuk> maybe it just needs to be rebuilt or something :p
<dholbach> doko: saving works on amd64 with gnome fileselector now
<doko> Keybuk: I didn't check yet. "just needs to be rebuilt" points to some problems.
<dholbach> it's *_mime_* API that was moved
<seb128> dholbach: no, it's *bonobo*mime*
<Kamion> mdz: so, we never turned on universe and multiverse by default for edgy
<Keybuk> Kamion: "turned on" ?
<Kamion> there's a spec about it
<Kamion> turning them on by default
<ogra_> eek
<mdz> https://launchpad.net/distros/ubuntu/+spec/enabling-additional-components
<Riddell> yes please
<mdz> mvo: ^^ ?
<Kamion> I had a look at the state of the package management system recently
<Kamion> g-a-i seemed fine, the work there had been done
<Kamion> synaptic hadn't
<Kamion> software-properties hadn't
<mvo> mdz: that one is still in review 
<mdz> mvo: I emailed about it a few weeks ago
<mdz> because it is a dependency of easy-codec-installation
<Kamion> if synaptic and software-properties could relatively easily be changed, it's a trivial switch to throw in the installer
<mdz> not that I'll finish that tonight
<Kamion> although it would slow down the apt-get update stage somewhat
<mvo> mdz: I would have to look that up, but IIRC I updated it and asked for review 
<Kamion> so I wanted to know whether I should be throwing that switch
<mvo> I noted that in the last two status update meetings that I'm blocked on this
<mdz> mvo: I think sabdfl expressed some concern about the UI and I asked him for feedback
<mdz> hmm, yes, I did
<mdz> I didn't get a reply
<mvo> mdz: was that after my comment in the whiteboard: "2006-07-05
<mvo> Adressed the comments by the various reviewers and added them to the spec itself - please review"
<mvo> ?
<mvo> mdz: it seems that its the synaptic stuff that is missing. I can have a look tomorrow and try to estimate how long it will take. I could get it done before the weekend I think
<mvo> mdz: I'm off to bed now, please let me know what you think about this tomorrow
<ogra> mdz, i have two fixes for dapper i'd like to land soon for ltsp, one is the fix at the end of #39294:and the other is a fx for g-p-m that hides the hibernate action on logout http://people.ubuntu.com/~ogra/70-suppress-pm-actions-on-ltsp.patch
<LaserJock> oh man, synaptic repo stuff got really cool in edgy
<Kamion> mdz: is the intent to switch to linux-generic as the default install kernel?
<Kamion> though that would effectively desupport 486 systems except for netboot and DVD (ha ha)
<Kamion> mdz: perhaps linux-generic just on the desktop CD and leave -386 on the alternate?
<Kamion> mdz: of course, the trouble with *that* approach would be that desktop would have to be different between the desktop and alternate CDs in order to account for needing different linux-headers packages
<Kamion> so I don't know
<Kamion> I'm moving desktop to linux-headers-386 for now, since that's the kernel provided on the CDs
<Kamion> (as it happened we had linux-headers-686 in desktop and linux-headers-386 in ship, apparently by mistake, so that's a megabyte or so reclaimed from the i386 CD)
<jdub> Seveas: pong
<Kamion> oh, we ship both kernels on the alternate CD; hmm; I'll just match everything up
<mdz> Kamion: linux-generic on desktop and -386 on alternate was the plan
<mdz> Kamion: hadn't thought about the headers problem
<Hobbsee> stupid question here, but why not use the linux-headers-generic, as you have with the rest of them?
<Hobbsee> ie, -image and restricted modules and all that?
<desrt> upstart is acting really goofy....
<Kamion> Hobbsee: -generic is basically -586
<Kamion> it's not an "all the headers" metapackage
<Hobbsee> well, yeah, of course.  so if you're only shipping -586, surely you only need the headers for -586?
<Kamion> ok, that unicode-data upload should untangle the console-data FTBFS on i386
<Hobbsee> like i say, i think i'm missing something really stupidly obvious here
<Kamion> at least the build-dep part; I'll upload tomorrow for the rest
<desrt> bah
<desrt> upstart won't do anything but boot into singleuser mode anymore :(
<Kamion> Hobbsee: sure, you're right, but if we wanted to ship -generic on the desktop CD and -386 on the alternate CD, we run into the problem that the definition of the desktop seed is common to both desktop CD and alternate CD
<Hobbsee> Kamion: point.  then stupid question number 2 is why you want to ship -386 at all then.
<Kamion> Hobbsee: the only way to resolve that is to have both -386 and -generic in desktop, which is not really desirable due to bloat
<desrt> and it's a terribly fucked single user mode where backspace puts a ^? ^H puts ^H and enter puts ^M and ^J puts ^J
<Hobbsee> yes of course
<Kamion> Hobbsee: because it's still actually possible and occasionally useful to install 486-class systems with Ubuntu, believe it or not; and also I believe there's still some legacy hardware around that blows up with a 586-class kernel
<Kamion> I'm not saying 486 should continue to be the default, but I do think it needs to be possible somehow
<Kamion> maybe we should make 386 an option on the install CD but not the default, and not ship the headers for it
<Hobbsee> Kamion: ah, ouch.  right.
<Kamion> note that the installer itself uses the -386 kernel and modules, so you could end up in a situation where you could install but not boot into the resulting system, if you were very unlucky ...
<Hobbsee> right.
<Hobbsee> heh.  that sounds like our car licencing.
<Kamion> Hobbsee: a further problem is that 486-class systems tend not to have enough hardware to deal with the more advanced installation methods
<Kamion> they often don't have PXE-capable network cards, they very likely don't have DVD drives, etc.
<Hobbsee> Kamion: gotcha, fair enough.  stupid question number3 is why ship the 586 class kernel at all, but you dont have to answer that if you dont feel like
<HrdwrBoB> 486 class systems are lucky to have an IDE CDROM
* Hobbsee suspect she's tried enough of your patience today with idiot questions
<Kamion> sorry, I'm conflating 386 and 486 all over the place here, which is because our C++ libraries require 486 anyway so 386 is basically dead in the water
<Kamion> Hobbsee: we get a lot of complaints from optimisation-lovers if we don't :-)
<Hobbsee> Kamion: point.
<robertj_> HrdwrBoB: I don't know about lucky
<Kamion> it apparently is a bit of a speed gain
<robertj_> HrdwrBoB: I'd say most 486s had CDRoms
<robertj_> HrdwrBoB: the DX/66 had a very long life
<Hobbsee> Kamion: i thought the straight dope thread on ubuntu-devel had proved that that wasnt the case.
<Kamion> I think Ben profiled the various options, hence the newly-cut-down number of kernel targets we're building
<HrdwrBoB> robertj_: I know of nobody who uses a 486 whatsoever, infact I'm pretty sure most charities will bin them now
<Kamion> Hobbsee: I'm way behind on ubuntu-devel. I don't think *all* the targets we used to build were necessary ...
<robertj_> HrdwrBoB: oh no, i think its silly to support 486
<Kamion> HrdwrBoB: you know mdz, right? :-)
<robertj_> HrdwrBoB: just saying, don't down the 486 :)
<Hobbsee> Kamion: right
* Hobbsee files another sync request
<Kamion> HrdwrBoB: IIRC he has a fairly-recently-acquired Soekris router box which has a 486 inside; it's still used in embedded systems sometimes
<robertj_> People who are using 486s for running gateways need to do the math on energy costs
<Kamion> sometimes one's time in replacing hardware has a cost too
<HrdwrBoB> Kamion: and if you are trying to install ubuntu on an embedded 486
<HrdwrBoB> you probably need to rethink what you are doing :)
<Kamion> look, I'm not saying it's a great idea, I just don't want to render it impossible
<Kamion> if I don't absolutely have to
<HrdwrBoB> it should be possible
<HrdwrBoB> but there's no real reason it neeeds to be on a CD for thousands/millions/whatever  of people to download 
<desrt> why not just use -686 and put -386 (or whatever) on a separate cd?
<Kamion> particularly because I'm not sure it's only 486s that require the -386 kernel; Ben said something about bits of hardware that fail when SMP alternatives are enabled, as they are in -generic, but I forget the details
<Kamion> desrt: we are NOT NOT NOT building a separate CD
<Kamion> combinatorial explosion would kill us
<desrt> k :)
<desrt> Kamion; not really
<Kamion> HrdwrBoB: how else will they boot it, though?
<desrt> Kamion; the 386 cd would be server-only
<Kamion> desrt: you've just described one use case for an extra CD. There are lots. I say no to them all, so far.
<HrdwrBoB> Kamion: on what hardware?
<Kamion> HrdwrBoB: <Kamion> ... but I forget the details
<Kamion> ask Ben
<HrdwrBoB> if we're talking about embedded machines, you're up to a higher class of user
<Kamion> not embedded AFAIK, but ASK BEN
<HrdwrBoB> ok
<Kamion> I suppose there's the netboot mini.iso
<Kamion> I could advertise that for 486 users
<Kamion> still worried about the "install with one kernel and boot with another" though - I think that will bring us a lot of subtle bugs
<robertj_> Isn't there a mubuntu that should be responsible for hardware thats too low-overhead for normal ubuntu?
<Kamion> robertj_: in theory, but not in practice
<Kamion> I do not like delegating to semi-vapourware
<robertj_> Kamion: then I say let them theoretically get it working, or wait for some company to offer Canonical cash to fix it
<HrdwrBoB> I agree, I've had many problems relating slightly different versions
<Kamion> and I say let's not break stuff that works until we have a good solution
<HrdwrBoB> especially relating to alternative storage methods
<HrdwrBoB> raid cards, USB storage, etc
<Kamion> robertj_: no company would offer Canonical cash to fix something that we just deliberately broke
<Kamion> be realistic :)
<robertj_> Kamion: also, no company is going to put a 486 on a board & want to run Ubuntu :)
<Kamion> sigh. off to bed.
<robertj_> g'night
<jdub> yay, my laptop shipped
<mneptok> jdub: but ... to *you*?
<Kamion> I'm going to ask Ben to consider producing i386 -generic udebs so that we have more options to play with here
<robertj_> jdub: new lappy?
<jdub> http://www.linuxdevices.com/news/NS4310115400.html
<Chipzz> hi jdub
<jdub> "Simply RISC's free, open "S1" core can run Ubuntu Linux, and targets embedded devices such as PDAs, set-top boxes, and digital cameras, the company says."
<jdub> ubuntu noted in press release as evidence of usefulness - check!
<administrator> hello all i was wondering how do i go about generating a livecd from seeds
<Hobbsee> hey Keybuk 
<Hobbsee> gah.  autosyncer for universe isnt on, is it?
<crimsun> not that I'm aware. We've been filing sync requests for source packages that lack Ubuntu deltas.
<administrator> hmmm interesting
<Hobbsee> crimsun: right.
<administrator> well bbsot
<pixelmonkey> a quick question about launchpad.  Other than just adding to the description of an existing bug, is there any way for me to CONFIRM it, like in bugzilla?
<crimsun> change the Status to Confirmed.
<administrator> so i guess not
<administrator> well can someone point me to documentation? i do not think i want to try this with debian cd creation tools
* Hobbsee contemplates merging sane-backends.
<desrt> does troy sobotka irc?
<crimsun> maybe in #ubuntu-artwork? 
<desrt> check.
* desrt has some comments about the new artwork :p
<jsgotangco> i should update later and see too heh
<desrt> jsgotangco; http://desrt.mcmaster.ca/random/edgy-gdm-theme.png
<jsgotangco> its a bit off
<desrt> jsgotangco; crazytalk
<TheMuso> Artwork shmartwork! :p
<jsgotangco> brb
<jdub> oh man
<desrt> jdub; your impression?
<jdub> *bzzt*
<desrt> uh oh
<jdub> to be frank :)
<desrt> can you be a bit more precise?
<jdub> i think the traditional gdm theme has been a very strong, high quality brand image for ubuntu
<jdub> so there's a risk in changing that at all
<Keybuk> what's the traditional gdm theme?
<desrt> the one that this one replaces
<Keybuk> they're both just arty wish wash, no?
<jdub> certainly it can do with refinement, particularly as the technology improves
<Keybuk> though Jane is going to go mental when she sees that logo
<Keybuk> and quote spacing guidelines and stuff
<desrt> Keybuk; if my system reaches maximum mount count and does a fsck then upstart does some very bad things
<jdub> but it's a *very* strong image
<Keybuk> desrt: define bad
<desrt> Keybuk; it drops me down to a single-user shell
<jdub> i think the one above doesn't have the same quality
<Keybuk> jdub: is it?  I always thought the old one was crap
<desrt> Keybuk; with fsck running in the background (but it doesn't mention that fact)
<jdub> plus it's 'just brown'
<Keybuk> admittedly, I don't like the new one either
<Keybuk> desrt: does it give you a message with the shell?
<jdub> Keybuk: the traditional one is extremely recognisable, it's a *very* strong image
<desrt> ya.  something about "there are no processes running so i will give you a shell" or something
<jdub> Keybuk: it's also minimal and 'quality'
<Keybuk> jdub: I disagree, but anyhoo
<desrt> Keybuk; jdub is a hater
<Keybuk> they change the windows login screen every release
<Keybuk> I really don't think people care
<jdub> desrt: i'm stating quite the opposite, actually
<Keybuk> desrt: that's odd
<jdub> Keybuk: "every windows release" comes vastly less often than every ubuntu release
<jdub> consistency in branding, particularly for the 'front door' is important
<desrt> jdub; general disclaimer is that i define anyone who doesn't like exactly what i like as a hater :p
<jdub> and that screen, i believe, is actually a very strong brand image
<Keybuk> jdub: you need to preach this to the art team :p
<jdub> i know
<Keybuk> desrt: it only gives you that message if the system fell flat on its face
<desrt> jdub; i think that this new screen is sufficiently similar looking to the old one that the brand isn't lost for those who don't really pay attention
<jdub> desrt: it's not
<desrt> jdub; and for those who do pay attention they know that it's still the same thing....
<jdub> no dude, the glow was *really* important
<jdub> think about it
<jdub> when you see rooms of ubuntu machines
<jdub> in photos on flickr
<desrt> Keybuk; lemme flag my fs for fsck on reboot and give it a go
<jdub> do you see rooms of desktops?
<jdub> *NO*
<jdub> you see rooms of *login screens*
<jdub> the bright, cheery, everyone-knows-it, ubuntu login screen
<desrt> great.  so this will let us collect version statistics from images of rollouts :)
<Keybuk> jdub: you forgot to subscribe to the Quotes page before you left
<Keybuk> you anti-traditionalist, you
<Burgundavia> jdub: who has final say over the artwork?
<mjg59> Mark
<Burgundavia> I agree on the login screen
<jdub> (i was asked for my opinion here, at some stage i will mail the art team)
<trappist> what's the deal with compiz-kde?  the compiz source package no longer builds it, but there's a package on the repos that's uninstallable due to deps on an older compiz.
<trappist> or maybe I should ask in #ubuntu-motu?
* desrt begins to wonder how the heck you lose a camera (without having left it in the backseat of a taxi...)
<Keybuk> desrt: if you can be at that shell and on IRC, that'd be great
<desrt> Keybuk; it's not doing it now :p
<desrt> (of course)
<Keybuk> lol
<desrt> oh nice.  fsck finished and bad stuff happened
<desrt> filesystem didn't get remounted readwrite....
<desrt> (therefore X failed to start)
<Keybuk> the one I've usually seen is that sulogin fails, so it just reboots after fsck :p
<TheMuso> Ok, that is a big gdm artwork change.
<desrt> i wonder if maybe it's just an error in the fsck script
<desrt> Keybuk; ok... the upgrade of usplash/initramfs/upstart or the combination thereof that i just did obviously corrected the problem
<desrt> Keybuk; but the system is now (reproducably) totally screwed if you ^C a fsck
<Keybuk> oh, you upgraded upstart?
<desrt> you don't get a readwrite remount
<administrator> well goodday everyone
<Keybuk> desrt: err, it's always been screwed if you ^C a fsck
<Keybuk> sysvinit doesn't handle that well either
<desrt> Keybuk; i used to be able to do that and it would just delay the fsck until next time and boot normally
<Keybuk> oh?
<Keybuk> not sure why upstart would change that
<desrt> definitely.
<Keybuk> you're still in the same checkroot.sh, run by the same /etc/init.d/rc, etc.
<desrt> run by the sysv compatibility script...
<Keybuk> the sysv compatibility script being "exec /etc/init.d/rcS" :p
<desrt> maybe signals are handled slightly differently
<Keybuk> not sure why they would be
<desrt> it's certainly not a big deal
<Keybuk> sysvinit gives it /dev/console and TIOCTTY
<Keybuk> so does upstart
<Keybuk> are you sure that fsck just isn't failing for other reasons?
<desrt> i ran fsck earlier tonight
<desrt> it just ran again because i set my maximal mount count to 1
<desrt> (and hit ^c quite early)
* desrt changes his fsck interval to 2 months and forgets about it
<Keybuk> heh @ upstart
<Keybuk> just worked out why control-alt-delete doesn't work
<Keybuk> heh
<desrt> holy CRAP apt-get autoremove
* desrt tosses debfoster to the wolves
<desrt> how does one gain privs to change priority of bugs from untriaged?
<desrt> or can this only be done my package maintainers?
<Lathiat> um you need magic bug powerz
<Lathiat> not sure how you request that actually
* desrt makes a nasty face at a bug
<Lathiat> if youve got a specified bug in mind right now i could change it for you
<Burgundavia> desrt: you need to be -qa
<desrt> a segfault inside malloc() can mean 1 of 2 possible things
<Burgundavia> which is only about 5 people
<desrt> i'm really hoping it the easy one
<Lathiat> Burgundavia: is the motu group also given that ability?
<Lathiat> else i have no idea how i can do it
<Burgundavia> Lathiat: afaik, no
<Lathiat> pretty sure im not in -qa
<Lathiat> hrm  possibly because i usually edit bugs assigned to ubuntu-motu
<Lathiat> that might make sense
<desrt> does anyone here actually use their computer to do stuff?
* desrt finds it amusing how a bug like "edgy's openoffice crashes whenever you try to save" can remain relatively undiscovered :)
<Burgundavia> desrt: it is known
<jdub> it's been around since warty ;)
<desrt> either i'm seeing a dup or it's reasonably unknown :)
<Burgundavia> no, this is every time, as opposed to once in 10
<desrt> bug 58492
<Ubugtu> Malone bug 58492 in openoffice.org-amd64 "Openoffice.org crashes on "Save"" [Untriaged,Confirmed]  http://launchpad.net/bugs/58492
<desrt> ((sort of funny how "reported bug" != "known bug" anymore))
<Burgundavia> there is a dup somewhere
<Burgundavia> LP has no facility for marking common dups
<desrt> open a bug about it against malone
<Burgundavia> any ephy users around?
<desrt> and i'll open one too
<desrt> the irony will be fantastic
<Lathiat> haha
<desrt> me.
<desrt> what's the official way to set CFLAGS for a debuild?
<Burgundavia> http://www.theonion.com/content/node/52332 <-- do you get the "unsubmitted form elements" dialog on this page when you try and close it?
<desrt> i do.
<Burgundavia> appears to be: http://bugzilla.gnome.org/show_bug.cgi?id=345786
<Ubugtu> Gnome bug 345786 in General "the "unsubmitted changes to form elements" warning should recognize when a form was autofilled, and not warn in that case." [Enhancement,New]  
<desrt> i get that error on googlemaps too
<desrt> although there it makes a little bit of sense
<Burgundavia> right
<Amaranth> damn, looks like willowng got caught in binary NEW
<Amaranth> dang willowng-config-kde
<desrt> oh fuck me
<desrt> openoffice is linked against both libdbus-1.so.3 and libdbus-1.so.2
<Amaranth> desrt: I'd rather not, you haven't given me anything.
<Amaranth> *shudder*
<Burgundavia> desrt: that might be an issue?
<desrt> "heh"
<Burgundavia> cool, I just doubled the number of bugs on moodle!
<Amaranth> Burgundavia: Now it has 2 bugs?
<Burgundavia> 4
<Amaranth> heh
<Burgundavia> 3 of them are "fails to install correctly"
<Burgundavia> which means more bugs have not yet come in because nobody can get teh bloody thing installed
<Burgundavia> just to clarify, debian policy states that apt-get install blah should make blah just work?
<Burgundavia> it should prompt you when it needs to, etc?
<Amaranth> Nope
<desrt> i wonder if this bug would be less of a problem if elf didn't have a flat namespace
<Burgundavia> right
<Amaranth> I know apt-file used to get installed non-functional because it could use wget or curl to download with but only had them as Recommends
<Burgundavia> right, but that is a bug
<Amaranth> not according to people i asked
<Amaranth> i thought so to
<Amaranth> +o
<Burgundavia> is zope an entire webserver?
<Burgundavia> installing schooltool and it is not pulling in apache
<Amaranth> yeah
* Burgundavia mutters about crack under his breath
<Amaranth> most python webapps either have their own webserver or include one of the python webservers in their tree
<Amaranth> mod_python appears to be unliked
<jdub> like many python web projects, it includes a web serving component
<jdub> which is often used behind apache
<Amaranth> they tell you to use mod_proxy to make it play nice with apache
<jdub> Amaranth: apache modules are teh suck
<jdub> Amaranth: web applications are teh rock!
* jdub wishes he could run bad php code separately from his server
<Amaranth> heh
<desrt> jdub; there are various hacks to get suexec ability for php
<jdub> php is still a bit dark ages
<Amaranth> yeah
<jdub> desrt: still cgi
<desrt> you can do it even with modphp from what i understand
<jdub> desrt: i prefer to run web apps as *apps*
<Amaranth> if it wasn't CGI you could make /home noexec and solve lots of problems
<desrt> o.
<Burgundavia> isn't this a massive security hole? "By default a user 'manager' with password 'schooltool' is created with full
<Burgundavia> access and modification privileges.
<Burgundavia> "
<jdub> desrt: lgo is moin as an app behind mod_proxy
<Amaranth> Burgundavia: But is the server open to outside access?
<Amaranth> (that's also a common thing for webapps)
* desrt cries as he finds himself download the oo.o sourcecode
<Burgundavia> desrt: you poor poor bastard
<desrt> jdub; that's neat.
<Burgundavia> Amaranth: currently no, but it could very easily be
<desrt> 215MB :(
<Amaranth> desrt: you touched it last, you're the new maintainer ;)
<Amaranth> wait, that's firefox
<Burgundavia> hmm, System Tools has reappeared :(
<jdub> desrt: if the app dies, i've set apache to show a cool 'server down' page - much better than not getting any response at all ;)
<desrt> jdub; what is the communication like?  normal http?
<jdub> desrt: yep
<desrt> spiff
<jdub> normal mod_proxy
<desrt> why not just run a separate php-only apache server? :)
<jdub> to a localhost only http server
<jdub> desrt: lots of people do that with lighttpd
<desrt> seems like a cool idea
<desrt> could even do it per-user
<jdub> yeah, makes it much saner
<desrt> http-over-domain-sockets would make it hella-cool
<jdub> quite a few enlightened hosting companies are doing things that way now
<jdub> (those are usually the ones who've experienced running python, rails or java apps)
<desrt> that way you don't have to worry about allocating port numbers or having user start their http on the port of another user
* jdub spanks desrt 
<desrt> ow.  why?
<jdub> because you like it that way!
<desrt> sure :p
<desrt> why is archive SO SLOW?
<mneptok> desrt: php-fcgi + lighty = each user's PHP processes belong only that user, and can be started and stopped independently of the daemon.
<mneptok> very nice
<desrt> ya...
<jdub> and you can give decent status pages
<desrt> but how do you deal with the port-allocation problem?
<mneptok> mod_proxy
<desrt> oh.  this is much better.  canadian mirror is just being slow
<mneptok> lighty answers on 81 and apache's mod_proxy passes off to that port for things lighty should serve
<desrt> but say you're a hosting company with 100 users
<mneptok> desrt: .ca mirror for Ubuntu or ... ?
<desrt> each user will need a different local port number to bind to
<jdub> desrt: it's not usually an issue - one port per user
<desrt> mneptok; ya.  dog slow right now
<jdub> or site
<desrt> jdub; right... but say my port number is 4000
<desrt> jdub; and yours is 4001
<mneptok> desrt: that mirror is on some very sketchy hardware ATM
<desrt> your server goes offline
<desrt> what's to stop me from starting my server on port 4001?
<mneptok> USherbrooke is looking to upgrade their infrastructure
<desrt> i wonder if mcmaster would get mad at me if i mirrored the archive
<jdub> desrt: that assumes you have access
<desrt> jdub; good call
<desrt> jdub; but.......
<jdub> desrt: but it's doable otherwise (selinux, say)
<desrt> jdub; if you're running php, you have access
<desrt> jdub; true.
<desrt> unix domain sockets still seem cleaner :)
<jdub> desrt: why if you're running php?
<desrt> jdub; php can execute shell commands, read/write files, etc
<desrt> jdub; having the ability to run arbitrary php scripts as a certain user is the same as having a shell as that user
<mneptok> not if you chroot the individual php-fcgi process to the user's ~/ ;)
<desrt> which is the whole point of moving php out of the same userid of the webserver in the first place :)
<jdub> desrt: "that assumes..." again :)
<jdub> no
<jdub> php being an ass is the reason for doing that
<jdub> and having a more flexible hosting system
* mneptok unzips and shows jdub his "register_globals=on" thong
<mneptok> take me, big boy.
<desrt> jdub; is on x86
<desrt> he has no room for register globals
<mneptok> don't worry, baby. it will fit.
<mneptok> >:)
<desrt> we've definitely thrown the PG13 rating to the wind this evening...
<desrt> heh
<desrt> you can workaround the ooo bug by symlinking libdbus-1-2 to 1-3
<Burgundavia> we went out drinking with a Josh from SUN, who used to work on OO.o and now works on Postgres for them
<Burgundavia> at LWE, I should say
<Burgundavia> he had some choice words to say about OO.o
* mneptok would love to get Gobe Productive GPL'ed
<Treenaks> Burgundavia: he prefers Postgresql, I take it? :P
<desrt> i don't think i've ever seen a package so evil that it has a ubuntu/ directory and a 2800 line debian/rules
<desrt> ok.  here's a question for people who might know
<desrt> openoffice links against dbus but isn't picky about a specific version
<desrt> then it has the shlibs thing in the depend: like for the gtk support package
<desrt> it was last compiled on august 1
<desrt> if someone kicks off a build now will it instead link against libdbus-1-3 and cause the problem to go away?
<Amaranth> likely
<Amaranth> build it in pbuilder (overnight, or something) and see :)
* desrt doesn't have a pbuilder :p
<desrt> is there some tutorial to set one up?
<Burgundavia> desrt: pbuilder? on the help wiki or the ubuntu wiki
* desrt just did man pbuilder and is guessing :)
<Burgundavia> desrt: https://wiki.ubuntu.com/PbuilderHowto
<desrt> i wonder if i can build an edgy base.tar.gz on my laptop then move it to my dapper pc
<Treenaks> sure
<desrt> i bet i could even just copy the edgy debootstrap script over...
<Treenaks> it's all chrooted.. and gcc doesn't care about the kernel, only about its headers ;)
<Burgundavia> with pbuilder, you can easily have an edgy pbuilder on dapper
<Burgundavia> without gross hacking
<desrt> this is WAY easier than i thought it was
<desrt> i like this a lot
<Burgundavia> hmm,  http://news.zdnet.co.uk/0,39020330,39282879,00.htm
<desrt> seems vaguely useful
<desrt> debootstrapping is really fast.
<jdub> Burgundavia: make sure he puts his name on the wiki, along with proposals
<sladen> Burgundavia: I've followed that up already
<Burgundavia> sladen: sorry, context?
<sladen> Burgundavia: 06:49 <Burgundavia> hmm,  http://news.zdnet.co.uk/0,39020330,39282879,00.htm
<Burgundavia> sladen: ah. And?
<sladen> Burgundavia: no responses yet.  It's silly o'clock in everwhere except Australia :)
<Burgundavia> right
<Fujitsu> Yup, 1620 here :P
<HiddenWolf> 8:18 AM in continental europe, hardly silly o'clock. :)
<Fujitsu> Yeah, not particularly silly at all.
<mneptok> and 09:18 in much of Africa. and central Asians are eating lunch.
<Fujitsu> Silly USians, I guess.
<HiddenWolf> pre-coffee-o'clock, granted. :)
<mneptok> hell, it's my midday. but then, my schedule is crazed.
<mneptok> 0220 is like noon. :/
<sladen> Fujitsu: silly Brits
<Fujitsu> Maybe.
<sladen> Fujitsu: whoever, as you mention, the people I was emailing were in the US
<Fujitsu> And where are you, sladen?
<sladen> Fujitsu: the home of Robin Hood.  Hiding out in Nottingham, deep in the rainforests of Nottinghamshire, Engerland
<Fujitsu> A... ha.
<sid> Where can I see things that will be in Edgy? Like prelinking/initng/preload and other things like this to speed up the system.
<Fujitsu> launchpad.net/distros/ubuntu/edgy/+specs
<sid> thanks
<desrt> sladen; edgy
<sladen> sid: not prelinking :)
<desrt> sladen; it's interesting to note that the result of doing a vbesave at boot and then once the X server has already loaded gives me different vbestate files
<desrt> sladen; and that i _seem_ to get slightly better behaviour if i restore the one i saved after X has started
<sladen> desrt: correct.  It's an attempt to snapshot the state of the video card.  In one it'sin Text-mode and the other in graphics mode
<desrt> sladen; but either way it crashes sometimes and not others... :/
<desrt> sladen; no.... the acpi suspend scripts change to a virtual console before vbestate save runs
<sladen> desrt: the changing to a console seems (on the whole) to be a fairly reliable way of saving the state
<desrt> sladen; it's true
<desrt> sladen; but i still need a vberestore otherwise my backlight doesn't come back
<desrt> :)
<sladen> desrt: as if we do a save in graphics mode and the card carries on being communicated with after the save
<desrt> sladen; point is i'm sort of screwed for ideas of what causes this
<desrt> sladen; but if you want me to try stuff i'm more than willing
<desrt> sladen; since it appears to affect an _awful_ lot of people :/
<sladen> desrt: backlight;  what card is this?
<desrt> over a dozen dups of the bug :p
<desrt> i945gm
<desrt> ooo just failed to pbuild.  now i'm upset :(
<sid> Too bad no one is hacking on preload, that looks like an interesting project. It tries to identify patterns in your behavior iirc, so every time you boot, if you start firefox preload will see the pattern and load the binaries and dependencies right before you start it, so it loads very fast.
<desrt> k.  in any case this is definitely a regression since 7.0->7.1
<sid> Or if everytime you start your rss feed reader, 2 minutes later you click on a link and load your web browser. etc etc. It tries to find patterns that you do. iirc
<desrt> but i'm gonna go to bed now
<desrt> sladen; probably talk to you later about this :)
<desrt> sladen; (assuming you're still interested in fixing it)
<sid> Which could be useful if you modified it for web browser downloads. ie if someone downloads a .odt file, or a .doc file. and 90% of the time when they do this, they fire up OO.o, then loading OO.o into memory before they do that would make it appear as if the applications loads very fast.
<desrt> sid; that's actually a neat idea
<desrt> if you pick "open this file" start preloading the app before the file is done downloading
<desrt> nite.
<sid> peace
<sid> Who is the web master?
<HiddenWolf> Is there no i386 daily-live today?
<Mithrandir> HiddenWolf: there's a daily every day
<HiddenWolf> http://cdimages.ubuntu.com/daily-live/20060908/ has ppc and a64 only
<Mithrandir> HiddenWolf: indeed.
<Treenaks> HiddenWolf: i386 is too old. everyone buys amd64 now ;)
<HiddenWolf> Treenaks: ah. my bad. :)
<Mithrandir> HiddenWolf: it tries to pick up the wrong kernel for some reason.
<HiddenWolf> Ah, I can see how that would complicate things.
<Mithrandir> trying a rebuild now
<Mithrandir> HiddenWolf: also, thanks for spotting this.
<HiddenWolf> Mithrandir: :)
<dholbach> good morning
<Mithrandir> morning, Daniel
<dholbach> hey Tollef
<Mithrandir> HiddenWolf: there, fixed.
<HiddenWolf> Mithrandir: wow, talk about fast service. :)
<Mithrandir> HiddenWolf: no point in waiting, is there? ;-)
<HiddenWolf> Mithrandir, :)
* Mithrandir makes the kubuntu, edubuntu and xubuntu live ones too, on a whim.
<Mithrandir> there, fixed kubuntu, edubuntu and xubuntu too.
<dholbach> HAPPY REVU DAY!
<pitti> Good morning
<Hobbsee> hey pitti!
<Hobbsee> morning jono 
* pitti hugs Hobbsee 
* Hobbsee hugs pitti 
<jono> hey Hobbsee :)
<Kagou> hi
<doko> The following packages where automatically installed and are no longer required:
<doko> gdm 
<Hobbsee> heh
<Hobbsee> doko: it's telling you to come over to the dark side!  :D
<doko> ohh, that was just one of the 100 packages that were suggested ;)
<Hobbsee> doko: what, the rest of gnome?  smart apt.
* pygi does a happy dance
<doko> The following packages where automatically installed and are no longer required:
<doko>   ispell linux-headers-2.6.17-6 wamerican ekiga xcursor-themes xfonts-75dpi pnm2ppa gthumb wogerman ttf-kochi-mincho libdirectfb-0.9-24
<doko>   ttf-thai-tlwg xfonts-scalable cdparanoia libwvstreams4.2-extras ubuntu-docs thunderbird-locale-en-gb libxplc0.3.13 wvdial xsane pkg-config
<doko>   mozilla-firefox-locale-en-gb gnome-volume-manager libpt-plugins-alsa libopal-2.2.0 doc-base brltty-x11 libbtctl2 gdebi vnc-common
<doko>   libuniconf4.2 ttf-mgopen esound ttf-gentium rhythmbox xterm gstreamer0.10-plugins-base-apps iogerman readahead ttf-indic-fonts ubuntu-sounds
<doko>   mozilla-firefox-locale-de-de screen bc dc language-selector-common cupsys-driver-gutenprint ttf-kochi-gothic libgnutls12 libpt-plugins-v4l
<doko>   xsane-common ttf-punjabi-fonts scim fortune-mod libgpod0 libscim8c2a ttf-lao libtasn1-2 ttf-devanagari-fonts libsdl1.2debian-alsa wswiss
<doko>   language-selector ttf-gujarati-fonts librecode0 ttf-arabeyes hal-device-manager ttf-telugu-fonts xbitmaps hotkey-setup xvncviewer
<doko>   libsdl1.2debian ttf-bengali-fonts gdm xfonts-base screensaver-default-images libpt-1.10.0 gok linux-headers-2.6.17-6-amd64-generic
<doko>   gnome-spell ttf-arphic-uming bittorrent python-xml contact-lookup-applet tsclient rdesktop scim-gtk2-immodule vino gimp-help-common wngerman
<doko>   xserver-xorg ttf-malayalam-fonts xfonts-100dpi gnome-btdownload gnome-cups-manager foomatic-db-hpijs libpt-plugins-v4l2 nautilus-sendto
<jamesh> have you lost ubuntu-desktop?
<doko>   ttf-tamil-fonts gimp-help-de foo2zjs diveintopython example-content hwdb-client landscape-client python-gst0.10 ingerman liboobs-1-0 slocate
<doko>   xorg fortunes-min ttf-baekmuk gstreamer0.10-tools libgnomebt0 ttf-kannada-fonts linux-headers-amd64-generic libopenobex-1.0-0
<doko>   ttf-arphic-ukai wbritish ssh-askpass-gnome tangerine-icon-theme libwvstreams4.2-base libxp6 min12xxw ttf-oriya-fonts libgnomecupsui1.0-1c2a
<pitti> argh, the paste monster is back
<doko>   thunderbird-locale-de firefox-gnome-support bluez-pin serpentine scim-modules-socket lftp
<Hobbsee> is that just outputting everything you havent specifically installed?  guess there arent enough libs there
<pygi> pitti, you have a sec? :)
<pitti> pygi: sure
<pygi> pitti, it seems libburn will work on freebsd soon, I have a working diff ^_^
<pitti> cool
<pygi> 1246 lines diff :P
<HiddenWolf> Kamion: ping
<HiddenWolf> iwj: ping
<HiddenWolf> iwj: unping, sorry. :/
<HiddenWolf> mvo, ping (wondering if oddness is due to command-not-found)
<seb128> cbx33: did you open a pessulus bug with that patch?
<seb128> "There are currently no open bugs." for the pessulus package according to launchpad
<mvo> HiddenWolf: what odness in particualr?
<HiddenWolf> mvo: from the livecd I tried pppoeconf on the command line (which is not on the cd) and I got: "This option is not available. Please see --help for all possible usages"
<cbx33> seb128: I thought you wanted the patch for the gconf thing....I have repackaged pessulus.....you can check the diff here..... http://progbox.co.uk/main-additions/
<cbx33> if you want me to extract the patch I can
<seb128> why "repackaged pessulus", again
<seb128> I asked the other day you didn't reply
<seb128> you don't want that change to Ubuntu?
<seb128> you prefer to keep repackaging it for yourself only?
<cbx33> no
<cbx33> sorry seb128 
<cbx33> I'll get you the patch and raise a bug
<seb128> you spoke about feature freeze yesterday, that was for the gconf change?
<cbx33> no...that was for the pessulus patch
<seb128> that's not coherent
<seb128> you asked if I reviewed a patch and you also say you didn't send it
<cbx33> I gave you that url a few days ago...
<cbx33> but I will send it through in proper format to LP now
<cbx33> I apologise for the miscommunication on my part
<seb128> and I asked to open a bug with the patch ;)
<cbx33> i thought you meant for gconf
<seb128> k, no problem
<cbx33> my apologies again
<cbx33> sorry seb128
<seb128> please open a pessulus bug with the patch
<cbx33> I will do it now
<seb128> it's better to organise the work ;)
<HiddenWolf> mvo: http://hiddenwolf.org/files/Screenshot.png
<seb128> thank you
<cbx33> seb128, what do you want me to do about the gconf path file modification?
<seb128> open a bug?
<cbx33> ok
<pitti> hi janimo!
<mvo> HiddenWolf: is this on the live-cd?
<HiddenWolf> mvo: yes
<janimo> pitti: hi
<mvo> HiddenWolf: can you please do: "dpkg -l command-not-found" ?
<zyga> login sound is great :)
<HiddenWolf> mvo: if I reboot to the livecd, yeah, sure. Other info you need?
<zyga> hey mvo, sorry I had no time to fix the parser yesterday
<zyga> I will have plenty of time during the weekend
<mvo> zyga: cool, thanks
<mvo> HiddenWolf: but the screenshot is from the live-cd? I don't think we have command-not-found installed there, so I doubt it is the reason for the problem
<mvo> HiddenWolf: but the screenshot looks very odd
<HiddenWolf> mvo: screenshot is from today's daily-live
<zyga> mvo: huh?
<zyga> any problems I should know of?
<cbx33> seb128: please find bug with attached patch
<mvo> zyga:  http://hiddenwolf.org/files/Screenshot.png 
<mvo> zyga: but I don't think we install command-not-found on the live-cd yet
<zyga> that's not the output of cnf
<zyga> I don
<zyga> I don't have an idea what prints that kind of messages
<HiddenWolf> For the record, pppoeconf should not be found, or throw an error about needing root if it was installed.
<cbx33> seb128: I'll brb
<seb128> cbx33: k, I'm looking at the patch right now
<HiddenWolf> mvo: zyga, I'm hesitant to file a bug without even knowing the correct package. Do you have any suggestions?
<zyga> HiddenWolf: hmm, grep sudo for that message, if not found then file it on pppoeconf
<mvo> HiddenWolf: I update the daily desktop cd now and see if I can reproduce it
<cbx33> seb128: I'm so sorry about the mix up
<cbx33> ;)
<cbx33> brb
<seb128> iwj: you wanted to do some changes to nautilus before the upload or just wanted the .dsc/.diff.gz to have a look? Said differently, should I upload the update
<seb128> cbx33: np
<HiddenWolf> mvo: ok, I'll wait for you, considering I have no network on livecds. :)
<pitti> mvo: mmmm, 'Enable sharing' :)
<pitti> mvo: works well here
* mvo hugs pitti
<pitti> mvo: except for some bug in enable_sharing, but that's my fault
* pitti is happy that cups 1.2.3 works now
<pitti> doko, seb128: FWIW, OO.o file dialog works just fine on latest edgy
<pitti> (for me)
<doko> pitti, was this the machine, where you did upgrade to the 2.0.4 packages?
<zyga> guys, where did the smp kernels go?
<zyga> I've got an uniprocessor kernel now
<pitti> doko: oh, I'm on 2.0.3-4ubuntu2-1 (amd64 latest edgy)
<janimo> pitti: do you know if the default printer setting is better set in /etc/cups/printers.conf or in ~/.cups/lpoptions? RH's tool uses the former we have the latter
<janimo> they are not the same format so they do not cascade as usual /etc ~/ configs
<zyga> mvo: did you get my message about g-a-i?
<mvo> zyga: no?
<mvo> zyga: what is it about?
<pitti> janimo: my feeling is that every user should have her own
<Tonio_> hi everyone
<HiddenWolf> pitti: depends on the setup. I can image that if there is only one printer, everyone would use the same settings, considering there is only one way the thing can be properly configured.
<pitti> HiddenWolf: how so?
<pitti> HiddenWolf: some people might want 'draft' b/w by default, some high quality with colors
<pitti> HiddenWolf: and different paper formats, etc.
<pitti> HiddenWolf: also, different people might have different default printers
<Tonio_> pitti: we would like digikam to get into main, and we wrote a maininclusionreport for this, but I just saw it still has 2 universe deps, should we write 2 other maininclusionreports or can all be done in the same page to make it more simple ?
<HiddenWolf> pitti: right. :)
<pitti> Tonio_: please write one MIR for each source package
<Tonio_> pitti: thanks for the info
<pitti> no problem
<Tonio_> pitti: may I ping you concerning this when it's done ?
<pitti> Tonio_: I'll get notified by email
<pitti> but sure, you can ping me, too
<Tonio_> ah ! perfect, thanks :)
<HiddenWolf> pitti: when will 1.2.3 be in? I was planning to file some bugs on cups later. (have to use us-legal papersize on a4 paper to avoid having parts fall off the page on dapper)
<pitti> HiddenWolf: I'm just building the final source package
<pitti> thus, in a few hours
<HiddenWolf> cheers.
<Kamion> HiddenWolf: yes?
<HiddenWolf> Kamion: two things, I just filed a bug about an option for pppoeconf network configuration in ubiquity, and today's daily showed an incorrect language list that you might want to look into: http://hiddenwolf.org/files/Screenshot.png (note missing fonts and "No Localization")
<Kamion> HiddenWolf: you're free to file wishlists of course, but it's very low down the list
<giftnudel> HiddenWolf, Kamion: the missing font was with knot-2 also
<giftnudel> iirc
<Kamion> HiddenWolf: I'm aware of the missing font
<giftnudel> ok
<Kamion> it's just for Dzongkha IIRC
<Kamion> HiddenWolf: "No localization" is sort of deliberate, although maybe should be sorted to the bottom
<Kamion> there clearly ought to be an option to install in the C locale
<HiddenWolf> It just looks odd this way.
<giftnudel> Kamion: it should be first I think
<pitti> 'Theme incompatible with usplash_bogl' -- hmm
<Kamion> giftnudel: I can see your argument, but I think with ubiquity's target audience it should be last
<giftnudel> ok
<giftnudel> Kamion: it doesn't matter anyway, the people that want it will look for it
<cbx33> why when I apt-get upgrade are some files kept back
<cbx33> mornin sabdfl 
<cbx33> some great feedback on the sounds ;)
<pygi> cbx33, ;)
<pygi> cbx33, I should get a cable so we can record real music :)
<HiddenWolf> cbx33: yeah, they rock, but are a bit long-ish. :)
<pygi> HiddenWolf, ;)
<Hobbsee> hey sabdfl 
<cbx33> HiddenWolf: some other people have said that too
<cbx33> damn you guys making gnome start quicker :p
<iwj> seb128: I wanted it for my testing.  So, I built it, and ran it, and it worked as I hoped.  There are no more changes needed from me.
<pygi> cbx33, lol :)
<seb128> iwj: ok, thank you
<HiddenWolf> cbx33: well, they're exactly long enough for the livecd here. :)
<cbx33> seb128: did the patch seem ok?
<seb128> cbx33: not really
<cbx33> oh ok
<cbx33> HiddenWolf: that's cool seeing as most people first impression will be of the live cd
<seb128> cbx33: I talked with vuntz who think you should create a new class for using gconftool instead of mixing that in the middle of the existing one
<seb128> cbx33: is that something that would be needed for edgy?
<cbx33> ah
<cbx33> seb128: Ideally yes....
<cbx33> SCP has just gotten the pessulus integration as per the spec
<seb128> what SCP is BTW?
<cbx33> Student Control Panel
<seb128> I don't know about it neither the spec
<cbx33> brb
<pygi> seaLne, SCP rocks :)
<pygi> seb128, *
<seb128> pygi: ?
<seb128> ah
<pygi> what? :)
<cbx33> seb128: did you want a whole new class, or just seperate functions within the gconfapplier class?
<seb128> pygi: I didn't get what you wanted by saying "*" first :p
<seb128> cbx33: ask vuntz ;)
<cbx33> ok...
<vuntz> seb128: can the patch be integrated after feature freeze?
<vuntz> seb128: if it's not possible, I believe it's good to integrate it now (since it works and doesn't affect standard desktops
<vuntz> then cbx33 can fix the issues in the next few weeks
<cbx33> I surely will
<cbx33> can we integrate now...and still fix after
<cbx33> so I can ask peopel tobeta test?
<seb128> vuntz: yeah, what I thought to
<seb128> too
* pitti kicks the autofuck tools
<pitti> *** YOU'RE USING autoconf (GNU Autoconf) 2.60.
<pitti> *** Scribus requires autoconf 2.53 or newer
<pitti> I learned in school that 2.60 > 2.53
<lifeless> ahahahaha
<lifeless> thats not autoconf, its a fucked macro in scribus, almost for sure
<pitti> lifeless: sure, I just love to bitch about autotools
<lifeless> :)
<pygi> pitti, lol :)
<Hobbsee> ugh, that.
<Hobbsee> heh
<pygi> Hobbsee, what? :)
<Hobbsee> pygi: pitti's comment
<pygi> ah well :)
<Tonio_> pitti: hehe, that's very common with kde packages, and the problem is generally in admin/cvs.sh
<pitti> Tonio_: I already fixed cvs.sh
<Hobbsee> Tonio_: that's what i thought.  read the error again.
<pitti> Tonio_: it's still complaining
<Tonio_> pitti: just export AUTOCONF=autoconf
<Tonio_> isn't that working ?
<Riddell> pitti: it needs two lines updated, for autoconf and autoheader
<pitti> Tonio_: not if I'm reading admin/detect-autoconf.sh correctly, but let me try
<Tonio_> this generally does the trick for me
<Riddell> pitti: http://kubuntu.org/~jriddell/kubuntu_00_autoconf2.60.diff
<pitti> Riddell: aah, right, that's it
<pitti> thanks
* pitti hopes that Kamion does not mind that he just bumped the severity of #59257
<ogra> hmm, where do 30 MB on my i386 CD come from ?
<seb128> pitti: how soon will we hade ddeb?
<Hobbsee> ogra: i ate some of the packages.  sorry about that :P
<ogra> Hobbsee, if you ate them they would have disappeared ... unless my logic is wrong :)
<Kamion> pitti: not at all, thanks
<Hobbsee> ogra: argh.  oops.
<Hobbsee> ogra: your logic is definetly wrong, yes :P
<ogra> but my (i386 only) CD grew by 30M
* pitti turns seb128's head to infinity's direction
<seb128> pitti: you dropped cups dbg package so you must have an idea, no? ;)
<Kamion> mjg59: console-tools 1:0.2.3dbs-62ubuntu6 fixes the VT switch in console-screen.sh/setupcon, which I understand made life awkward for usplash
<pitti> seb128: next week, I hope
<seb128> pitti: said differently, should be drop dbg packages for GNOME too now?
<seb128> cool
<pitti> seb128: no, that would be too hasty; I just wanted to avoid going through NEW
<seb128> ok
<pitti> seb128: and cups generally doesn't crash often, it just doesn't work most of the time :)
<seb128> right ;)
<pitti> seb128: (i. e. most of the time when it doesn't work, it's not due to a crash)
<Nerm> morning
<Nerm> is there a nice repo or something for getting gnome 2.16 on dapper ?
<seb128> Nerm: edgy
<Nerm> ah.. hmm..
<seb128> Nerm: you can't get stable and new crack at the same time
<Nerm> yes this is true - it's a work machine though so it needs to be reasonably stable... is edgy.. usable ?
<Hobbsee> Nerm: no.  wait a fwe months
<Nerm> ok :)
<pygi> Hobbsee, few months, lol :)
<seb128> Nerm: I would say it's ok for daily use
<Nermal> seb128: I'll wait - nothing I really need in gnome 2.16 
<seb128> ok
* pygi is running gnome 2.15 since few months :)
<seb128> ogra, cbx33: I've just uploaded pessulus with that patch so it can get testing, feel free to make the patch better anyway ;)
<ogra> yay \o/
* ogra hugs seb128 
<jsgotangco> yay
<ogra> so it looks like we really could get student control panel in edubuntu edgy :))))
<ogra> hey sabdfl 
<seb128> ogra: cool
* ogra tires the first upstart driven ltsp ... and feels a bit  ... um... edgy ...
<cbx33> thanks you so much seb128 
* cbx33 starts the group hug :p
<seb128> np
<seb128> thank you for the work on that ;)
<Riddell> Kamion: should I be worried if kubuntu/dvd can't install xorg in the daily CD checks?
<Kamion> Riddell: you should at least investigate to find out why
<Kamion> might just be out-of-date binaries though
<jordi> whiprush: nice post :)
<coyctecm> https://launchpad.net/distros/ubuntu/+source/metacity/+bug/29584
<Ubugtu> Malone bug 29584 in metacity "False reports of "Window not responding" error" [Medium,Needs info]  
<coyctecm> any progress with that?
<coyctecm> it happens amd64 nut not with x86 box
<coyctecm> dapper+latest updates
<HiddenWolf> coyctecm: if there was any progress, it'd be on the bug report
<gomek> Anyone here have much experience with customizing the ubuntu install cds?  (Stupid question, I know, but...)
<gomek> I think a better question to ask would be whether anyone is awake!
* Hobbsee wonders why people keep coming in and asking this.
<gomek> Would the other person be "administrator"?
<pygi> gomek, !!! 
<pygi> gomek, use Reconstructor for live cds, and this is not the right channel :)
<gomek> Which channel would be the correct one?
<coyctecm> HiddenWolf: yes i could try to fix it, thought i have no clue what to look
<gomek> You greet me as if you know me, pygi!  How welcoming.  ^_^
<mneptok> #teach-me-distro-creation
<mneptok> :P
<gomek> bah, you made me actually join that channel
<pygi> gomek, lol, just a sec pls :)
<gomek> thanks much pygi
<pygi> gomek, http://reconstructor.aperantis.com/index.php?option=com_frontpage&Itemid=1
<pygi> otherwise #ubuntu :)
<whiprush> thanks jordi 
<pygi> gomek, you have docs there also on how to use it :)
<gomek> ah.  my problem, though, is in completely stripping gnome from ubuntu.
<gomek> from that webpage: Reconstructor does not create separate distros.
<Hobbsee> infinity: ping?
<pygi> gomek, you can remove ubuntu-desktop package
<pygi> gomek, page lies :)
<gomek> that's only a metapackage
<pygi> gomek, well, and all it's deps :P
<gomek> could i remove, like, everything, then install ubuntu-base?
<HiddenWolf> gomek: try something like debfoster
<pygi> gomek, probably yes, but #ubuntu pls :)
<gomek> alright, i'll try #ubuntu, but what if they send me back to #ubuntu-devel?  haha
<coyctecm> no they won't
<gomek> alright, thanks for the help, then.  ^^
<Hobbsee> mvo: have you seen bug 59311?  there's a fix there, whenever you feel like implementing it
<Ubugtu> Malone bug 59311 in update-manager "update-manager crashes when /var/log/dist-upgrade doesn't exist" [Medium,Confirmed]  http://launchpad.net/bugs/59311
<mvo> Hobbsee: thanks, I'm a bit swamped currently, but I will get to it today
<Hobbsee> mvo: cool.  okay.  did you have other fixes to make to update-manager, or just that one?
<mvo> Hobbsee: the fix needs to be done in the dist-uprader I presume, that one uploaded seperately to a special target. otherwise I would be fine with you having a look
<Hobbsee> mvo: gotcha, okay.
<mvo> but thanks for offering your help!
* mvo hugs Hobbsee
* Hobbsee hugs mvo 
<Hobbsee> i was going to give it a shot
<Hobbsee> before i go and rant at a couple of people.
<HiddenWolf> mvo: did you check the livecd?
<Hobbsee> make that 3 people.
<Hobbsee> the people-Hobbsee-will-rant-at list is growing!
<pygi> Hobbsee, ble =)
<Hobbsee> :P
<slomo> Hobbsee: oh, i hope i'm not on that list? ;)
<Hobbsee> slomo: not currently :)
<Hobbsee> slomo: want me to find something?
<zyga> mvo: ping
<mvo> hello zyga
<mvo> HiddenWolf: not yet
<mvo> iwj: gnome-app-install should be fixed, I would appreciate if you could check that it works for you too
<zyga> mvo: is there any project to upgrade the format of .deb packages?
<mvo> zyga: upgrade as in ? 
<zyga> mvo: such as improved binary format for various reasons
<mvo> zyga: like what? new compression methods? something else than ar?
<zyga> mvo: yeah something like that
<zyga> mvo: more extensibility perhaps
<zyga> any project that aims to develop deb+1 is fine with me :)
<wasabi_> I don't particularily see anything wrong with teh current packages.
<wasabi_> Obvioulsy I'd like to see new FEATURES, such as file class tags.
<zyga> wasabi_: they are fine but it's hard to add anything and they have some drawbacks like random access or even efficient file listing
<zyga> (actually I'd love to see the death of 99% of postinst prerm and such but that is a major change and would require debian blessing)
<wasabi_> I like the extensibility being in scripts.
<zyga> only 1% of packages _really_ need those scripts and they are a pain in our collective ass
<wasabi_> It means we don't need a new package format for every minor change.
<zyga> wasabi_: scripts are not declarative, we mostly use them for declarative purposes which sucks badly
<zyga> wasabi_: I do not propose to REMOVE them, just limit the real need for them
<zyga> all crucial packages probably need them :)
<zyga> wasabi_: I for one would welcome all info, man, and other regstered by a wrapper around dpkg
<zyga> this is a good thing actually as the packages are more compatible and more roboust (can be easily validated)
<mneptok> screw it, let's go to .rpm
<pygi> lol
* HiddenWolf runs for cover
<zyga> mneptok: rpm suffers from the same issues :P
<pygi> let's not :)
* pygi thinks we should all go to quasy-scsi package :)
* mneptok closes his <.sarcasm> tag for zyga 
<zyga> mneptok: I know you were not serious ;-)
<mneptok> and, apparently, i didn't. so here it is. </sarcasm>
<mneptok> zyga: my reputation as a complete loon makes it hard for me tell when people know i'm joking :)
<gnomefreak> who is best person to speak to about apt?
<pitti> gnomefreak: mvo 
<pygi> gnomefreak, mvo ^_^
<gnomefreak> ok ty
<pygi> gnomefreak, #synaptic
<jdong> who's the best person to annoy in the interest of seeking revenge for this application crash report dialog that keeps smacking me in the face? ;)
<jdong> seriously, that's some art of annoyance :)
<pygi> jdong, I forgot who do we bug about all the bugs this week :)
<gnomefreak> jdong: :) fix whats crashing
<jdong> I've got a better fix
<elmo> is there some way to recursively flatten the depends of a a package?
* jdong pulls out rm and sudo
<gnomefreak> ut oh
<StevenK> elmo: Doesn't germinate do that?
<StevenK> elmo: Or are you talking in a general case?
<elmo> StevenK: general case - and I also didn't think germinate did flatten it all the way down
<elmo> but maybe I'm wrong - it's been a while
<StevenK> elmo: I can't think of anything in a general case.
<pitti> elmo: oh, the depends, not the rdepends---doesn't apt-cache dotty do that?
* pygi just got upgrade in bandwith package, whee :)
<pitti> elmo: also, apt-rdepends' description seems to indicate that it can do forward dependencies, too
<elmo> pitti: ah, hmm, thanks
<xav> can you think about anything that could explain a 50% 3d performance drop in either debian or ubuntu ?
<jdong> crimsun: ping?
<xav> afaik, using the same version of X, mesa, and the games I'm trying
<jdong> xav: 50% compared to what?
<xav> the only difference I can think about is 686 optimization, but I'm not even sure ubuntu doesn't have it
<xav> jdong: compared to other distrib
<jdong> k
<mjg59> How are you measuring performance?
<jdong> 686 optimization or cflags cannot possibly explain a 50% performance difference
<xav> mjg59: by checking the fps right after the games start, using default settings
<Hobbsee> infinity: unping
<mjg59> And which chipset is this?
<xav> I don't need to check fps, it's so easy to feel it. using intel 855gm crap
<xav> I don't think there is such a difference on other box, with other cards
<xav> I'm less sure about that though
<xav> jdong: right, I could hardly believe that
<jdong> could be something with the i810 drivers, or dri....
<jdong> funny thing is, I have a 855GM in my other laptop
<jdong> and it feels fine in Ubuntu compared to Fedora/RHEL4
<jdong> I haven't tried any other distros
<xav> in 3d games?
<jdong> if you count chromium bsu as a 3d game :D
<jdong> I'm not gonna try to run ut2004 on an 855gm
<xav> no, the one that it can just run
<xav> ie slow but playable, just at the limit :)
<xav> eg ppracer or flightgear
<iwj> mvo: Ah, thanks.  Where is the version I should be testing ?  Your bzr ?
<xav> oh my god, I feel so stupid, I forgot one of the most important factor, and that was the reason..
<ogra> hmm, weird ...
<ogra> i have a script that i run on ltsp clients on boot ...
<ogra> while true; do
<ogra>         if [ -S /tmp/.ltspfs-socket ] ; then
<ogra> ... do something ...
<ogra>         else
<ogra>                 sleep 10
<ogra>         fi
<ogra> done
<mvo> iwj: in the archive 
<ogra> it always dies after the second run ...
<mvo> iwj: all the local testing was good so I did the upload
<ogra> anybod an idea ? 
<pitti> ogra: it dies in 'do something'?
<ogra> no
<ogra> it dies in sleep
<ogra> thats the weird part 
<StevenK> ogra: Can you run it with -x ?
<pitti> ogra: urgh?
<ogra> good idea
* ogra add set -ex
<pitti> in general it's a very good idea to write all shell scripts with #!/bin/sh -e
<ogra> hmm, nothing special there ...
<ogra> i see it checking for the socket and doing the sleep
<ogra> twice
<ogra> then it dies
<pitti> ogra: i. e. sleep exits with != 0?
<StevenK> pitti: That's what I'm thinking
<ogra> well ... how could that be ? 
<pitti> sleep is not a bash builtin at least
<pitti> ogra: s/sleep strace -f -o /tmp/sleep.trace sleep 10
<ogra> i'm using sh in the start process 
<pitti> erm,
<StevenK> pitti: Hah
<pitti> ogra: s_sleep_strace -f -o /tmp/sleep.trace sleep 10_
<ogra> hmm 
<ogra> looks ok
<ogra> http://people.ubuntu.com/~ogra/sleep.trace
<pitti> ogra: ok, where *exactly* dies it?
<StevenK> ogra: Can you throw the -x trace somewhere?
<iwj> mvo: OK, I'll take a look, thanks.
<iwj> But I have to have lunch now :-).
<ogra> thats tricky
<ogra> it doesnt die if i start it from commandline after the boot
<ogra> so a simple redirec doesnt work
<StevenK> I've never quite figured out how to get -x to spit into a file
<ogra> right
<StevenK> And re'exec'ing shell scripts can do wacky stuff
<ogra> i'll try to modify the initscript that starts it
<ogra> to redirect somewhere ...
<zyga> mvo which you is you?
<zyga> mvo: I'd like to PM you 
<ogra> hrm 
<ogra> it doesnt die if i dont background it 
<ogra> originally i call it with an & attached
<ogra> if i drop the & it runs and runs
<ogra> how weird
<popey> cbx33: ping
<zyga> mvo_: ^^ ?
<bddebian> Heya folks
* ogra wonders if thats upstarts fault
<cbx33> pong popey 
<mvo_> zyga: I'm this one
<zyga> mvo_: ok
<ogra> aha !
<ogra> if i run it from rc2 instead of rcS it works ....
<ogra> the only thing that runs between these two scripts is S90console-screen.sh ...
<jdong> mjg59: I only get 16 colors with usplash :(... it looks very weird right now :)
<zyga> mvo: do you see anything I wrote? I'm not sure if gaim handles renaming users right...
<jdong> ok, gnome... this isn't funny.... I'd like to change some printer settings before I print, please....
<Hobbsee> jdong: you cant.  it's called simplicity :P
* Hobbsee ducks
<jdong> lol
<StevenK> jdong: Consider yourself lucky Gnome didn't remove the Print button!
<jdong> so I have to open up the Cups manager, change the settings, print, then change the settings back....
<jdong> yeah, that's simple
<jdong> that's usability
<ogra> jdong, patches accepted ;)
<StevenK> jdong: They want it to appear as simple as Windows.
<jdong> ogra: apt-get install kprinter works faster for me :)
<jdong> or does gnome not let me print to stdout
<ogra> but the prob will never get fixed that way :)
<Amaranth> i thought the print dialog in edgy was a lot better
<jdong> Amaranth: that's what I was told, too
* Hobbsee high-fives StevenK 
<jdong> Amaranth: but gedit's print dialog looks exactly the same
<mneptok> Amaranth: yeah, it now has an actual "Screw This" button
* StevenK high-fives Hobbsee back
<Hobbsee> :D
<jdong> ogra: wouldn't patches that add more options to the print dialog get rejected anyway? :P
<ogra> depends on the options :P
* ogra kicks /bin/dd
<Amaranth> weird, i remember epiphany and gedit were both supposed to be using the new gtk printing stuff but they have completely different dialogs here
<jdong> ogra: I want the cups printer property page accessible from the print dialog
<Amaranth> and i've never printed from linux/gnome before
<jdong> ogra: I'd like to print my pictures at higher than default resolution, please :)
<Amaranth> so i have no idea which one is new :P
<zyga> ogra: did you find the SIGSEGV that happens outside of C locale? :D
<ogra> zyga, aha
<ogra> is there a bug about it ? 
<zyga> ogra: it's a bug in gettext 
<ogra> ah, ok
<ogra> its evil 
<zyga> ogra: something with PRIuMAX and such macros that should be expanded by gettext
<zyga> I didn't file a bug but I did let the upstream of dd know about that a long time ago
<jdong> Amaranth: so, now there's two different gnome print dialogs?
<Amaranth> either that or epiphany always had it's own dialog
<zyga> (gettext supports those macros but there is an apparent bug :)
<Amaranth> iirc the gtk+ dialog was supposed to be generated from your ppd file (filtered or something i'd guess)
<pitti> slomo: renice'ing apport to +5 works wonderful
<pitti> slomo: thanks for the idea
<mvo> zyga: probably freenodes policy. I'm away for a bit
<mjg59> jdong: You will do until there's new artowkr
<mvo> zyga: lets talk in 1h
<zyga> mvo: ok
<jdong> mjg59: I mean, the current usplash, the gradients are all garbled colors
<jdong> mjg59: the other laptop does smooth gradients and correct colors
<jdong> so I'm thinking it's some sort of video mode problem?
<Amaranth> jdong: usplash works for you? lucky
<mjg59> Nngh.
<jdong> Amaranth: only on one of my laptops
<mjg59> If usplash /doesn't/ work for people, could they *please* let me know?
<ogra> usplash works totally fine on thin clients ....
<mjg59> Since it does now in theory
<ogra> get thin clients people !
<Amaranth> mjg59: there is a bug that i figured was similar enough
<Amaranth> bug filed, i mean
<mjg59> Amaranth: Which is?
<Amaranth> it looks like usplash does something weird to make me have huge fonts then crashes
<pitti> mjg59: I just did a clean installation of today's ppc/alternate, no usplash love there
<mjg59> What hardware is this, and what version?
<mjg59> pitti: Yeah, sorry, PPC is known broken
<mjg59> Fix is straightforward
<pitti> mjg59: however, it still has -16
<pitti> tomorrow's CD images should be more recent
<dholbach> doko: karma-for-uploads is not implemented yet :-p
<Amaranth> mjg59: https://launchpad.net/distros/ubuntu/+source/usplash/+bug/57694
<Ubugtu> Malone bug 57694 in usplash "[edgy]  usplash fails to correctly restore text mode" [Untriaged,Confirmed]  
<elmo> I assume it's too late to do a main/universe swap?
<Amaranth> mjg59: it's an hp pavilion dv8000t laptop with a 1440x900 native resolution screen, using usplash 0.4-20
<mjg59> Amaranth: Ok. That's not the same problem.
<mjg59> Amaranth: What graphics chipset? What CPU?
<Amaranth> core duo, nvidia geforce go 7400
<mjg59> Right
<mjg59> I have similar hardware here
<mjg59> What was the last version of usplash you tried?
<Amaranth> probably -18
<Amaranth> want me to try it again?
<iwj> mvo: That gnome-app-install works fine for me, thanks.  (Modulo some messages during the postinst, which I expect you know about.)
<Amaranth> i didn't see anything in the changelog to make me thing it would work
<mjg59> -18 fixed all known text mode issues
<Windkracht8> Hello all
<Amaranth> alright, i'll reboot
<Amaranth> brb
<Amaranth> ack, logout dialog won't come on
<jdong> mjg59: so, any hints on why I only get 16 color gradients on the 256-color usplash?
<jdong> core duo, ati mobility radeon x1400
<Windkracht8> something I've seen, the update manager notification icon, isn't transparent
<Windkracht8> does anyone know where to get the icon so I can make it transparent and send it to the developers? 
<Amaranth> mjg59: so it no longer puts me in big text mode but i just get a regular text boot
<Amaranth> i did see a flash of "file exists" or something before it cleared the screen
<StevenK> Must have been something we said
<Hobbsee> heh
<Windkracht8> nobody knows where the update-notifier source code is?
<jdong> apt-get source update-notifier?
<jdong> bzr branch http://people.ubuntu.com/~mvo/bzr/update-notifier/main/
<Windkracht8> thanks
<jdong> np
<Windkracht8> seems like they all ready made it transparent
<Windkracht8> so Windkracht8 out, by all
<Kamion> mjg59: oh, do you know what the powerpc problem is? I was about to start looking, having cleared out all state from my session that I'd be unhappy to lose
<Kamion> (usplash)
<ogra> who does initramfs atm ? 
<ogra> infinity, ?
<ogra> or Keybuk 
<zyga> mvo: around?
<zyga> mvo: last chance to be around before monday
<mvo> zyga: sorry, I'm terrible busy right now
<zyga> mvo: okay, till monday then
<mvo> have a great weekend zyga!
<zyga> have nice weekend everyone :)
<zyga> bye
<tortoise_> seb128: ping
<seb128> tortoise_: pong, with context is better if you want to get a pong
<tortoise_> seb128: am trying to write a patch for the gnome-at-properties-dialog in gnome-control-center.  I'm having some problems though with using dpatch-edit-patch on the package.
<seb128> how so?
<dholbach> sladen: what about your bcm2033-firmware upload to revu - is that still something you want to have in?
<tortoise_> I've asked in #ubuntu-motu about this
<tortoise_> rm -f debian/gnome-control-center.1
<tortoise_> rm -rf /tmp/dpep-ref.F24980/control-center-2.16.0/debian/build
<tortoise_> make: *** No rule to make target `unpatch'.  Stop.
<zul> dholbach: uh...wouldnt that upset broadcom?
<dholbach> zul: i have no idea about that stuff :)
<zul> dholbach: neither do i :)
<thom> more importantly is it at all distributable
<zul> thom: thats what i meant
<thom> well, they're two different things :-)
<zul> yes yes
<seb128> tortoise_: control-center doesn't use dpatch, it uses simple-patchsys
<seb128> tortoise_: you can use cdbs-edit-patch
<tortoise_> seb128: Also I've been trying to add some icons to the package and I get this error when building the package: 
<tortoise_> capplets/accessibility/at-properties/at-settings.png: binary file contents changed 
<tortoise_> Ok, thanks I'll read up on that
<seb128> tortoise_: you can't change a .png file, the diff doesn't work on binary
<seb128> tortoise_: you can to use uuencode if you really want to do that
<tortoise_> seb128: Whats the proper way to add a pixmap to the package then?
<seb128> tortoise_: uuencode
<tortoise_> seb128: ok, thanks
<seb128> np
<dholbach> tortoise_: if you apt-get source ekiga you find an example for it
<tortoise_> dholbach: thanks
<Keybuk> Kamion: ping?
<desrt> k.  i need feedback
<desrt> if something fails to build inside pbuilder is it possibly my fault?
<desrt> aside from running out of diskspace (of which i have 26GB free)
<dholbach> desrt: what goes wrong?
<dholbach> desrt: which error msg?
<desrt> some generic error
<desrt> lemme pastebin it
<mdz> seb128, dholbach: how was the meeting about bugs?
<desrt> http://pastebin.ca/164405
<dholbach> mdz: oh I wanted to send the log to everybody who was there - do you want a copy too?
<mdz> dholbach: please
<_ion> I looked into the "usplash never comes up" problem a bit: e.g. /sbin/usplash -c -x 800 -y 600 shows the splash, but /sbin/usplash -c -x 1024 -y 768 says "screen init failed". /etc/usplash.conf seems to contain "xres=1024", "yres=768".
<desrt> dholbach; i suppose it's within the realm of possibility that OO.o build uses more than 26GB....
<dholbach> mdz: we're going to pimp the desktopteam wiki about different modules we have, simon agreed on creating queries for people to get easily involved and jono will help us to get it broadcasted
<mvo> mdz: good morning. what shall we do about enabling universe/multiverse? shall I try get the misssing bits done for synaptic over the weekend?
<dholbach> desrt: that's something that doko will be able to tell you
<desrt> doko; ping? :)
<mdz> mvo: does the implementation of suggest-packages-for-filetypes require it?
<doko> ?
<seb128> mdz: good, discussion with useful and we decided on some actions to organize teams, bring new people and what would need work first
<mdz> doko: peak disk space used for an oo.o build
<mvo> mdz: no, gnome-app-install handles this just fine and ian does not want to install any applications from universe by default anyway for security reasons 
<mdz> mvo: ok, let's defer it then
<mvo> mdz: ok, thanks (and sorry for the mis-communication about it)
<mdz> mvo: np, the ball was not in your court
<dholbach> desrt: util: No such file or directory -- weird. is that a typo somewhere? a wrongly substituted variable? a missing build-depends?
<desrt> dholbach; i've made no changes to the package.  this is the one that's currently in edgy :)
<dholbach> desrt: HUM
<desrt> dholbach; basically, oo.o currently has a bug where it always crashes when you try to save
<desrt> https://launchpad.net/bugs/58492
<Ubugtu> Malone bug 58492 in openoffice.org-amd64 "Openoffice.org crashes on "Save"" [Untriaged,Confirmed]  
<_ion> Btw, in the initramfs, scripts/init-top/usplash prereqs "framebuffer", and _both_ mknod /dev/tty{0..8} . That causes error messages.
<desrt> from my understanding of the problem it can be fixed by a rebuild
<seb128> mdz: BTW the xchat-gnome clipboard handling should be fixed, please let me know if you still have issues with 1:0.13-0ubuntu3
<desrt> but i want to test that theory before i go ahead and request a real build
<doko> desrt: I remember about 10GB, but I'm just running a du now 
<doko> ohh, just 8, must be 10 oon powerpc
<mdz> seb128: oh good, thanks
<seb128> np
<desrt> so definitely not 26
<desrt> doko; got any insight into that error that i pastebinned?
<desrt> doko; alternatively, could you please just kick off a build of openoffice?  i'm reasonably convinced that i'm right....
<desrt> and if i'm not then it's no worse off except for a lot of downloading :p
<doko> desrt: no, my build yesterday did succeed
<doko> desrt: see 
<doko> deb http://people.ubuntu.com/~doko/ubuntu/ edgy/$(ARCH)/
<doko> deb http://people.ubuntu.com/~doko/ubuntu/ edgy/all/
<desrt> doko; i mean an official edgy build to fix bug 
<desrt> bug 58492
<Ubugtu> Malone bug 58492 in openoffice.org-amd64 "Openoffice.org crashes on "Save"" [Untriaged,Confirmed]  http://launchpad.net/bugs/58492
<desrt> it's probably something mental like building in en_CA.UTF-8
* desrt cancels
<desrt> doko; ya.  your build is linked against the proper dbus
<desrt> doko; please fire off a rebuild of openoffice.org on edgy, all arches...
<doko> desrt: no, it's not yet ready
<desrt> doko; it can be the exact same one that it already on the mirrors :p
<doko> desrt: it doesn't build with the current b-d's.
<desrt> that would explain why it broke for me :)
<desrt> in any case it's no big rush, i think, since the bug has a workaround for now
<Kamion> Keybuk: hi
<Keybuk> Kamion: are you doing archive day today?  if not, I missed mine on Tuesday so am happy to do it
<bddebian> Bums. ;-P
<Kamion> Keybuk: oh, er, I appear to have forgotten
<Keybuk> Kamion: :D
<Kamion> Keybuk: I'll do a sync pass now, and you can do the rest?
<Keybuk> Kamion: ok, deal
<Keybuk> you do syncs, I'll do queue
<bddebian> *cough*debian multimedia*cough*
<elmo> Kamion: unimportant ping about old-releases
<Kamion> bddebian: *cough*scared*cough*
<HiddenWolf> mjg59: you asked people to report broken usplashes, right?
<sladen> dholbach: it was distributed in bluez for hotplug for ages in Debian main.  
<bddebian> Kamion: :)
<sladen> dholbach: I built that when we switched to udev;  but that must have been getting on for a year ago
<Kamion> plus it's not configured in sync-source right now
<mjg59> HiddenWolf: Yes
<dholbach> sladen: ok, I'll archive it
<HiddenWolf> mjg59: I don't see usplash since my upgrade an hour ago.
<HiddenWolf> mjg59: dapper-edgy
<HiddenWolf> one min
<HiddenWolf> mjg59: back, still no usplash
<mjg59> HiddenWolf: What hardware, and what version of usplash?
<HiddenWolf> mjg59: nforce4 mobo, nvidia 6600gt, amd64 proc, running i386 ubuntu, usplash 0.4-20
<mjg59> i386 Ubuntu?
<mjg59> Ok, interesting
<mjg59> I'll see if I can reproduce
<HiddenWolf> mjg59: I did get a working usplash on today's daily-live, so it might be something relating to my upgrade
<Seveas> mvo, ping
<mvo> hello Seveas
<Seveas> mvo, hi. How smart is apt when it has to install lots of packages from several cd's at the same time? Does it ensure people don't need to juggle their disks around a lot?
<Treenaks> Seveas: try installing Debian and see :P
<Seveas> Treenaks, I'd rather find out without jumping through hoops and mvo knows apt rather well so asking him is the easy way ;)
<Treenaks> Seveas: lazy! :P
<Seveas> (btw: it could simply be the iso creation tool that does the effort to minimize disk juggling, so installing debian wouldn't give a definite answer)
<mvo> Seveas: yes, it should order the install so that it requires a minimum amount
<mvo> Seveas: multiple CDs are pretty common for debian
<Seveas> mvo, great! That just saves me a lot of work
<mvo> Seveas: there might be bugs though :) but in general it should work well
<gnomefreak> Seveas: stick with ubuntu only 1 disk to juggle :)
<Seveas> gnomefreak, I'm actually working on something to create .iso images
<gnomefreak> ah
<Seveas> and apt being smart is nice, then I don't have to be
<gnomefreak> lol
<gnomefreak> how hard would it be to take installed packages and create a iso so i can install it as it
<Seveas> gnomefreak, dpkg --get-selections | grep -v deinstall | cut -f 1 -d ' ' | xargs apt-get -d install --reinstall && mkisofs /var/cache/apt/archives /tmp/packages.iso 
<Seveas> (sort of)
<gnomefreak> hmm if that works (will try later) i might play with that make script of it and see thank you
<Seveas> gnomefreak, it won't work as is 
<_ion> kamion, keybuk, mjg59, seveas: /lastlog -regex _ion.*usplash :-) Any idea why usplash refuses to use the 1024x768 resolution?
<Seveas> _ion, -ELASTLOGFAILED
<_ion> < _ion> I looked into the "usplash never comes up" problem a bit: e.g. /sbin/usplash -c -x 800 -y 600 shows the splash, but /sbin/usplash -c -x 1024 -y 768 says "screen init failed". /etc/usplash.conf seems to contain "xres=1024", "yres=768".
<_ion> < _ion> Btw, in the initramfs, scripts/init-top/usplash prereqs "framebuffer", and _both_ mknod /dev/tty{0..8} . That causes error messages.
<Keybuk> _ion: I don't keep lastlog
<Keybuk> (and don't know anything about usplash's current resolution code)
<sladen> Keybuk: irssi should do by deafult?
<Keybuk> sladen: I don't use irssi, and if I did, I would have modified its configuration to not keep lastlog like I do with X-Chat
<gnomefreak> lol
<_ion> /lastlog greps the scrollback buffer.
<Keybuk> if people want to ask me something, they should bloody well e-mail me, not leave it in the middle of a busy IRC channel and "hope I read it"
<Keybuk> _ion: yes, I only keep ~10 lines of scrollback
<Keybuk> just enough to fill the screen
<Seveas> _ion, i386/ppc?
<Keybuk> (this is the same reason I /QUIT from IRC, rather than use a proxy or screen)
<_ion> seveas: i386.
<Seveas> and 'screen init failed' is the only message?
<_ion> Yes.
<_ion> I'll try to add some debug printfs to the source.
<_ion> seveas: It might be worth mentioning, that during shutdown, usplash does become visible (using 640x400 i guess).
<Seveas> usplash_svga.c, see which of vga_init/vga_setmode fails
<_ion> Thanks, will do.
<Seveas> hmm, usplash_down should now use /etc/usplash.conf too
<Keybuk> jdub: we killed advogato, we are bad people
<desrt> oh score!
<desrt> the fix for the openoffice bug is also the fix for the vmware player bug
<_ion> seveas: vga_setmode (12) returns -1
<Seveas> does your display not support that resolution?
<_ion> That's what i'm using in X. :-) It would support higher resolutions as well, but they get a bit too blurry.
<Seveas> then I have no clue unfortunately
<Seveas> mjg59 has done the difficult things
<Seveas> I merely implemented a few bling-bling enhancements
<iwj> Keybuk: I take it that you're responsible for the initscripts package being split off from sysvinit ?
<iwj> Package: initscripts
<iwj> Conflicts: mdutils, sysv-rc (<< 2.86.ds1-1.2), sysvinit (<< 2.86.ds1-12)
<iwj> Replaces: mdutils, sysvinit (<< 2.85-12), libc6, libc6.1, libc0.1, libc0.3
<iwj> Note carefully the different version numbers in the relationships to sysvinit.
<iwj> Is that a mistake ?
<Keybuk> iwj: err, initscripts was split off from sysvinit about a decade ago
<Keybuk> it may, of course, be a mistake ... in which case, we inherited it from Debian
<iwj> Keybuk: Oh.  Hmm.  The package in dapper matches the Conflicts but not the Replaces.
<iwj> This is almost certainly some kind of mistake.  I think I'll not fix it by introducing a Breaks in sysvinit on Friday evening though :-).
<iwj> I'll investigate some more in the meantime.  Thanks.
<bluefoxicy> Can we get --enable-compositor passed to Metacity and have it off by default?
<bluefoxicy> err, passed to ./configure for metacity.
<Amaranth> bluefoxicy: No, if someone checks that box and can't use it metacity crashes and won't come back until you uncheck it.
<bluefoxicy> "Not yet enabled by default, new compositing affects are only available when Metacity is compiled with the special --enable-compositor option."  "Once Metacity is compiled with the correct option, the effects can be turned on and off without a restart or new login, and applications can take advantage of this. For example, the GNOME terminal can now offer real transparency."
<Amaranth> Plus from what I've seen on the forums metacity's compositor almost never works and you usually end up with a blue screen
<bluefoxicy> Amaranth:  ah, ok, so it's brokenshit instead of sane enough to tell you it won't work
<bluefoxicy> "The new compositing features also depend on support for the GLX_texture_from_pixmap extension, which is only available to owners of Intel i830 to i945, and ATI Radeon 7000 to 9250 chips at the present time."
<Keybuk> omg, Google are evil
<Keybuk> I was just looking at one of those domain pages which just lists search results related to the domain
<Keybuk> squatter/parked things
<Keybuk> and it turns out that it's Google that are doing that now
<Keybuk> http://www.google.com/domainpark/
<HiddenWolf> Keybuk: yeah, well, they have to show double-digit growth, the pressure is on. :)
<Treenaks> Keybuk: Google doesn't filter its own adsense results from normal searches?!
<doko> Kamion: the ada changes are just python2.3 / python2.4 stuff.
<doko> desrt: ok, I can the build failure now as well. no clue at the moment ...
* BenC loves the new theme backgrounds
* jdong agrees with BenC... and the sounds are pretty nice, too :)
* _ion too </aol>
<BenC> yeah, the new login sound is cool
<jdong> ooh, "dawn of ubuntu"
<zul> not so brown..
* jdong misses the depressing shades of brown a la warty :)
* Treenaks misses the naked people a la warty ;)
<jdong> BenC: oh btw, when will lifeless and I get the dm-bbr love?
<Seveas> Keybuk, do you have time to do an usplash upload required to get the themes in?
<BenC> jdong: it's in the dapper upload that is just about on it's way up
<BenC> jdong: and it will be in the next edgy upload too
<jdong> BenC: very nice, thanks so much
<Keybuk> Seveas: not right now
<Seveas> ok, then it'll have to wait and I'll work around it in the themes
<jdong> BenC: btw, I noticed that the mc/smt powersavings patch was reverted....
<BenC> jdong: no problem
<jdong> BenC: curiousity prompts me to ask about it :)
<jdong> what is/was it?
<BenC> jdong: yeah, it needed a lot more patches with it, was causing compile failures
<jdong> oh, I see
<BenC> and didn't have time last minute to track it down
<BenC> the main thing, the multi-core, is still there
<jdong> k, cool
<jdong> so you'll probably try again with that in a future kernel update?
<Seveas> Treenaks, NudeBuntu
<BenC> jdong: I'll check and see what all is needed...it may turn out that it's just too much backporting
<jdong> k
<jdong> BenC: would you expect Edgy kernels to build/work under Dapper?
<BenC> jdong: build: no, work: yes
<BenC> the latest edgy kernel should install no problem on dapper
<jdong> k, cool
<jdong> would you expect that situation to change through edgy's lifespan?
<BenC> things like lrm are a different story (because of nvidia and ati userspace stuff)
<BenC> jdong: probably not
<jdong> I'm trying to figure out what's the best thing to recommend to forum users running Dapper who are looking for newer kernels
<jdong> most of the time for hardware support reasons
<jdong> I'd rather not send them out to kernel.org compiling their own vanillas...
<BenC> jdong: if they aren't using ati/nvidia video, they should be ok to use edgy kernels
<BenC> jdong: but preferably, we should backport needed hw support
<jdong> that'd be sweet, yes
<jdong> but I don't think that'll always be possible
<jdong> i.e. what will it take to get the tifm21xx drivers compiling under 2.6.15?
<_ion> Btw, sudo settings should default to "Defaults insults". :-)
<_ion> I just can't help smiling when, after mistyping the password, sudo says something "rude" instead of a boring standard error. :-)
<BenC> jdong: what is that driver for?
<jdong> TI 5-in-1 FlashMedia cardreaders, pretty common in newer laptops
<BenC> jdong: probably fairly easy
<jdong> last time I tried, it complains about not finding some structures in the kernel... going to 2.6.16+ fixed the compile errors :-/
<BenC> jdong: it's a lot easier to add a new driver, and update an old one, since it never worked, something is better than nothing
<BenC> jdong: probably just some trivial name changes and such
<jdong> ah, I see
<jdong> then is dapper's kernel open to new features like this?
<BenC> yes, because it is LTS, we'll do some easy backports
<BenC> pitti: !!
<pitti> hi BenC 
<BenC> pitti: dapper kernel is being packetized to security.upload.ubuntu.com at this very moment
<BenC> pitti: one quirk, the ABI actually needed bumping for i386/amd64, but since it was only one symbol change, and not something that any module used, I forced it not to
<jdong> BenC: very cool. As far as tifm21xx, should I open up a launchpad ticket for that, or will you handle it from here? :)
<Kamion> doko: ada> ok, but please put that in the bug; I might not be doing the next round of syncs
<BenC> jdong: lp, give it a keyword dapper-backport
<jdong> BenC: k, will do. thanks for your time
<Trae> Keybuk, are you around bud?
<pitti> BenC: *phew* :)
<Trae> Keybuk, I'm on SLED 10.1  and wanted to know if there was any testing I can do to maybe help out that Ubuntu Power bug.
<mvo> mdz: regarding bug #56141, I will make all the linux-headers in the seeds recommends, ok? 
<Ubugtu> Malone bug 56141 in ubuntu-meta "Edgy ubuntu-desktop depends on linux-headers-686" [Low,Confirmed]  http://launchpad.net/bugs/56141
<Trae> this thing is driving me up the wall and I'm ready to go back to Ubuntu
<mvo> BenC: when will linux-headers-i386 become linux-headers-generic?
<Trae> it's only been 6hrs so far.
<Trae> heh
<Trae> but it hasn't powered off on me viewing any video
<Trae> :(
<mvo> BenC: thanks a lot for the vmware modules merge \o/
<mdz> mvo: the ones in server and ship don't need to be changed, only desktop
<Trae> https://launchpad.net/bugs/22336
<Ubugtu> Malone bug 22336 in acpi-support "laptop overheats when performing CPU intensive tasks." [High,Confirmed]  
<Trae> this is the bug I speak of.
<Trae> :D
<mvo> mdz: ok, but I will change powerpc, amd64, ia64, sparc and hppa as well, right?
<mdz> mvo: yes
<Kamion> ah, I know what I can do
<Kamion> I can promote console-setup to minimal and then go off for the weekend
<Kamion> superb
<Trae> I'd love to help out with any test you guys might be able to think of... but if noone has anthing I'm nuking this and going back to Ubuntu
<Trae> I'm a fish out of water
<Trae> heh
<Trae> Been using Ubuntu (and Debian) apt-based systems for TOO long
<Keybuk> Trae: tbh, I've no idea from this point ... you really need mjg59
<Trae> Keybuk, ahhh :(
<Trae> mjg59, you here?
<Trae> Keybuk, tx btw for all the help
<mdz> GRRR xchat-gnome changes its keyboard shortcuts AGAIN
<Seveas> sorry, but lol 
<jdong> lol
<Trae> hah!
<Trae> Keybuk: it just did it on SLED 10.1!!
<Trae> Keybuk: as I said, I didn't have any problems compiling Gentoo for like 24hrs almost 
<Trae> now THAT is odd
<Kamion> mdz: just to check with you: promoting console-setup to minimal involves promoting xkb-data to minimal and thereby x11-common
<Kamion> not actually any of X proper, of course, just some of the base scripts
<Trae> mjg59: if you see this... my laptop just locked up on SLED 10.1 too
<Kamion> mdz: this seems reasonable to me given that we're now generating console keymaps from X keymaps, but I wanted to check before Just Doing It
<mdz> Kamion: it's a bit large but as far as I can see it's mostly changelog
<mdz> Kamion: isn't xkb-data obsolete?
<mdz> it seems to be empty on my system
<Kamion> that's a mistake
<Kamion> at the moment the actual data is in xkeyboard-config even though that's allegedly transitional
<Kamion> there's a bug filed about it
<mdz> I see
<Kamion> xkb-data is the new name
<mdz> @#!$!#@$! xchat
<mdz> anyway, the size of x11-common is pretty manageable compared to the xkb data
<zul> lol
<mjg59> Trae: Ok, thanks
<Kamion> perhaps we should take the old Debian changelog out of x11-common
<jdong> mdz: what on earth do you keep pressing? :D
<mdz> jdong: control+w, of course
<Kamion> and for that matter out of all the binary packages by now - it could just stay in the source
<jdong> mdz: and what did you expect that shortcut to do?
<Kamion> jdong: delete word
<mdz> which has been erase-word since the dawn of time
<mjg59> Keybuk: Did you add the code that rewrites kopt lines for the UUID transition? If so, does it also munge the kopt_2_6 line that's now in grub? We've had some people who still have legacy names in there
<jdong> well, since the dawn of the other redmond-based world, that's been close window :D
<zyga> mdz: untill it became close window
<mdz> zyga: which is a lot less useful, and clobbers an existing well-established shortcut without providing any replacement
<jdong> mjg59: yes, /me had legacy device names with knot2's installer, caused by kopt_2_6
<jdong> mdz: ctrl+bksp?
<zyga> mdz: hail to the standard of the majority :/
<Kamion> mdz: the other possibility is putting console-setup in standard rather than minimal, but I'm less comfortable with that from an installer point of view, so I'll probably just go with what I've got
<mdz> jdong: that doesn't work in anything but gtk programs
<mdz> Kamion: ok
<jdong> picky picky picky :)
<Kamion> does meta-backspace work in xchat?
<Kamion> hmm, doesn't work in irssi
<Kamion> must just be a bash/readline thing
<mdz> Kamion: no, it doesn't
<zyga> heh
<mdz> not even with gtk-theme-name = "Emacs"
<zyga> masters of ubuntu arguing over erase-word keybinding :)
<jdong> :)
<mdz> ah, gtk-can-change-accels to the rescue
<Trae> why isn't the ability to select between Emacs and Default gtk-key-teme an option in the keyboard configs?
* jdong wouldn't be surprised to see a mdz-edition of xchat landing in edgy-changes :)
<mdz> I don't mind having to override its shortcuts once, but it should respect  my choice after that
<zyga> why should every program behave like emacs?
<Trae> uh oh
<jdong> ooh, is now a good time to rehash vim-tiny vs vim-full? :D
<zyga> bah.. I already feel where this is going
<zyga> ignore me
<mdz> zyga: they shouldn't, and given that ^W isn't an emacs shortcut, I don't know what you're talking about
<Trae> mdz: when was the last time you nuked your xchat2 configs?
<mdz> Trae: when I moved from xchat->xchat-gnome
<mdz> that is, during dapper
<mdz> I don't even know where gtk-can-change-accels stuff is stored, probably buried in gconf somewhere
<Trae> mdz: that might be a xchat-gnome build issue, cause it always keeps the Emacs for me if I set it to gtk-key-theme
<Trae> mdz: go to occy.net/search
<Trae> mdz: search for: Emacs
<Kamion> mdz: how does the bit at the end of https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Proposals look to you?
<Trae> mdz it'll show you how to change it in gconf-editor
<mdz> Trae: I did that about a year ago
<Trae> mdz: if you re-install, you lose it :)
<Trae> *chuckle*
<mdz> it's still set, and still honored by everything but xchat, which overrides it
<Trae> sorry, just trying to help
<Trae> mdz: I'd beg to differ with you, I have no problems
<Trae> mdz: the only difference between you and I?  I don't use xchat-gnome
<Trae> at least I don't think I do
<Kamion> Burgwork: I put a console-setup item on the UWN proposals page
<mdz> Trae: I beg to differ that that's the only difference between us
<Trae> mdz: hahaha
<mdz> or our systems either
<Seveas> mdz, I finished putting together uubuntu and kubuntu usplash themes for the art team, which are due today. However, they need someone to uplad both them and a fixed usplash (there is one new revision in my usplash branch that they need) -- fschoep is not here right now so who should I talk to for that?
<Trae> mdz: I am slightly better looking
<Trae> *chuckle*
* Trae hides
<Riddell> Seveas: I can upload
<mdz> Seveas: the usplash changes should go through mjg59 if he is around
<mdz> Seveas: dholbach generally handles the artwork uploads, though he may have left for the day
<mdz> (for ubuntu)
<Seveas> mdz, ok, then this is all waiting for mjg59 
<mdz> Riddell: if you wouldn't mind uploading the ubuntu themes as well, that'd be appreciated
<Trae> mdz: I'd be happy tohelp you debug that once I get my system back and setup
<Trae> mdz: debug meaning try things for you, I can't code, but I can try stuff
<Seveas> Riddell, actually, the themes can be uploaded -- they build fine, I just made them uninstallable by depending on a newer version than currently in the archive
<Trae> I know how horrible it is not having Emacs keybindings
<Riddell> Seveas: where can I get them?
<Seveas> one sec
<Trae> zyga: and bash isn't "emacs"  yet you can still do:  ctrl+u to clear a line,  ctrl+a and ctrl+e etc.. to get to front and back of lines... those are the thins "Emacs" keybindings give you in forms with it set in gtk-key-theme
<mdz> Trae: I've fixed my problem already using gtk-can-change-accels and filed a bug about the issue
<mdz> (bug 59563)
<Ubugtu> Malone bug 59563 in xchat-gnome "Unixish keyboard shortcuts stopped working again" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59563
<Trae> mdz: ok... I'm quite certain it's a config issue.... on your part, but I could be 100% wrong
<Seveas> Riddell, http://blackbird.kaarsemaker.net/~dennis/usplash/
<Kamion> Trae: working configurations shouldn't be broken by upgrades, as a general rule
<Keybuk> Seveas: btw, what does that upload change?
<mdz> Trae: it isn't.
<Keybuk> Seveas: or is it new packages?
<Seveas> Keybuk, the ones for riddell are 2 new packages
<Keybuk> what's the usplash upload?
<Seveas> the usplash fix they need is preventing a segfault if a theme doesn't link in its own font
<Seveas> +a small fix in the example theme
<Seveas> the diff is very small
<Keybuk> heh
<Riddell> Seveas: any rationale for having separate packages?
<Seveas> Riddell, none other than laziness
<Riddell> Seveas: i.e. new packages rather than the ones we were using previously
<Seveas> Riddell, they should be merged imho but kwwii and fschoep came to me about an hour ago to create this and this was easiest to do before having to get some sleep
<Riddell> Seveas: previously ubuntu usplash was in just "usplash" as far as I know, and kubuntu was in kubuntu-default-settings
<Seveas> ah, but art packages are split up all over the place
<mdz> Kamion: are we using the 'linux' metapackage in the installer?
<Trae> Is there a Project Manager who can help guide those of us without Coding backgrounds into areas that need help?
<Trae> I would love to get more involved and help out.
<Seveas> mdz, xubuntu and edubuntu still don't have an usplash theme and I haven't really heard anything from them -- can they go in after feature freeze?
* Trae wonders if that is what Jono is for
<Trae> heh
<Kamion> mdz: not at present - base-installer knows what kernels are preferred on what CPUs
<Kamion> and picks the best one it can
<Trae> that and REALLY scary singing
<mdz> Kamion: does it know that there is now only one preferred kernel on i386 and amd64?
<mdz> I think most of the stuff it installs are now compatibility packages
* pygi thinks he should have -tao soon :)
<mxpxpod> desrt: ping?
<mjg59> Seveas: Oh?
<mjg59> Seveas: What do I need to pull from your branch?
<mdz> Keybuk: when I upgraded my desktop to upstart, it became unable to reboot due to having the upstart commands but sysvinit running
<Seveas> mjg59, 1 revision (if lp already shows it)
<Riddell> Seveas: does the postrm not need to update alternatives?
<mjg59> Seveas: Ok
<mjg59> Seveas: What does it fix?
<Seveas> Riddell, I took the postrm from the old usplash -- I found it odd too
<Kamion> mdz: could you please file a bug with the details? I reduced it to -386 and -generic on i386, and just -generic on amd64
<Seveas> <Seveas> the usplash fix they need is preventing a segfault if a theme doesn't link in its own font
<Seveas> <Seveas> +a small fix in the example theme
<Seveas> <Seveas> the diff is very small
<Kamion> mdz: oh, no, -generic and -server on amd64, add -server and -server-bigiron on i386
<mjg59> Seveas: Ok
<AlinuxOS> Hello All, mjg59 have some minutes ?
<Kamion> mdz: it will prefer -generic on i386 on anything with a 586 or better
<mjg59> Seveas: What's your repository again?
<mjg59> AlinuxOS: Hi - what's up?
<Seveas> bazaar.launchpad.net/~dennis/usplash/theming
<AlinuxOS> https://launchpad.net/distros/ubuntu/+source/ttf-bpg-georgian-fonts/+bug/55966 here, finally it works...a trick is found.
<Ubugtu> Malone bug 55966 in ttf-bpg-georgian-fonts "ttf-bpg-georgian-fonts.conf problem." [Untriaged,Confirmed]  
<mjg59> AlinuxOS: Ok, cool
<mdz> Kamion: my understanding was that the only reason to use anything other than -generic was to get the legacy drivers which don't work with SMP
<mjg59> AlinuxOS: I'll do something about that
<mjg59> AlinuxOS: I'm afraid I can no longe rupload to Debian, though
<mdz> where is BenC?
<Kamion> well, I'm away for the evening, anyway, so I can't talk about this now ...
<Kamion> I'll get back to it on Monday if I don't hear anything in the meantime
<Keybuk> mdz: yes, fix is in bzr; will upload once I've finished debugging this other problem
<AlinuxOS> mjg59, there is Arne Goetje-s comment + updated control, defoma-hints, postinst and prerm scripts. 
<Kamion> mdz: it should be moot though - every system we care about will use -generic
<mdz> Keybuk: what's the fix?  sounds tricky
<AlinuxOS> mjg59, why not for Debian ? 
<mdz> Kamion: enjoy the weekend
<mjg59> AlinuxOS: I'm no longer a member of Debian
<Keybuk> mdz: giving the upstart shutdown command enough marbles to try sending an old-style initctl message if it gets ECONNREFUSED from upstart
<Kamion> ta
<AlinuxOS> mjg59, what about Ubuntu ? :)
<Kamion> I still think we should figure out how to get upstart to gracefully be re-execed by sysvinit :-)
<mjg59> AlinuxOS: Can manage that
<AlinuxOS> mjg59, I'm sorry for that...
<mjg59> Keybuk: Did you see my question about grub and uuid stuff?
<mdz> mjg59: current usplash seems to still clobber the console on my T42
<mjg59> mdz: I'll look into it
<Keybuk> mjg59: no, what is the question?
<mdz> mjg59: any info I can provide?
<mjg59> Keybuk: kopt in grub gets changed to have UUIDs
<Keybuk> Kamion: it's not actually that hard... the problem is that upstart would think all the jobs were stopped
<mjg59> Keybuk: kopt_2_6 doesn't seem to
<Keybuk> Kamion: and might then start doing odd things, like starting more gettys
<Keybuk> mjg59: oh
<Kamion> GETTYS FOR EVERYONE
<Kamion> anyway, really gone
<mjg59> Keybuk: Biting new installs rather than upgrades, but has hit us because some machines went from sda to hda (small kernel screwup)
<mjg59> mdz: 1400x1050 system?
<Keybuk> mjg59: file a bug, subscribe me, I'll look into it
<mjg59> Keybuk: Ok
<mdz> mjg59: 1024x768
* Keybuk goes to cook dinner
<mdz> I also see some very odd behaviour where the boot process hangs
<mdz> but resumes on ctrl+f1
<mdz> I'm going to have sshd start earlier and see what's up
<mjg59> mdz: Are you sure you're on latest usplash?
<mjg59> And latest kernel?
<AlinuxOS> mjg59, what a paradox there is 0.3 version of ttf-bpg-georgian-fonts for Debian and 0.2 version(old with no fonts.conf) in Ubuntu (Dapper and Edgy) repository ;)
<mdz> mjg59: hmmm
<mdz> mjg59: usplash 0.4-20, 2.6.17-7
<mdz> I'm regenerating initramfs manually to be extra sure
<mjg59> mdz: Ok
<Burgwork> Kamion, thanks! I will add it
<ogra> why does our initramfs supply a /usr/share/initramfs-tools/conf.d/ dir ?
<ogra> apprently its not used 
<mdz> ogra: /usr/sbin/mkinitramfs:for i in ${CONFDIR}/conf.d/* /usr/share/initramfs-tools/conf.d/*; do
<Riddell> Seveas: I can upload the kubuntu splash as part of kubuntu-default-settings, are you sure we want a new package for the ubuntu splash?
<mdz> mjg59: I think it might have become confused due to -386 sorting ahead of -generic
<mdz> and regenerated the wrong one
<ogra> mdz, well, it doesnt work ...
<mdz> mjg59: console seems to be OK
<Seveas> Riddell, kubuntu is your call -- do what you see fit. For Ubuntu all pieces of the artwork have been split up so I assume this has to be a separate package as well
<mjg59> mdz: Ah, ok
<Riddell> Seveas: ok
<mjg59> mdz: That would make sense
<ogra> i have to put my file into /etc/initramfs-tools/conf.d/ to make it work
<mdz> ogra: given that they're used on exactly the same line, it seems likely that something else is wrong
<ogra> weird
<mdz> ah, I see
<AlinuxOS> mjg59, I think that even if you don't update that package for Debian - it still can be usable for debian. right ?
<mjg59> Seveas: Ok, uploading
<mjg59> AlinuxOS: Yes
<mdz> ogra: look at the lines after that in mkinitramfs; it later assumes they're all in $CONFDIR
<mdz> apparently no one ever tried to use that feature before
<ogra> right :)
<mdz> ogra: what are you trying to do?
<Seveas> mjg59, \o/
<mjg59> Seveas: Feel free to get the themes dealt with
<mjg59> Seveas: They probably want an appropriate depends line
<AlinuxOS> mjg59, ok so just somone from debian could update it :)
<mjg59> AlinuxOS: Sure
<ogra> mdz, dropping the sed calls to change mkinitramfs.conf from ltsp and put a proper file in to change the options
<AlinuxOS> Why no more you ? Some political issue ? 
<ogra> mdz, 
<mdz> ogra: any reason not to put it in /etc as a conffile so the admin can change it?
<ogra> root@edubuntu:/# cat /etc/initramfs-tools/conf.d/ltsp 
<ogra> MODULES="netboot"
<ogra> BOOT="nfs"
<ogra> thats where i got it now
<ogra> i like to avoid conffiles if possible ...
<ogra> if you think it makes sense to make it one i'll keep it in etc
<ogra> but i think we should ship it in usr and rather make mkinitramfs perfer the files from etc
<ogra> so the admin can drop in an ltsp file to override the default
<ogra> s/an ltsp file/an ltsp file in the etc dir/
<mdz> Keybuk: splash-down seems pretty broken at the moment; is that due to teardown, upstart or both?
<mjg59> mdz: The difference in resolution is because usplash doesn't get called with the resolution arguments
<mdz> mjg59: argh, false alarm, my console is broken after all
<mjg59> I've no idea why only the second phase of it appears
<mjg59> mdz: Hm
<mdz> with current kernel, usplash and initramfs
<mjg59> I'll try testing with Daf's T42 when he gets back, but it's the 1400x1050 model
<mdz> it was a recovery mode boot before
<mjg59> mdz: If you go to a console and do sudo vbetool vgamode 3 does it get your text back?
<Seveas> mjg59, actually I went ahead with the themes prematurely -- the kubuntu one is upladed as part of kubuntu-default-settings, the ubuntu one is in a new package, so needs some NEW massaging
<mjg59> Seveas: Ok
<mdz> mjg59: yes, it does
<mjg59> mdz: Hmph. Right.
<mjg59> mdz: In that case, in theory usplash is doing precisely that
<mdz> mjg59: but then switching to X and back breaks it again
<mdz> so perhaps it's X and not usplash at all
<mjg59> mdz: Haha.
* Riddell just about to upload usplash-theme-ubuntu
<mjg59> It is possible that it's X
<ogra> mjg59, hey, that helps here too ... no stripes anymore
<mjg59> ogra: ?
<mjg59> ogra: Using which version of usplash?
<ogra> mjg59, i told you i have stripes and no chars on the console 
<ogra> not the most recent one 
<mjg59> ogra: Yes, and I fixed that on the similar hardware I have here
<mjg59> Right
<ogra> i upgraded, but didnt reboot yet
<mdz> ogra: does switching to X break it again?
<ogra> yes
<mjg59> Gah. I wonder if X is doing something mad like saving register settings at startup and not afterwards.
<mjg59> That sounds implausible, though.
<mdz> ogra: which X driver?
<mdz> I'm using ati
<ogra> me too
<ogra> oh, no, wait
<mjg59> It's fine on the only ati hardware I have
<ogra> i lied
<ogra> i use fglrx atm
<mjg59> Oh, in that case it's almost certainly X
<mjg59> Graphics bugs which involve the use of binary-only drivers are likely to get ignored, I'm afraid
<ogra> the stripes look the same with ati though ... thats why i tried to switch
<Seveas> it breaks here on dapper/fglrx from ati.com too
<mjg59> It's fixed in -18
<ogra> (my card has no 3d support in fglrx so i wouldnt use it normally)
<jdong> hmm usplash behaves ok with my fglrx/edgy and dapper's usplash worked fine with fglrx, too...
<jdong> since -18
<jdong> except for the 16-color ordeal
<mdz> ogra: do you know why gnome-screensaver only recommends the screen hacks, instead of depending on at least one
<mdz> ?
<mdz> oh, I suppose blanking is built-in
<ogra> yep
<ogra> i dont have any hacks installed in edubuntu
<ogra> a hard dep would make that impossible ...
<ogra> g-ss also supplies two or three own savers
<ogra> (the flying gnome feet for example)
<Riddell> xubuntu usplash uploaded, someone else will need to do the artwork though
<Riddell> ogra: want me to do edubuntu?
<ogra> Riddell, whats the change ? 
* ogra thinks he mised something
<Riddell> ogra: there's a new usplash
<ogra> *missed
<ogra> yes
<Riddell> with new usplash plugins needed
<ogra> aha
<ogra> where and when was that announced ?
<ogra> did i miss a mail ?
<ogra> Riddell, anyway, if you got something ready, go ahead 
<Riddell> it's not been announced by e-mail, it's what we've been discussing on this channel for the last our
<ogra> ah, i juat came back 
<ogra> *just
<ogra> and am busy fixing the last small ltsp breakages
<mjg59> AlinuxOS: Ok, there's an issue here
<AlinuxOS> mjg59, only in your case ? Or it's a general problem ?
<mjg59> Installing that package has changed my default GTK fonts even without me having a Georgian locale
<mjg59> Which isn't really acceptable
<mjg59> Let me see if I can figure this out
<mjg59> Yeah, it's giving me BPG fonts
<AlinuxOS> mjg59, hm...
<AlinuxOS> for me everything is ok here.
<mjg59> AlinuxOS: But you're expecting the BPG fonts, right? :)
<mjg59> The latin characters in them are less well formed than the default font we use
<mjg59> So it can't override those
<AlinuxOS> mjg59, normally BPG don't changes latin charachters...there is georgian unicode range, so only georgian unicode range is changed.
<mjg59> AlinuxOS: Rioni very definitely contains latin characters
<ogra> mjg59, any opinion on bug 29527 ?
<Ubugtu> Malone bug 29527 in gnome-power-manager "brightness is not associated with any graphical indicator (such as volume one)" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/29527
<mjg59> ogra: It probably needs my patch removing
<ogra> do you think i should disable the patch for a test ? 
<ogra> ok
<ogra> thats what i thought ...
<mdz> mjg59: I'm definitely using ati and not fglrx
<AlinuxOS> mjg59, http://alinuxos.no-ip.org/geo.png - Here is ok. Maybe it changes it but in Georgian contecst, it loooks great. There was no laments about this issue.
<mdz> ogra: can you try with ati?
<ogra> mdz, if the g-p-m build finished ...
<mjg59> AlinuxOS: But it *breaks* non-Georgian contexts
<mjg59> And so I can't upload it
<mjg59> I'm looking into this now
<AlinuxOS> mjg59, thank you.
<mdz> mjg59: your theory about X saving the regs at startup it looking pretty plausible
<mdz> booting without usplash, it switches fine
<mdz> booting with usplash, it's destroyed
<mjg59> mdz: But usplash is setting it to text mode before X starts. Hmm.
<mjg59> AlinuxOS: So, before:
<mjg59> tyrosine% fc-match
<mjg59> DejaVu-Sans.ttf: "DejaVu Sans" "Book"
<mjg59> And after:
<mjg59> tyrosine% fc-match 
<mjg59> BPGRioni-Regular.ttf: "BPG Rioni" "Regular"
<mjg59> That is, it's changed my default font
<AlinuxOS> mjg59, hm...is it font problem ?
<mjg59> AlinuxOS: No, fontconfig
<mjg59> I assume
<mdz> mjg59: is it?  when X starts, usplash is still up and goes all funny
<mjg59> mdz: Erm.
<mjg59> mdz: That's really not meant to happen.
<mdz> mjg59: what's meant to stop it?
<mdz> as far as I know it's always been that way
<mjg59> svgalib/src/vga.c, __svgalib_releasevt_signal
<mdz> except for the going all funny, which I assumed was related to vesa
<mdz> mjg59: isn't that triggered by X starting, i.e. it's already too late?
<ogra> gdm usually stops it
<mjg59> mdz: Yes, but X isn't supposed to be fucking with the VTs until after that
<mdz> ogra: I don't think gdm even knows usplash exists
<ogra> see the gdm initscript
<mjg59> Also, what ogra said
<mdz> oh, so it does
<ogra> in a horrible way by calling start :(
<mdz> it used to know about usplash_down but seems broken
<mjg59> mdz: Ok. If you go to the console (while it's broken), then run usplash and then switch away, does it work?
<mdz> mjg59: usplash_quit() in init.d/usplash doesn't
<mjg59> As in, does usplash exit and text mode get restored?
<mdz> oh, I booted without splash
<mdz> mjg59: yes, switching away from usplash dtrt
<mjg59> Ok
<jdong> GRR... for the 28th time this hour, xchat and gaim did NOT crash @$@!$@!$!
<mjg59> So it sounds like there's an issue with the gdm and usplash interaction here
<jdong> what source package do I file the crash notification applet under?
<tseng> jdong: the crash applet itself?
<tseng> jdong: apport
<jdong> tseng: thanks
<mdz> mjg59: ok, I've reproduced it
<jdong> god this is the most annoying thing since WGA....
<mdz> mjg59: after disabling the /proc/cmdline check in usplash_quit (I'm not sure why it's needed anyway), it fails to kill usplash with TERM and ends up KILLing it
<mdz> which produces the garbled screen
<mdz> er
<mdz> fails to kill usplash with usplash_write QUIT that is
<mdz> this is completely a local problem
<mdz> ignore me
<mjg59> Mm?
<mjg59> What was up?
<mdz> mjg59: /usr/local/sbin/usplash_write.  I assume the fifo location changed or something
<AlinuxOS> mjg59, in case if there is some problems to find an optimal solution... https://launchpad.net/distros/ubuntu/+source/ttf-bpg-georgian-fonts/+bug/55966 you can ask to Arne Goetje. He helped me a lot to figure out howto to manage general georgian fontconfig.
<Ubugtu> Malone bug 55966 in ttf-bpg-georgian-fonts "ttf-bpg-georgian-fonts.conf problem." [Untriaged,Confirmed]  
<mdz> that's what that weird hang was; it was init.d/usplash watiing before killing usplash
<mdz> consoles and usplash are both OK now
<mdz> so I wonder what ogra's problem was
<mdz> maybe he, like me, 'make install'ed usplash a year or so ago and forgot about it
<mdz> actually I don't know how I ended up with that, probably debugging
<mdz> ogra: my problem turned out to be a stray /usr/local/sbin/usplash_write
<ogra> oh
<mdz> usplash wasn't getting shut down properly
<ogra> well, its the same behavior with the ati drive fwiw
<ogra> *driver
<mdz> ogra: check that usplash is getting shut down before X starts
<ogra> well, gdm should do that no ?
<mdz> ogra: check
<ogra> its not running
<ogra> but i need to update and reboot anyway, as i said when we began ...
<Seveas> Riddell, did you use ubuntu or kubuntu for xubuntu? 
* ogra does that now
<Riddell> ogra: the edubuntu-artwork buildsystem is too complex for me, you'll need to do it yourself I'm afraid, copying the files out of kubuntu-default-settings
<Riddell> Seveas: kubuntu
<ogra> Riddell, i'll look after i got ltsp done
<mjg59> mdz: ogra hasn't rebooted with a new usplash
<Seveas> Riddell, someone was working on a proper edubuntu theme iirc
<Bluhd> I've got a problem with acloca
<Bluhd> *aclocal
<ogra> Seveas, yes, cbx33 
<Bluhd> whenever I run it, I get this:
<Bluhd> macro `AM_PROG_LIBTOOL' not found in library
<Bluhd> libtool is in fact installed
<Seveas> cbx33, ping
<mdz> mjg59: gdm used to run /sbin/usplash_down to dtrt during shutdown, but that doesn't exist anymore
<mjg59> Oh, that's interesting
* mjg59 wonders why it's vanished
<mdz> mjg59: the makefile doesn't install it
<ogra> i think it changed in dapper already
<ogra> i had a prob with ldm back then and i think it was seb who told me to stop it via the initscript in ldm's
<mdz> after copying it into place, splash-down seems to work nicely again
<mdz> well, the first stage
<ogra> (which brought me an ugly bug i have now in dapper ltsp)
<mdz> then it reverts to low res mode
<mdz> I can fix that though
<Bluhd> Hello?
<mdz> Bluhd: this channel is for development of the distribution itself, not for help with doing development on ubuntu
<Bluhd> oh
<Bluhd> ok
<Kamion> usplash-theme-ubuntu> I'm going to need to adjust the preseed file on our CDs to install that
<Kamion> but it can wait until tomorrow
<bluefoxicy> heh I've crashed firefox 50 times in the past half hour.
<cbx33> pong Seveas 
<cbx33> pong ogra 
* bluefoxicy goes to tell the Epiphany guys they need to get gnome-webcore back alive and make it work as a back-end
<Seveas> cbx33, how's the edubuntu usplash theme going?
<bluefoxicy> stupid gecko goes nuts with a lot of dhtml re content management system administration.
<cbx33> just getting the ideas together havn't start putting it down on paper yet
<cbx33> ogra, did you get anywhere with SCP?
<bluefoxicy> probably just race conditions everywhere, and those 611 "defects" and 74 "security holes" or whatnot.
<cbx33> Seveas, hopefully going to do that tomotrrow
<ogra> ?
<ogra> nope
<ogra> pitti apparently didnt review the MIR
<cbx33> ahh....ok
<Seveas> cbx33, I though deadline was today?
<cbx33> does this mean we're confined to Universe?
<bluefoxicy> (anything where i can load the application too much and make it crash I immediately assume is probably a race)
<cbx33> Seveas, we had a setback in the artwork for edubuntu
<cbx33> not all the people working on it, turned in work....as a result we're playing catchup
<cbx33> 've jumped in to helpout, even though my artwork skills are limited
<cbx33> ogra, are you happy with the higher Ed wallpaper?
<Seveas> cbx33, ok -- here's a deal: provide me a 600x800, 1024x768 and 1365x768 version of the same background png and I'll put the theme together. Make sure a brown progress bar fits with the theme for now
<cbx33> Seveas, you are a star !
<ogra> is there a new one or are you referring to the one you showed me ? 
<cbx33> ogra, yes
<cbx33> the one I showed you?
<ogra> Seveas, brown ??
<cbx33> comments suggestions
<ogra> Seveas, is that necessary ` 
<ogra> ?
<Seveas> ogra, I already have a brown progress bar in png so that's easiest
<cbx33> Seveas, can I alter the images in your pacage to provide a diff colour
<Seveas> kubuntu-blue is also possible
<cbx33> I'll mod the pngs if that's ok?
<Seveas> sure!
<ogra> Seveas, the current one i see in edubuntu is the edubuntu red one
<cbx33> just hue them up to our scheme
<Seveas> provide me another progrss bar and I'll use it
<cbx33> thanks Seveas you really rock !
<Seveas> I'm just that bad with graphics that there is no way I can create one myself
<cbx33> Seveas, heheh
<cbx33> I'm not that great myself
<cbx33> photography is my art outlet....
<cbx33> and the ubuntu sounds of course ;P
* ogra can make one over the weekend, i just didnt look at the new usplash at all yet ...
<cbx33> ogra, I don;t wanna lumber it on you
<Seveas> ogra, I can put it together in minutes
<cbx33> you've done enough
<Seveas> Have done it three times now ;)
<cbx33> I'll get it sorted
<cbx33> Seveas, I'll sort that out for you
<ogra> cbx33, its fine for now (the wallpaper), but i guess we'll need sabdfl approval since our artteam hasnt really shown much before the freeze
<Seveas> cbx33, mail images to dennis@ubuntu.com -- I'll be offline for a large portion of the day tomorrow
<cbx33> ogra, i apologise :(
<ogra> cbx33, not your fault ...
<cbx33> I tried to stir interest...contacted some people who sasid they were interested...but got very little back
<cbx33> :'(
<ogra> stop apologizing for everything :) you did awesome work with SCP, the sounds gisomount etc ...
<cbx33> not but I do feel I've let you guys down
<cbx33> heh
<ogra> you didnt 
<cbx33> I'm an apologetic guy ;)
<cbx33> I'll try to work a lot tomorrow on them
<cbx33> lisa will be working on them too
<cbx33> we should have a lot more to show for it....it's been crazy here...my brother i law has moved in today for 2 weeks while his parents are on holiday
<cbx33> ogra, how do you want to work usplash....
<cbx33> if we get images...want to approve before they goto Seveas ?
<ogra> its not your fault that the artteam we once had got silent ...
<ogra> yes you are
<ogra> without any reason for that :)(
<ogra> :)
<coyctecm> i need help, where metacity checks the timeout(or something) where it looks is window responding or not
<ogra> i'd like to see them, yes, but approval lies in either sabdfls or the artleaders hands
<cbx33> ok
<cbx33> art leader being Lisa or Frank?
<cbx33> oh and ..... just for my own piece of mind....do you thin kSCP will be universe this release now?
<ogra> frank ... but i guess he'll refer us to sabdfl
<ogra> cbx33, no idea, it completely depends on pitti 
<ogra> he knows that i'd like it on the CD
<ogra> and he knows it was submitted as MIR eary enough ...
<cbx33> ok cool
<cbx33> hehe funny the sounds sabdfl kinda just commented and let me and Frank choose
<ogra> thats fine 
<cbx33> but I'm quite close with Frank so I'll get him to check them over
<ogra> i think lisa can decide herself since she's artteam lead, but the final call will be sabdfls anyway
<cbx33> ok
<cbx33> we knew that....the sabdfl thing
<cbx33> ogra, just so as ...well.....do you have anything you'd like us to try for the artwork
<mdz> mjg59: do you have access to any machines where ondemand doesn't work, so we can develop a test for that?
<cbx33> and you mentioned about the manga one and religion.....is there something we can do to modify it more to your liking...?
<mjg59> mdz: Having checked the code, I believe that The Right Thing will already happen
#ubuntu-devel 2006-09-09
<pygi> I want someone familiar with autotools to gimme a hand :) anyone raises hand?
<mjg59> Trying to set the ondemand governor will fail
<mjg59> So powernowd will start instead
<mdz> oh, I missed your powernowd upload
<mdz> I had partially implemented the same thing locally
<mdz> but was unable to test it
<mjg59> Ditto, but I'm pretty happy about how the code works
<mdz> thanks for doing that
<mjg59> You get EINVAL back if you try to set ondemand and it doesn't like the system
<tseng> is the init scripts status not being printed to be blamed on usplash or upstart?
<mjg59> tseng: usplash will now not print anything unless you remove the quiet argument
<mjg59> Which is consistent with the upstart behaviour
<tseng> mjg59: ah, cool
<tseng> was out of town all week, I seem to have missed all the fun
<mjg59> So, other than a couple of regressions in suspend, I'm pretty happy with how edgy looks for laptops
<tseng> mjg59: regressions related to screen blanking, perhaps?
<tseng> mine are back, need to work on it this weekend
<mjg59> tseng: Yeah, possibly
* pygi spams the channel once again with need for autotools expert
<cbx33> right I'm off to sleep so I can start artworking early tomorrow....ogra if you have any comments on that manga piece, we were planning to use that for youg persons theme.....please email to either me or lisa......;)
<ogra> cbx33, ok
<cbx33> as I know you had a few issues with it...
<cbx33> some suggestions on changes would be great
<Burgwork> mjg59, do you ever feel like your fighting a contant uphill battle?
<mjg59> Burgwork: Nah
<mjg59> Though tracing suspend regressions in the kernel is a bit of a pain
<mjg59> Other than that, I think we're heading forwards pretty quickly
<Keybuk> mdz: none of the above, afaik
<mdz> Keybuk: correct, it was a combination of my broken system, a usplash bug and an initscripts bug
<mdz> all three are fixed now
<mdz> it still flickers but basically works
<desrt> doko_; messed up, eh?
<desrt> mxpxpod; pong
<doko_> desrt: there's no room for schadenfreude. if you know the reason, please tell it. kthxbye
<desrt> schadenfreude -> ?
<Spads> desrt: "shamefun", or taking joy in the suffering of others
<shackan> desrt, it's german for "being happy about other people's suffering" (roughly)
* desrt is confused
<Spads> desrt: slapstick humor is "shadenfreude"
<desrt> doko; i'm not happy that your build is broken :p
<Spads> (as an example)
* mjg59 fixes fontconfig
<mjg59> Why is nothing ever easy?
<desrt> mjg59; damned if i know
<hikenboot> hello all anyone know what this means---when copying between two hardrives with konqueror ---ERROR: SlavePool: No communication with slave.
<ogra> Seveas, i made an edubuntu version based on the kubuntu usplash theme, i thought we dont need indexed images with the new version ?
<Seveas> we do
<Seveas> but 256 colors instead of 16
<ogra> ah
<Seveas> and all images have to use the exact same palette
<Seveas> (which is not too difficult to accomplish with the gimp)
<desrt> wow.  mjg59 is famous
<desrt> he has a wikilinked mention in the Debian page on wikipedia
<desrt> (but no page yet)
<mjg59> Haha
<mjg59> Write me one
<desrt> "mjg is really cool and probably made your laptop work."
<desrt> i think i might get NPOV'd :p
<Fujitsu> Should the free ATI driver have hardware 3D support?
<tseng> Fujitsu: not really
<tseng> its pretty poor
<Fujitsu> Because evolver crashes with the free driver, as in bug #45190.
<Ubugtu> Malone bug 45190 in evolver "Graphic display error when running evolver" [Medium,Needs info]  http://launchpad.net/bugs/45190
<Fujitsu> What should be done with that?
<mjg59> Fix the r300 driver
<Fujitsu> mjg59, that would be the ideal solution... But what should I do with the bug?
<mjg59> Fujitsu: See if it's fixed in edgy. If not, it needs to go upstream
<Fujitsu> Isn't it more of a bug in the driver, though?
<Fujitsu> As it works fine with fglrx.
<mjg59> ...
<mjg59> Erm
<mjg59> Yes, it's a driver bug
<mjg59> See if it's fixed in edgy. If not, it needs to go upstream.
<Fujitsu> Oh, you mean driver upstream?
<Fujitsu> Oops.
<Fujitsu> OK.
<mjg59> Yes, sorry
<Keybuk> hmm
<Keybuk> why have my consoles lost their colour?
<Keybuk> Sep  9 01:55:32 rc2: setupcon: not found
* Keybuk blames Kamion
<Keybuk> hmm, and usplash keeps hanging on shutdown
<bddebian> Heya
<adamant1988> hello all
<mjg59> Nngh.
<mjg59> It's /something/ to do with the APIC, as far as I can tell.
<Amaranth> mjg59: What is?
<mjg59> The failure of this machine to suspend/resume
<mjg59> If I disable apic support, it seems happier to work
<mjg59> But:
<Amaranth> oh
<mjg59> It worked fine with apic support in our 2.6.15 kernel
<Amaranth> that's always fun
<mjg59> Need to try upstream 2.6.15
<Amaranth> see if it's something you added to 2.6.15 or something you took away from 2.6.17?
<mjg59> Yeah
<Hobbsee> Kamion: yes krename sync is fine.  trust me w.r.t dh_iconcache only changes - i did most of them.
<Hobbsee> Kamion: we only figured out that we could stick them into cdbs *after* we'd done a lot of them.
<Hobbsee> grumble :P
<Hobbsee> well, a whole heap of the universe ones anyway
<Mez> any devs around want to push a patch to main for me?
<Mez> tiny patch - just to fix bug 52690
<Ubugtu> Malone bug 52690 in xchat "Please use irc.ubuntu.com alias for default IRC server" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52690
* netjoined: irc.freenode.net -> brown.freenode.net
<cbx33> if I have Edubuntu meta installed but I want to check out the ubuntu usplash - how can I do it?
<StevenK> cbx33: Remove edubuntu-artwork-usplash and reinstall usplash?
<cbx33> ah cool ye forgot about that
<StevenK> cbx33: However, other things might want edubuntu-artwork-usplash around.
* jdub boggles at new startup sound.
* tseng boggles at the new art being considered an improvement
* jdub is going to wait for a diplomatic mood and raise that on the art list
<jdub> particularly for the gdm theme :|
<tseng> jdub: thanks
<tseng> jdub: I don't have the patience, myself
* jdub goes crazy trying to get firefox/flash sound
<tseng> jdub: for a good time, call https://launchpad.net/distros/ubuntu/+source/f-spot/+bug/34074
<Ubugtu> Malone bug 34074 in f-spot "Dapper becomes unstable when disk full after f-spot import" [Medium,Confirmed]  
<jdub> ha ha
<jdub> so i've done the libesd.so.1 thing
<jdub> no dice
<tseng> i turn off esd
<tseng> close all sound apps
<tseng> start firefox with oss
<tseng> if the stars are aligned, that usually works
<jdub> 'with oss'?
<tseng> out of the box
<tseng> never did any tricks
<jdub> mine is spawning esd
<tseng> seems i have esd running again as well
<tseng> cute
<tseng> its nice that gstreamer can just sort it out now, at least
<jdub> hrm, i have to convince alsa to use the other device
<jdub> maybe that's what's confusing it
<tseng> jdub: btw just ordered an all-intel d620
<tseng> jdub: core2 for freedom lovers
<Treenaks> I just killed an out-of-control apport (yay crashing firefox..)
<Treenaks> but I got an _ugly_ OOPS from the kernel..
<Fujitsu> That seems to happen, Treenaks.
<Treenaks> Fujitsu: scary..
<giftnudel> Treenaks: apport was not ooc, it just takes forever
<giftnudel> Treenaks: or at least that happened to me
<Treenaks> giftnudel: still, I had to kill it
<giftnudel> Treenaks: why? I mean, how could you tell?
<Treenaks> giftnudel: because it was eating all my swap, and my laptop wasn't responding to anything else
<giftnudel> Treenaks: at least the second part I can remember, the first not ;), but it really seemed to me "more" ooc ;)
<Hobbsee> hey Keybuk 
<Keybuk> hey
<Fujitsu> Good evening, Keybuk.
<Keybuk> afternoon
<Hobbsee> Keybuk: oh yes, i remember what i was going to bug you about.
<Hobbsee> Keybuk: are the fixing kde's shutdown button to actually work on your plans at all?
<Hobbsee> looks like that entire dialog is now disabled
<Hobbsee> i would expect, due to upstart
<Keybuk> Hobbsee: it should be fixed
<Keybuk> I've got nothing to do with dialogs being disabled or anything
<Keybuk> I have an allergy to C++, so wouldn't have touched that
<Hobbsee> Keybuk: right, i'll see what's happened elsewhere then.
<Hobbsee> heh, right
<StevenK> Keybuk: You break out in hives?
<Keybuk> StevenK: yeah, get a template of a rash
<StevenK> Boo hiss!
* StevenK throws something at Keybuk
<seb128> does anybody knows if /etc/network/interfaces has to be ISO-8859-1 encoded and if essid can be can contain a non-ascii utf-8 encoded char?
<Treenaks> seb128: I remember seeing a bug about that by Mithrandir
<cbx33> thanks for the uopload seb128
<Treenaks> seb128: so I'd ask him :)
<seb128> cbx33: np
<seb128> Treenaks: thanks for the pointed, remember on what package and if that was Debian,Ubuntu,other?
<Treenaks> seb128: I think it was either the Gnome network config tool (gnome-system-tools?) or wireless-tools
<seb128> Treenaks: I'm looking at bug #27171 in fact
<Ubugtu> Malone bug 27171 in system-tools-backends "[network-admin]  non-ASCII WLAN SSID breaks network-admin" [Unknown,Unconfirmed]  http://launchpad.net/bugs/27171
<Treenaks> yes
<Treenaks> but that's not Mithrandir's bug :)
<tormod> yes I filed that one :)
<seb128> tormod: from where did you get it has to be ISO-8859-1 encoded?
<tormod> seb128, trial and error I guess
<seb128> tormod: that doesn't mean it has to be
<seb128> tormod: either a policy or reference says it has, or the apps should handled it being utf-8 just fine
<tormod> seb128, how would the app know it is utf-8?
<seb128> tormod: how would it know it's iso-8859-15 :)
<tormod> seb128, :) Is there no standard for non-ascii in gnome?
<seb128> utf-8 is the standard
<seb128> not only for GNOME
<tseng> seb128: (are we going to really leave apport on for release?)
<tseng> seb128: (this is very painful)
<seb128> we switched to utf-8 by default for hoary
<seb128> tseng: stop complaining, thank you :p
<tseng> :(
<tseng> i have been trying to kill banshee for 20 minutes, literally
<tseng> I cant
<seb128> tseng: when a software has bugs they got fixed instead of removing the software
<seb128> I think pitti is doing a decent job on apport
<seb128> your request is not fair to him
<seb128> let him know your issues and give him a chance to fix them
<leolein> Hello, Is there any people who speak german?
<tormod> leolein, ubuntu-de
<tseng> seb128: i didnt request anything, its just a very large overhead added, atm I cant seem to even kill it at all. I will wait for pitti
<tormod> seb128, then the problem is that iwlist returns iso-8859-1 instead of utf-8
<seb128> the only complain I've about apport it's the few seconds of slowdown when it creates the dump
<tseng> this is not a few seconds at all
<seb128> tormod: I would think that too
<seb128> tseng: depending of the box and the software probably
<tseng> killing apport can also make your kernel panic
<tseng> this is an extreme case, but its been 20 minutes
<tseng> I can't kill the app
<seb128> weird
<jdong> tseng: I feel your pain... apport usually locks up my mouse for a few seconds when it makes its report
<tseng> the few seconds is kind of annoying, but not the kind of thing I would complain about
<leolein> tormod: I know. But I have a question to anyone who build pakets for ubuntu. Exemple, if there is someone who build pakets from the Gimp 2.3 Releases.
<seb128> leolein: not at the moment, we are going to use 2.2.n for edgy
<leolein> okay. Thank you
<seb128> np
<tormod> seb128, in the end what counts: the user types the same character in his wifi router configuration (through a web browser most of the time) and in network-admin. There is a long chain between... iso-8859-1 in the interfaces file works.
<seb128> tormod: right, and my understanding is that the network stack should deal with it being ut-8
<seb128> utf-8
<tormod> seb128, should ifupdown translate it? Otherwise both wireless-tool and linux-wlan-ng (possibly others too) have to be fixed separately.
<seb128> no idea, I'll talk with Mithrandir about it monday
<HiddenWolf> mjg59: what information do you need for a "usplash doesn't come up" bugreport?
<mjg59> Version of usplash, version of kernel, full hardware information
<HiddenWolf> mjg59: dmesg / lspci? 
<mjg59> Yeah
<HiddenWolf> coming right up
<seb128> mjg59: I've reinstalled my edgy, usplash works fine now on my desktop, was probably something broken after the /etc/rc[0-6] .d by services-admin
<Treenaks> mjg59: on a bug report?
<Treenaks> mjg59: (if yes, a specific one? which one?)
<HiddenWolf> seb128: I seem to have the same issue, usplash stopped working since dist-upgrade, works on live-cd
<HiddenWolf> mjg59: ^^
<mjg59> Treenaks: ?
<mjg59> Oh, right
<mjg59> No, please file new bugs
<Treenaks> mjg59: ok
<mjg59> If it works on the live-cd, then it's probably a transient issue of some sort
<HiddenWolf> mjg59: I'll file a bug and mention that, ok?
<mjg59> Yeah
<seb128> mjg59: is the rectangle supposed to fit the screen BTW? If yes, are you interested by bugs about it takjng only like half of it?
<mjg59> Which rectangle?
<seb128> mjg59: the test image, that's a rectangle with all sort of drawing
<mjg59> No, that's expected
<HiddenWolf> mjg59: https://launchpad.net/distros/ubuntu/+source/usplash/+bug/59651
<Ubugtu> Malone bug 59651 in usplash "usplash does not come up after dapper-edgy upgrade" [Untriaged,Unconfirmed]  
<seb128> ok
* Hobbsee tickles Mithrand1r 
<_ion> http://www.nasa.gov/55644main_NASATV_Windows.asx Atlantiksen laukaisu kai reilun tunnin pst.
<_ion> Sorry, wrong channel.
<Treenaks> _ion: already watching :)
<Treenaks> (Atlantis tuning pasta?!)
<HiddenWolf> seb128: sorry to bug you again, but do you know if upstream epiphany changed the behavior of the adress bar? prevously (dapper) you could type in the adress bar to search google, now I get "server-refused-connections"
<seb128> it's due firefox 2.0
<HiddenWolf> ack.
<HiddenWolf> firefox killed epi's best feature.. :/
* Treenaks hands HiddenWolf a tissue to cry into
<HiddenWolf> someone hide all blunt objects, please
* HiddenWolf feels violent urges
<_ion> Searching from the URL bar works without a hitch for me.
<HiddenWolf> _ion: on edgy?
<HiddenWolf> _ion: it triest to resolve everything to a .com for me.
<HiddenWolf> tries*
<_ion> hiddenwolf: Do you mean the "I'm feeling lucky" search? Type "? search-query" to the location field.
<seb128> HiddenWolf: what do you call "gnome-keyring from the menu"?
<HiddenWolf> seb128: system > administration > keying manager
<seb128> HiddenWolf: does it ask for a password?
<seb128> it does here
<seb128> doesn't
<HiddenWolf> it does, if you haven't provided that password earlier in the session
<HiddenWolf> IE, if you haven't emailed using evo
<seb128> why should it close if you refuse it the access to the keyring?
<seb128> evo doesn't close if you refuse it access to the keyring
<seb128> neither do nautilus
<HiddenWolf> no.
<HiddenWolf> but if you cancel gksudo it goes away, and doesn't leave a non-functional program on your screen. if you cancel the password prompt for gnome-keying, you are left with an empty window on your desktop
<Treenaks> seb128: nautilus just keeps asking lots of times if you refuse access
<Treenaks> or it did, last time I refused
<seb128> HiddenWolf: the point is that we are not using gksudo there
<seb128> HiddenWolf: and it does that because you can't use the admin tools without sudo
<HiddenWolf> I know, but the behavior is inconsistent with other programs from the menu
<seb128> HiddenWolf: you can use that program without keyring
<HiddenWolf> seb128: i'm not talking about using evo without keying
<seb128> it's consistant with how the program work
<HiddenWolf> i'm talking about launching keyring and not tying the password
<HiddenWolf> that leaves a greyed-out keying on the desktop
<seb128> and?
<seb128> why should it close?
<seb128> it's usuable without it
<HiddenWolf> it's odd and inconsistent.
<seb128> would you reply to my question?
<seb128> why should we close a program than can work?
<seb128> just to be consistant with admin programs that can't work without sudo?
<seb128> that doesn't seem to be a solid argument to me
<seb128> and the keyring password dialog doesn't look like a gksu screenfading one
<seb128> so it's not that inconsistant
<HiddenWolf> seb128: ah, i see, there is some stuff that you can do, but there is no option to open the keying still, which is odd. An empty window is odd too.
<HiddenWolf> seb128: it just confused the hell out of me.
<seb128> k
<seb128> I'm closing the bug, that's not one ;)
<HiddenWolf> fine. I'll file some upstream about oddness later on.
<HiddenWolf> I do feel that deny should be cancel tho, in the other bug.
<seb128> right
<HiddenWolf> It's cancel everywhere else.
<seb128> though "deny" makes sense
<HiddenWolf> it's inconsistent.
<seb128> the GNOME HIG recommends to set explicit actions on buttons when possible
<seb128> like no OK, Cancel for everything
<seb128> "Deny" make sense in that context
<Treenaks> so the other buttons are strange?
<seb128> which one?
<Treenaks> 16:21 <  HiddenWolf> It's cancel everywhere else.
<HiddenWolf> Arguably, but cancel makes sense too, since you're cancelling your action, changing your mind.
<seb128> you didn't do an action
<Treenaks> HiddenWolf: yes, but that's not really what you're doing.. you're denying.. it's more specific
<seb128> you start an app
<HiddenWolf> you're not thinking "hey, i don't need to type my password, so lets deny that request, and go make a new keyring"
<seb128> the action is starting the app
<seb128> then the app ask for permission granting
<seb128> you accept or deny that request
<seb128> you don't cancel your action of start the app
<seb128> where for gksu you cancel your action
<seb128> it makes sense to me and seems to be coherent
<HiddenWolf> I disagree, but it's your call
<seb128> I've a rationnal
<seb128> you are not going to convince anybody by disagreeing without argumenting
<seb128> that would be rather upstream talk ;)
<HiddenWolf> I don't see how I can, and I seem to disagree with the entire design of the app that I've seen so far. so I'll bug @gnome.org
<seb128> ok, thank you
<HiddenWolf> Well, at least my other 2 bugs today are valid. :)
<seb128> enough work for today, bbl
<pef> hello
<Chipzz> ugh
<Chipzz> if I'm allowed to say so: the new gnome-session splash looks HORRIBLE
<Chipzz> and some people do have other backgrounds than the standard brown, so it is *NOT* ok to have semi-anti-aliassed corners half part of the splash
<HiddenWolf> Chipzz: I guess #u-artwork would be more appropriate
<Chipzz> yea prolly
<Chipzz> just ranting :P
<Chipzz> </rant>
<Chipzz> on an unrelated note, grub doesn't show the menu anymore for some reason
<Chipzz> (when pressing escape)
<bddebian> Heya folks
<bluefoxicy> oooh
<bluefoxicy> gotta love the APSL section 12 subsection 1 clause C :)
<bluefoxicy> 12.1 Termination. This License and the rights granted hereunder will terminate:
<bluefoxicy> "(c) automatically without notice from Apple if You, at any time during the term of this License, commence an action for patent infringement against Apple; provided that Apple did not first commence an action for patent infringement against You in that instance."
<bluefoxicy> i.e. if you sue them over patents in the code and they're not already suing you over patents in something, you can't use the code anymore :D
<bluefoxicy> which is rather benevolent if you think about it; they're covering their ass saying you can't sue them, but they're leaving themselves open in the case where they're the aggressor, creating the good faith that they won't initiate such hostilities.
<bluefoxicy> (oh, and yeah, there's a clause in the beginning that says any patent or intellectual property held by any contributor including Apple placed into the code is granted for global use to everyone under all cases with no restrictions)
* bluefoxicy is looking at Apple's allocator.
<Kamion_> bluefoxicy: it might look fluffy, but it's nasty. If they infringe a legitimate non-software patent of yours - any patent - then you can't sue them without losing the right to distribute all APSL-licensed software
<Kamion_> don't be deceived into thinking it's benevolent; there are much better-written patent termination clauses in other licences that only activate if you sue over a patent covering that particular code
<bluefoxicy> Kamion_:  Mm.  Interesting.  You're correct of course.
<bluefoxicy> I had misread that clause based on their definition of intellectual property
<bluefoxicy> It's indeed a global statement.  How vicious.
<bluefoxicy> Kamion_: Oh well, I'm designing something much better over this morning's coffee anyway, as great as Apple's allocator is.
<bluefoxicy> http://steel-malloc.sourceforge.net/web/index.php?page=links
<sbalneav> Hmm, something must have changed for xkeyboard-config.  It depends upon xkb-data, but it's not included in one of the meta packages (ubuntu-minimal, I think), and therefore breaks the ltsp-build-client script badly.  Is ogra usually around on the weekends?
<shawarma> I
<shawarma> whoops
<Deeah> abiword saves as *.abw as default, wouldn't it be better to have it save as .odt(open document format) by default?
<bluefoxicy> yes.  Does it support OpenDocument Text yet?
<Deeah> The version in edgy does
<Deeah> The version in dapper probably does not.
<Deeah> (not sure)
<HiddenWolf> Deeah: does, but not properly
<bluefoxicy> Does it support it well?
<jdong> Deeah: Abiword's odt support is not good
<Deeah> ahh, so that's why
<Deeah> ok
<jdong> lots of formatting gets lost
<bluefoxicy> ah.  There's your answer ;)
* jdong wishes it had better odt support :)
<bluefoxicy> (i.e. it does not support ODT)
<jdong> but abiword's team has made their position clear that doc support is their #1 priority :(
<Deeah> .doc(Word)? or document formats?
<jdong> .doc (MS word), yes
<jdong> :-/
<Deeah> That's sad. :(
<jdong> it is sad
<Treenaks> feature-wise it;s a good goal
<jdong> no kidding
<jdong> replacing ms word is a nice goal
<jdong> if they can succeed at doing that, I'll applaud them
<Treenaks> but odt support would also be nice ;)
<jdong> no kidding
<Treenaks> What we need is an infinite number of developers!
<jdong> :)
<Treenaks> Banging away on an infinite number of keyboards
<HiddenWolf> jdong: well, it's a start, but they need a hell of a marketing campaign. :)
<jdong> HiddenWolf: they need to make their product work :)
<jdong> portableapps will take care of the rest
<HiddenWolf> jdong: abi is nice already
<jdong> damn, a 5MB self-extractable that turns into a MS word replacement
<jdong> HiddenWolf: it's nice, but it's not good enough to be a word replacement yet
<jdong> I use abiword whenever possible
<jdong> but it still is far behind OOo when it comes to MS Word compatibility
<HiddenWolf> I have tostick to OOo unfortunatly :)
<jdong> OOo is a gigantic monster though
<jdong> especially under windows
<HiddenWolf> mostly because of the interface of ooo, which you can drag and drop nicely to fit your habits.
<jdong> the poor OS wasn't built to support such an app :)
<HiddenWolf> yeah, abi is much nicer, but I like OOo's ui. :)
<HiddenWolf> at least I like that I can minimize the toolbars to what I like. :)
<jdong> anyone know if we're getting new dapper/edgy kernels soon?
<jdong> I've heard a dapper kernel is on the way to dapper-security
<Deeah> I would use abiword if it supposed odt better. But it doesn't so I'm sticking with OO.o
<jdong> OOo does a pretty good job of handling abw, while abiword is really portable (i.e. doesn't take much to put it on a USB stick)
<jdong> so I try to use abiword whenever possible
<jdong> I've encountered Windows boxes that choke on portable OOo before
<jdong> not to mention it takes up way too much of my thumb drive
<Treenaks> choking on OOo is not hard
* jdong is unfortunately blessed with using windows boxes
<Treenaks> imho the OOo devs need an 'Xorg-like' kick in the nuts
<jdong> ooo is one huge beast
<pygi> jdong, heh :)
<Deeah> You can get a 2 gig thumb drive on newegg.com for $42 iirc
<Treenaks> jdong: exactly, as X used to be
<jdong> Deeah: size is not the only issue...
<jdong> speed is the other one
<Treenaks> jdong: one good kick (license change) fixed that
<Treenaks> it's still not as good as we'd like it to be
<jdong> I'm not waiting 2 minutes for a simple text document to load up :)
<Treenaks> but it's been split into manageable chunks
<jdong> well, it's still a big beast, as big as before :)
<jdong> and don't get me started java bashing
<Treenaks> jdong: it's now a chunked beast, with several people, al taming different parts of it
<jdong> frankly GCJ has not been the most helpful thing in terms of speed :P
<Treenaks> jdong: instead of one stagnant team trying to fix everything
<Deeah> Well Sun promised to open source java in October
<jdong> freedom, yay, awesome... but speed... no
<Deeah> October is in 3 weeks
<jdong> Deeah: do you honestly think us Debian/Ubuntu folk are gonna be ok with whatever license sun stamps on it ;)
* jdong very pessimistic today
* Treenaks gives jdong some happy pills
<Deeah> jdong: Well they went out of their way to talk with Debian etc, and they seem to want to cuddle some developers
<jdong> Treenaks: it's called vicodin 12.5/750, and I'm already taking them for my aching joints :)
<Deeah> So I wouldn't be suprised if it's a dfsg compatible license
<jdong> Deeah: let's hope so
<Treenaks> jdong: 12.5/750? that sounds like my first modem (1200/75) :P
<jdong> trappist: 12.5mg of narcotic goodness, 750mg of tylenol to burn out your liver
<jdong> s/trappist/treenaks
<Treenaks> jdong: ooh, gratifying
<jdong> it is
<jdong> I have no idea why "euphoria" is listed as a side effect
<jdong> I'd say that's a part of the pill's job
<Treenaks> jdong: 'FINALLY! IT'S GONE!'
<jdong> euphoria is good amist extreme pain :)
<Treenaks> extreme pain--
<jdong> yes, extreme pain and arthritis really does suck
<Treenaks> this is confusing
<Treenaks> jdong here.. jwang on #catalyst (irc.perl.org)
<jdong> lol
<Treenaks> jdong: you 2 conspired to do this, didn't you? :P
<jdong> oh great, the prefetch myths are starting again....
* jdong hates the other side of his life, as a windows admin
<Treenaks> jdong: prefetch or prelink?
<jdong> windows's prefetch
<Treenaks> windows prefetches?
<jdong> that c:\windows\prefetch directory?
<Treenaks> never heard of it
<jdong> people keep on believing it's a good idea to empty it out
<jdong> Treenaks: it's actually amazingly good technology, if you take the time to research it
<jdong> basically it's like our readahead, only the lists are dynamically generated by monitoring application loading
<Treenaks> ok
<jdong> each file in the prefetch directory contains the files that are loaded when a program is started
<Treenaks> and clearing that dir negates its effects..
<jdong> sorted by location on disk
<Keybuk> how do they avoid dynamically monitoring the previous prefetch? :p
<jdong> so not only do files get preloaded, but it also reduces disk seeking
<Keybuk> we actually have something like that
<jdong> it's one of the reasons XP was faster than 2000
<Keybuk> boot with the "profile" kernel command line option
<jdong> Keybuk: prefetch/preload?
<jdong> Keybuk: yes, we do, I'm not saying we don't :)
<Keybuk> jdong: why the "only" then?
<Keybuk> like our readhead, only ...
<jdong> Keybuk: our readahead doesn't dynamically reoptimize itself based on user activity
<jdong> Keybuk: and our readahead doesn't look at disk layout to prevent seeking
<Keybuk> yes it does
<Keybuk> (both)
<Keybuk> we don't enable the former because it's damned slow on Linux to set up
<jdong> k, that's cool to hear
<Keybuk> it's not been very helpful, tbh
<jdong> I've noticed....
<jdong> on one of my systems, turning off readahead actually helps boot time
<Keybuk> Linux is already pretty good at guessing when it needs to readahead things
<Keybuk> reminds me that we haven't generated readahead lists for edgy yet
<jdong> :)
<jdong> hey, my ranting got something accomplished!
<Keybuk> but yeah, we have the stuff to watch the running system for files that are opened, and then sort them by disk position to read in the correct order, etc.
<Keybuk> it's just so slow to run that it's disabled unless you boot with "profile"
<jdong> Keybuk: does the profiled boot save its new list back to /etc/, ready to be used for next bootup?
<jdong> i.e. how would I "refresh" the readahead lists?
<jdong> I'd expect that to be useful if I've done something that would've changed the position of files on my disk
<jdong> i.e. rsync all the files off then back on
<bddebian> Howdy
<zyga> bddebian: hey
<bddebian> Hello zyga
<jdong> Keybuk: nvm, answered my own question looking at the init scripts
* zyga thanks for console-setup to whoever made it
<zyga> hmm, python2.4-doc is not detected by python2.4 at runtime
<jdong> Keybuk: re-profiling my edgy box shaved 10 seconds off my bootup time...
<jdong> and there is certainly visibly less disk seeking
<bluefoxicy> bug #54308 seems to have a fix, which is in upstream CVS as well.
<Ubugtu> Malone bug 54308 in xserver-xorg-video-via "newest edgy via driver breaks" [Medium,Confirmed]  http://launchpad.net/bugs/54308
<Keybuk> jdong: seems not unreasonable to expect
<blaster8> Any kernel gurus?
<blaster8> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/59696
<Ubugtu> Malone bug 59696 in linux-source-2.6.17 "Asus Pundit-R SATA only supports 33MBps operation" [Untriaged,Unconfirmed]  
<blaster8> that's the one
<blaster8> Asking for a 2 line backport from 2.6.18 to support high speed DMA on my mobo :)
<blaster8> It's all in the bug report
#ubuntu-devel 2006-09-10
<jdong> man, having readahead reprofile itself makes a significant impact in bootup speed on ALL of my ubuntu boxes!
* jdong has already written a howto on it
* z\ chiup chiup.
<jdong> lol
<jdub> tseng: rad! what formfactor is that one? 14" inch?
<hikenboot> hello all --there is a package called ubuntu-desktop...it says its unnecessary but removing it will prevent packages from being installed....is this correct?
<azeem> hikenboot: please ask in #ubuntu
<hikenboot> ok sorry
<Xoritor> i have hit a bug... 
<Xoritor> just letting you guys know
<Xoritor> can anyone tell me the proper place to file a bug report for edgy?
<jdong> launchpad.net/distros/ubuntu
<Xoritor> ok well im there already...
<Xoritor> do i have to "sign up" to file a bug?
<Xoritor> i really dont want to do that
<jdong> yes, you have to make a launchpad account
<jdong> sorry
<Hobbsee> !bug
<Xoritor> bleh
<Hobbsee> eh
<jdong> it's not a very demanding form
<Hobbsee> !bug > Xoritor 
<Xoritor> yea but its just annoying
<Xoritor> thx
<Xoritor> i just hate "joining" things
<Xoritor> my issue though so i will not voice my "volumes of issues" here ;-)
<Xoritor> well ill have to wait for "an hour or two" for the message to arrive... even more annoying
<Xoritor> maybe you can answer this question and tell me if i even NEED to file a bug
<Xoritor> Setting up console-setup (1.7ubuntu6) ...
<mbiebl> Kamion_: I was just wondering, why ubuntu-minimal depends on console-tools and console-setup. 
<mbiebl> Do they complement each other?
<Xoritor> it ran for over an hour the first time...  and some long time after that... i think 3 hours
<Xoritor> and this time its running again...
<mbiebl> Seems to me, as if they both do basically the same.
<jdong> Xoritor: it shouldn't run for hours..... :-/
<Xoritor> jdong, thats what i thought!
<Xoritor> heh
<jdong> Xoritor: is your computer reasonably modern?
<jdong> i.e. not below 300MHz :)
<Xoritor> p4 3ghz 2gb ram 
<jdong> LOL, screw that thought!
<Xoritor> wd raptor 74gb
<jdong> holy.....
<jdong> yeah, I suggest bug reporting that... very strange behavior
<jdong> put it on the console-setup package
<Xoritor> k
<Xoritor> thx
<jdong> thx for your patience, sorry about your problems :(
<Burgundavia> mdz: hmm, just noticed edgy schedule has no artwork freeze
<Xoritor> you think using "time apt-get -f install" would be of any use?
<Xoritor> jdong, no problem...
<mdz> Burgundavia: artwork is a feature
<mdz> as written in the edgy release plan spec
<Xoritor> its not a big issue really everything seems to be working fine on that box other than that
<mdz> same issues, same deadlines
<jdong> Xoritor: i don't think timing that would be any use.... console-setup takes less than a second usually
<Burgundavia> ok, which means we are passed the freeze
<Burgundavia> just wondering
<Xoritor> jdong, again thx
<jdong> np
<Xoritor> hmm
<Xoritor> i seem to have found the issue
<Xoritor> the file /etc/default/console-setup does not exist
<Deeah> http://www.rafb.net/paste/results/jagn0J82.html
<Deeah> http://www.rafb.net/paste/results/Sc9zqT18.html
<Deeah> Check the second link not the first, something is wrong with adduser.
<z\> fabbione ping
<Xoritor> hey i fixed it!
<Xoritor> heh
<Deeah> Xoritor: adduser?
<Xoritor> Deeah, no... my issue with console-setup
<Xoritor> jdong, i am prolly still going to file a bug report and post my solution in case it will help others
<jdong> k, sounds good
<jdong> alright, everyone, look out....
* jdong got a brand-new loaner Core Duo T2600 valued at around $3000 bucks.... and is inserting a edgy daily into it
<z\> fabbione ping
<jdong> malone, I'm coming your way :)
<jdong> usplash.... success!
<jdong> sound..... success!
<jdong> damn 1900x1200 looks great
<jdong> you guys are in the clear -- ubuntu is certified working OOTB on this laptop
<mdz> Burgundavia: right, the artwork which is in now should be basically complete, though it will get bugfixes and tweaks as other features will
<jdub> jdong: JDONG CERTIFIED (tm)
<jdong> :)
<jdong> heh, but it does suffer from C3-sleep-whine syndrome
<jdong> meh, hardware problem
<mjg59> We'll go tickless and it'll be fine
<jdong> ooh, when will we go tickless?
<jdong> mjg59: you are gonna make me drool all over this shiny new laptop
<mjg59> Edgy+1, with luck
<jdong> k, cool
* jdong not too discontent with C2 anyway
<Burgundavia> mdz: hmm, ok
<jdong> who does readahead?
* jdong just made some discoveries
<jdong> namely, bootup is faster if readahead is not backgrounded
<jdong> I'd venture to say that's because when readahead is daemonized, it leads to more disk seeking
<Burgundavia> jdong: Mithrandir or Kamion_ woudl be the people to talk to
<jdong> Burgundavia: thx; I'll launchpad it for now
<wasabi> initramfs evms stuff got busted on my system again. root=/dev/evms/root resulted in panic, unable to mount root, no device "evms/root"
<wasabi> prolly just a shell script error.
<wasabi> The following NEW packages will be installed: liboobs-1-1
<wasabi> nice. ;)
<_ion> Preconfiguring packages ...
<_ion> It's just standing there. :-) console-setup.config is eating the CPU. load average: 2.83, 2.35, 1.47
<_ion> root     14449 15.5  0.6   4628  2348 pts/2    R+   06:33   1:38 /bin/bash /tmp/console-setup.config.144313 configure 
<_ion> It's been running for >10 minutes.
* _ion hopes his proposed solution to bug #45385 has been noticed.
<Ubugtu> Malone bug 45385 in edgy-wallpapers "no wallpaper for dual head/very wide screen monitors" [Wishlist,Needs info]  http://launchpad.net/bugs/45385
<Burgundavia> _ion: they are coming. The changelog explicitly mentions it
<_ion> burgundavia: Please read the comment first. The _don't need_ to be coming, thanks to a new feature in Gnome 2.16.
<jdub> _ion: using zoom?
<_ion> Yes.
<jdub> worthy in so many ways
* _ion is using the default edgy wallpaper with its 8:3 (dualscreen) setup, and it looks just fine.
<_ion> s/its/his/
<diana> In edgy can anyone confirm that nautilus doesn't show any files as view list opposed to view as icons? When I go to "View as List" no files show, just blank white.
<diana> View as icons seems to work fine for me, but not view as list. I wanted confirmation before I file a bug.
<diana> Lure: you here?
<Lure> diana: yep
<diana> Lure: You running edgy?
<Lure> yes
<diana> Lure can you confirm for me that nautilus doesn't show any files as view list opposed to view as icons? When I go to "View as List" no files show, just blank white. View as icons seems to work fine for me, but not view as list. I wanted confirmation before I file a bug.
<Lure> diana: I can not - I am running KDE/Kubuntu
<_ion> Worksforme
<Fujitsu> Works for me(r)(c)(tm) as well.
<diana> k, thanks
<_ion> Yay, finally i can remove hplip, the accessibility stuff, the bluetooth stuff and scim while keeping ubuntu-desktop installed.
<mempf> I can't save in openoffice
<mempf> it just crashes, is this a known problem?
<Hobbsee> mempf: is where you're saving to writable by the user?
<mempf> yes
<Burgundavia> Hobbsee: I need a feature for UWN. Got a cool Kubuntu one?
<Hobbsee> Burgundavia: hmmmm....
<imbrandon> Burgundavia, KDE4 Krash "working" on Kubuntu edgy ;)
<Burgundavia> already talked about that
<imbrandon> amarok 1.4.3
<Burgundavia> features are features in dapper
<imbrandon> ah hmm
<Hobbsee> katapult?
<Hobbsee> Burgundavia: katapult would work, if you wanted to
<Burgundavia> can you write up a couple of sentences a screenshot of dapper katapult?
* Hobbsee is doing an assignment.  or will be
<Burgundavia> Hobbsee: ok. imbrandon could you provide the love to me?
<Burgundavia> by provide, I mean write. By love, I mean two or three sentences on what katapult does plus a screenshot
<imbrandon> Burgundavia, sure, do you need it this moment? or do i have a bit ? ( i would need to install dapper in a VM , i only have edgy boxen atm )'
<Burgundavia> imbrandon: you have a great deal of time. By great deal, I mean at least 30 minutes ;)
<imbrandon> Burgundavia, hehe ok
<Burgundavia> seriously, I will find another ubuntu feature, but I like to make certain the derivs get the love too
<imbrandon> Burgundavia, lemme grab a soda and i'll get on it
<Burgundavia> thanks
<Burgundavia> you will even get your name in the editors of this weeks UWN
<Hobbsee> imbrandon: it looks the same
<imbrandon> ;)
<imbrandon> Hobbsee, nah we just added transparency to the new one and i have updated ;(
<imbrandon> Hobbsee, but no biggie
<Hobbsee> bah.  close enough
<troy_s> Anyone have any luck with edgy in vmware-player -- after the updates I can't seem to boot it.
<imbrandon> troy_s, yea its kinda broke atm
<troy_s> eek
<troy_s> well this is booting from dapper.  the edgy image no likey.
<imbrandon> troy_s, the only solution i have found so far is to use the vmware server from the website ( not the packages ) and compile a new kernel module
<imbrandon> ohhhh
<imbrandon> yea edgy i can boot from dapper
<troy_s> grr... have you updated it imbrandon ?
<troy_s> mine is hanging when it is trying to mount /root
<Burgundavia> the vmware issue appears to be a dbus one
<troy_s> yeah i read about the edgy vmware player issues, but it should work fine on dapper.  (although i'm on 64 bit and the 64bit edgy didn't install)
<imbrandon> Burgundavia, ok almost done .....
<Burgundavia> sounds good
<imbrandon> Burgundavia, you'll probably have to proof this descrip, i'm not the best writer but it gets the point accross ;)
<Burgundavia> add it to the page and I will proof it
<imbrandon> yup, almost done
<imbrandon> ok Burgundavia whats the link to the "working" page
<imbrandon> got it ready, well enough for you to "touch-up" hehe
<Burgundavia> https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue13
<jdub> Burgundavia: going to html -> text it for the email this week? maybe do html email?
<Burgundavia> not going todo the second, but I will play with the first
<Burgundavia> I have been thinking about doing it more int he styel fo the gentoo and fedora wn, who only ship a toc
<Burgundavia> s/ship/toc
<Burgundavia> s/ship/mail/ (ok, I am tired)
<imbrandon> Burgundavia, ok text added, now to figure out how to add the screenshot
<imbrandon> lol
<Burgundavia> just add the url, upload it somewhere else
<imbrandon> k
<Burgundavia> moins image handling sucks too much
<imbrandon> ;)
<imbrandon> holy jesus, i put the url and it put it inline , hehe, guess i need to scale it a bit
<Burgundavia> right, then do
<Burgundavia> [image_url thumb_url] 
<imbrandon> ahh ok nice, fixing now
<imbrandon> ok much better, ok i'm done Burgundavia, work your magic ;)
<Burgundavia> imbrandon: cheers
<imbrandon> gah already found a typo , s/atl+spacebar/alt+spacebar please while editing Burgundavia
<Burgundavia> got it
<Burgundavia> imbrandon: can you make a thumb about half the size?
<imbrandon> sure, i'll reupload to the same spot , so it will just pick it right up
<Burgundavia> thanks
<Burgundavia> jdub: I don't see html2txt on the default install. Which package is that?
<imbrandon> ok uploaded Burgundavia, should pick it up on refresh
<imbrandon> err ok NOW uploaded
<imbrandon> my bad 
<imbrandon> heh
<imbrandon> Burgundavia, and i just caught that , mailing just the TOC sounds like a good idea to me, just my .02c though
<Burgundavia> then I can leave it on moin
<Burgundavia> except the wiki has had issues recently
<imbrandon> yea, and you donr have to wory about txt vs html emails
<imbrandon> becouse i personaly prefer html emails ( to those on my list and *.ubuntu.com is whitelisted ) but i can see the reason some dont tbh
<Burgundavia> html email is not going to happen
<Fujitsu> +1 Burgundavia.
<Fujitsu> No. HTML. Mail.
<imbrandon> right, i hear ya, i was just makin a case
<imbrandon> not trying to persuade you
<imbrandon> ;)
<imbrandon> Fujitsu, bah
<KurtKraut> How can I gather data from http://hwdb.ubuntu.com/ ? For instance, to check how frequent is the use of Ubuntu over AMD processors ?
<Burgundavia> KurtKraut: not easily
<KurtKraut> Burgundavia, :( any suggestions !?
<Burgundavia> hmm, the lead developer of that is ogra, who is currently not around
<KurtKraut> Burgundavia, is this him ? https://launchpad.net/people/ogra
<Burgundavia> yes
<KurtKraut> Burgundavia, I'll contact him. Thanks.
<jdub> Burgundavia: well, there's html2text, but you can also use any of the text web browsers (try some of them for output preferences)
<Burgundavia> jdub: thanks
<Zdra> hi, since dbus 0.90 upload in edgy I can't find the tool dbus-viewer... is it removed or moved to another patckage ?
<Fade> KurtKraut: you can use beautifulsoup to scrape the data directly from the website.
<KurtKraut> Fade, thanks for replying but... what is beautifulsoup ?
<Spads> http://www.crummy.com/software/BeautifulSoup/
<Fade> it's a python module that implements a fairly resilient html parser.
<Spads> there's a ruby version called Rubyful soup too
<Fade> you'd have to write the logic to scrape the specific site yourself.
* jdub spanks Spads 
<KurtKraut> Fade, oh, I see. Thanks.
<Fade> I have a small program that you could look at if you want an example of its use.
* Spads uses it to scrape web comics into RSS feeds for his personal planet install
<KurtKraut> Fade, thanks for the offer but I was only wanting this data because of the drop of linux-image-k7/686/amd64
<KurtKraut> Fade, I wrote an article about that, trying to calm down people before they complain about it.
<KurtKraut> Fade, and I was curious to check how many people uses each arch
<Burgundavia> KurtKraut: amd64 should still be there
<Burgundavia> Fade: popcon
<KurtKraut> Burgundavia, packages.ubuntu.com does not say that
<Fade> I'm familiar with the popularity contest. :)
<imbrandon> KurtKraut, its amd64-generic
<KurtKraut> imbrandon, Burgundavia, check out http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=linux-image-amd64-generic&searchon=names&subword=1&version=edgy&release=all
<Burgundavia> no, KurtKraut you are right
<Burgundavia>  linux-image-amd64-generic - Obsoleted by: linux-image-generic
<imbrandon> hrm no 64bit kernel ?
<KurtKraut> Burgundavia, I may even agree with the k7 and 686 drop. But the amd64 ? None of the bechmarks shown that it was unnecessery
<KurtKraut> There was a bechmark comparing amd64-generic with amd64-xeon and there was almost no diferente
<KurtKraut> but between amd64-generic and i386 there is obviously some difference
<Burgundavia> no idea, ask mdz or BenC
<KurtKraut> And I'm a bit concerned how the community will receive this changes.
<Burgundavia> about 0.5% will bitch
<imbrandon> moreso when they cant run 64bit usrland apps
<Burgundavia> which consitutes about 50% of the active forum users
<KurtKraut> Burgundavia, ahahha :D
<imbrandon> lol
<Fade> :)
<Burgundavia> at approx. 7 million installs and about 1000 active forum users, my numbers are actually pretty accurate
<Lure> KurtKraut: amd64 is still there - as it is different architecture
<Lure> KurtKraut: only i386 architecture kernel types were simpliefied
<imbrandon> i was gonna say there is no way we droped 64bit support
<imbrandon> but i was gonna check first
<KurtKraut> Lure, but have you seen how packages.ubuntu.com is labeling the linux-image-amd64-generic ?
<Fade> does hwdb expose a method to look up available records?
<Burgundavia> -generic is just being built for both arches
<Lure> Burgundavia: exactly
<Burgundavia> the kernel has always been a little odd anyway
<Burgundavia> we don't install gnome-amd64 or gnome-i386
<Fade> that would be determined by the pool.
<imbrandon> Burgundavia, actualy you do
<imbrandon> you install gnome-version_arch.deb
<imbrandon> ;)
<imbrandon> but its handled by dpkg
<imbrandon> and apt
<Burgundavia> yes
<Fade> gnome-powerpc for example is implicit. :)
<imbrandon> but what we DONT do is install gnome-386 vs -686
<Burgundavia> if you want true crack, here is a good one: Debian doesn't have a single kernel source package like we do
<imbrandon> i think thats what you ment
<Burgundavia> no, I meant the arch name is not in the binary package
<Burgundavia> but yes, we don't have that either
<Burgundavia> although we used to build mplayer like that
<imbrandon> yea becouse it USED to matter, notso anymore
<imbrandon> debian dosent what now? hehe i missed that one
<imbrandon> lemme grab some more coffee brb
* Fade watches an apt-get upgrade churn endlessly on preconfiguring packages
<imbrandon> oh wow Burgundavia i never noticed that, yea that is crackfull ( about the debian kernel sources )
<Fade> what ubuntu needs is a wiki entry describing the kernel policy and build proceedure.
<KurtKraut> Fade, +1
<Fade> I've been building custom kernels the debian way, but the initrd in the mainline edgy stream isn't booting my laptop because it doesn't seem to load the reiserfs module from initrd.
<Mithrandir> Fade: like https://wiki.ubuntu.com/KernelCustomBuild ?
<Burgundavia> Fade: start writing one and get BenC or mdz to approve it
<Fade> I'm afraid I don't know enough about it to do the doc any justice.
<ogra> hmm, does anybody have an idea why our debootstrap is so broken ? 
<ogra> the --verbose option isnt really helful :(
<Fade> specifically about the mechanics of initrd.
<Fade> the initrd in the powerpc arch is broken, for the last two releases.
<Burgundavia> don't we use initramfs now?
<Fade> Mithrandir: I dunno if you're involved in X triage, but (x|gnu)emacs is still bjorked. :)
<Mithrandir> Fade: get me a backtrace with full debug symbols and I can begin poking at it.
<Fade> xemacs-gnome works and xemacs -nw works, but if you start a native X process it dies spectacularly.
<Fade> there's a full backtrace in my bugreport
<Mithrandir> which bug?
<Kamion_> Burgundavia: I don't know where you got the idea that I do readahead, but I don't
<Fade> https://launchpad.net/distros/ubuntu/+source/xemacs21/+bug/58856
<Ubugtu> Malone bug 58856 in xemacs21 "xemacs segfaults on edgy powerpc system" [Untriaged,Unconfirmed]  
<Kamion_> _ion: could I get a trace of that console-setup installation with DEBCONF_DEBUG=developer set in the environment?
<Burgundavia> Kamion_: you play with the cds. In Mith the better person for that?
<Mithrandir> Fade: that backtrace is useless -- I need one with debugging symbols.
<Fade> how do I generate it?
<Kamion_> KurtKraut: huh? amd64-generic -> generic was just a rename; we aren't "dropping" the amd64 kernel
<Mithrandir> Fade: build the package with DEB_BUILD_OPTIONS=nostrip 
<Kamion_> Burgundavia: try the readahead changelog ...
<KurtKraut> KaiL_, renamed to what ?
<KurtKraut> Kamion_,  renamed to what ?
<Fade> okay. give me about twenty minutes.
<Mithrandir> Fade: I need to go see my wife now, but if you post what you find to the bug I'll read it later.
<Burgundavia> Kamion_: ok, will do
<Fade> okay
<Fade> wil "export DEB_BUILD_OPTIONS=nostrip && sudo pbuilder build xemacs21.dsc" do the trick?
<Mithrandir> Fade: probably not, no.
<Fade> where should i set the var?
<Fade> just run pbuilder from a root shell?
<Fade> ah, I got it.
<Kamion_> Burgundavia: Debian does have more or less a single kernel source now, by the way
<Kamion_> KurtKraut: linux-image-*-amd64-generic -> linux-image-*-generic
<Kamion_> it was just a rationalisation to get rid of the unnecessary architecture name in the package name
<Kamion_> KurtKraut: note that linux-image-*-generic on i386 is a different kind of kernel build to linux-image-*-generic on amd64
<KurtKraut> Kamion_, oh, now it is clear. Thanks.
<Kamion_> KurtKraut: if you've already published an article containing the misunderstanding, it would be nice to correct that
<Kamion_> KurtKraut: the full details are here: http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-source-2.6.17/linux-source-2.6.17_2.6.17-7.19/changelog
<Kamion_> under "Changes in kernel targets:"
<KurtKraut> Kamion_, I already wrote that part as 'pending confirmation'
<ogra> Kamion_, do you have a clue why debootstrap is broken atm ? i just tried it with --verbose but that seems to do exactly nothing ...
<Kamion_> ogra: not without a bit more detail, e.g. a transcript; it worked for me just the other day
<ogra> ok, i'm just running it again ... will look deeper in the chroot then ...
<Kamion_> or try running with set -x
<ogra> ok, next run :)
<ogra> Kamion, aha, seems xkb-data isnt in the chroot ... i'll try the set -x now
<Kamion> I did promote xkb-data to priority important, so debootstrap should pick it up
<Kamion> (it's needed for console-setup)
<ogra>  xkeyboard-config depends on xkb-data; however:
<ogra>   Package xkb-data is not installed.
<ogra> thats what dpkg --configure -a in the chroot gives me
<ogra> with a bunch of subsequent errors
<ogra> (including console-setup)
<Kamion> I suspect there are earlier errors that you've skipped over
<Kamion> perhaps some way back?
<Kamion> maybe causing x11-common or xkb-data not to be installed?
<Kamion> I'm trying a debootstrap myself now to compare
<ogra> well, debootstrap is very silent, as i said ...
<tseng> jdub: yes 14" 'widesreen'
<ogra> even --verbose doesnt change anything in its output ...
<ogra> the one with set -x is running ...
<Kamion> there should be a log somewhere in the created chroot
<ogra> but doesnt seem to give any extra output of the download ...
<Kamion> either /debootstrap/debootstrap.log or /var/log/bootstrap.log, IIRC
<ogra> ah, crap indeed i deleted the chroot to build a new one
<Kamion> well, I'm building one now
<Kamion> anyway, coffee
<ogra> i'll check it after that run has finished ... takes a moment
<ogra> good idea :)
<Kamion> ah
<Kamion> dpkg: regarding .../xkb-data_0.8-7ubuntu1_all.deb containing xkb-data, pre-depen
<Kamion> dency problem:
<Kamion>  xkb-data pre-depends on x11-common (>= 7.0.0-0ubuntu3)
<Kamion>   x11-common is unpacked, but has never been configured.
<Kamion> the pre-dep is giving it trouble
<ogra> ah
<Kamion> I think I need to promote x11-common to required; then it'll be done first
<Kamion> done that now
<Kamion> should be fixed after the next publisher run; thanks
<ogra> cool, thanks :)
<ogra> ltsp will be happy again 
<ogra> now i have to find out me what changed on the 7th that made my i386 (and only that ) CD grow by 30M ...
<ogra> its very weird ...
<Hobbsee> ogra: could you not count before?
<ogra> Hobbsee, the thing is i didnt touch anything ... but it broke exactly on the 7th 
<Hobbsee> ogra: :(  what else would have been touched?
<ogra> so something in the ubuntu metapackages (-minimal etc) must have changed or something in the seeds ...
<ogra> but the bzr logs of the ubuntu seeds dont show anything suspicious
<ogra> ah, wait ...
<ogra> * switch to 2.6.17-7; adapt installer seed to new image names (amd64-generic -> generic, itanium-smp -> itanium)
<ogra> the installer seed doesnt use the linux metapackage ... :)
<ogra> i didnt merge  :)
<Hobbsee> heh
<Hobbsee> silly ogra :P
<ogra> hmm
<ogra> whats the deal with package names in brackets now ? 
<ogra> are that recommends ? 
<ogra> ah, right, they are 
<Kamion> _ion: console-setup 1.7ubuntu7 might fix your problem, but I'd still be interested to see the above trace
<_ion> kamion: Here it is. (At the end, i ^C'd.) http://johan.kiviniemi.name/tmp/console-setup.log
<Kamion> _ion: did you set the layout to us,fi yourself?
<Whoopie> Kamion: Hi, although you approved openoffice.org-l10n for dapper-proposed, it didn't arrive the archives.
<_ion> kamion: Yes.
<Kamion> _ion: ok, fixed in 1.7ubuntu7, thanks
<_ion> kamion: I use fi when writing Finnish text, but us everywhere else. fi really sucks for coding. :-)
<_ion> kamion: Ok, thanks.
<Kamion> I'm not sure whether console-setup can/should attempt to handle us,fi better
<Kamion> if it produces bad results for you, let me know via a bug report on console-setup
<Kamion> but the immediate bug was just a straight infinite loop
<_ion> kamion: Just ignore everything but the first one, if keymap switching isn't possible/practical in console.
<_ion> People probably generally use the primary one as the first one.
<_ion> s/primary/preferred/
<Kamion> Whoopie: whoops, looks like I checked it over but never actually typed 'queue accept'. Fixed now.
<Kamion> thanks
<Whoopie> Kamion: thank you.
<Kamion> _ion: I believe we can actually do toggling
<Kamion> might be wrong though
<_ion> kamion: Ok. That would be cool.
<_ion> kamion: 1.7ubuntu7 is going to appear here first, right? https://launchpad.net/distros/ubuntu/+source/console-setup
<Kamion> yeah
<Kamion> yeah, we definitely can do toggling - I just tried it with Thai
<Kamion> though it didn't seem to want to let me switch back to Latin - I might be on crack though
<Kamion> you get used to safely unwedging your keyboard layout while working on this stuff :)
* hunger grumbles that upstart has broken his boot sequence yet again.
<hunger> This time it just stopps with a message along the lines of "unknown signal recieved".
<Keybuk> hunger: what is the exact message?
<Hobbsee> Kamion: ping?
<Hobbsee> Kamion: do you know that console-setup seems to be failing on preconfigure? http://rafb.net/paste/results/fhrtQY55.html
<Fade> hrmn. how do you change a debian/rules file in a package you're building with pbuilder?
<azeem> you change it, then create a new source package you point pbuilder at
<hunger> Keybuk: I need to reboot to see it... and then I'll need about an hour to get the system up again. I do not have the time to do that right now.
<hunger> Keybuk: I'll tell you tomorrow if that is OK.
<Fade> I just want to set DEB_BUILD_OPTIONS, is there any less involved way for injecting it into a pbuilder build?
<StevenK> Hobbsee/Kamion: Smells like debconf-age
<ogra> ugh
<ogra> wh does my dist-upgrade want to remove xchat ?
<Hobbsee> ogra: it's a mean and nasty plot to make you switch to konversation.
<ogra> hmmm
<ogra> only through the update-manager ...
* Fujitsu seriously considers moving to KDE after seeing various recommendations the GNOME team has made.
<Fujitsu> (ie. moving to Mono as the primary development platform)
<jdong> Fujitsu: oh come on, what's wrong with mono? :)
<Spads> nucleosis
<ogra> ubuntu will still stay with python as primamry lang ...
<Fujitsu> It is Microsofty to the max...
<Fujitsu> I'd hope so, ogra, but GNOME's going to Mono.
<jdong> Fujitsu: it's novelly :)
<Fujitsu> ...
<Fujitsu> Urgh.
<ogra> Fujitsu, lets them ... why should we care
<Fujitsu> Even worse :P
<jdong> oh come on, everyone loves novell :P
<jdub> Fujitsu: on what basis do you believe that gnome is "moving to mono"?
<Hobbsee> jdong: yeah right.
<jdub> Fujitsu: additionally, xchat vs. xchat-gnome is totally an ubuntu issue; neither are shipped with gnome.
<Fujitsu> Well, they seem to be recommending that people develop applications in Mono...
<jdong> Fujitsu: by including gtk# and one mono app?
<jdub> Fujitsu: 'gnome' does? no.
<Hobbsee> heya jdub 
<Fujitsu> jdub, where did X-Chat come into it?
<jdub> morning Hobbsee 
<Fujitsu> jdub, I'm sure I saw a recommendation somewhere...
<Hobbsee> jdub: it's not morning.
<zul> morning jdub 
<jdub> Fujitsu: unless you were randomly commenting in the middle of things, i figured you were responding to the topic of conversation
<jdub> Fujitsu: you may be confusing inclusion of gtk# in the gnome bindings release with 'recommendation'
<jdong> Fujitsu: again, I ask... is there anything wrong with apps written in mono?
<jdong> other than it's not your favorite language?
<jdub> Fujitsu: perhaps you should look at the other bindings in that suite
<Fujitsu> jdub, Hobbsee mentioned `switching to Konversation'.
<jdub> Fujitsu: there were previous comments i thought you may be responding to, if not, it's not relevant
<jdong> Fujitsu: Hobbsee is kubuntu to the max....
<jdong> :)
<Fujitsu> jdong, the language is controlled by Microsoft, and somewhat bloated.
<Fujitsu> jdong, I know.
<jdong> Fujitsu: MS doesn't really control it anymore
<Hobbsee> jdong: all lies.  i use firefox and thunderbird!
<jdong> Fujitsu: and honestly, mono runs much faster than python
* jdong hopes he didn't just lure out the python fanatics
<jdub> "bloated" doesn't mean anything; please don't use it in a discussion that might be technical
<Spads> Where oh where is my FORTH desktop???
<jdub> Spads: in your boot rom i would hope!
<jdong> no offense to anyone or anything python -- I like python :)
<Hobbsee> Spads: GNOME deleted it for simplicity.
<Hobbsee> :P
<jdub> Spads: did you see that OLPC guys are giving linuxbios forth love?
<Spads> jdub: !!
<jdub> Spads: exactly!
<jdub> i'm just waiting for the gtk+ bindings
<jdub> nothing like having a gui bios!!!
<_ion> I think i read C# is going to support closures. Python even doesn't support them.
<jdub> hfsnw!
<jdong> _ion: does python 2.5 support generics yet?
<_ion> jdong: I don't know.
<jdong> I've recently started liking mono
<jdong> the first time I tried it was a long time back, and it was too immature
<jdong> but now, it's a wonderful platform to work on
<_ion> Python does have some almost PHP-ish inconsistencies (e.g. len(str) vs. str.count("x"), wtf?). And some things are just nasty, e.g. having to type "self.__" in front of every single instance variable you want to be private.
<jdub> Ex-WarehouseDispatch to Local Courier
<jdub> woo
<Kamion> Hobbsee: should be fixed in console-setup 1.7ubuntu7; see the first changelog entry therein
<Hobbsee> Kamion: cool, i didnt see that when i checked LP.
* _ion is just building 1.7ubuntu7
<jdong> Kamion: how are the default lists for readahead generated?
<Kamion> jdong: no idea; I have nothing to do with readahead
<jdong> oh, sorry, someone told me to ask you that yesterday :)
* jdong hits up launchpad again
<Kamion> yes, see above where I told Burgundavia he was mistaken
<jdub> jdong: you might want to ask thom and/or Keybuk 
<jdong> k
<Keybuk> jdong: I install a machine, boot with "profile" and store the lists in the package
<Keybuk> unsurprisingly
<jdong> Keybuk: k, that's what I guessed
<jdong> Keybuk: I was noticing that my dapper box profiled a significantly different list than that was default
<Keybuk> jdong: did you install your dapper box fresh, or upgrade it?
<jdong> Keybuk: it was fresh, but alternate cd
<Keybuk> or have you installed anything else on it?
<jdong> it's relatively vanilla
<thom> Keybuk: does readahead not do any sorting based on on-disk location now?
<Keybuk> was the contents substantially different, or just the order?
<jdong> order, actually
<Keybuk> thom: the watch files are sorted
<jdong> I think the order should be recalculated as a part of postinst
<Keybuk> jdong: yeah, it'd make sense
<jdong> it shouldn't be too hard to split out that code into readahead-reorder, right?
<thom> Keybuk: right, i think we decided back in mataro that that was very install dependent, which is why the init script did it in the stop target
<jdong> and on a related note, bug 59716
<Ubugtu> Malone bug 59716 in readahead-list "Bootup is consistently faster when readahead is not daemonized" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59716
<Keybuk> thom: that never worked though?
<jdong> it holds true on my computers
<Keybuk> and really upset people with NFS filesystems, thin clients, etc.
<Keybuk> jdong: yes, I've been fighting that argument for a year now
<jdong> maybe that won't hold true with NFS, but it certainly holds true with disks :)
<Keybuk> the plan I wanted was to have /etc/readahead/$pkg for each package
<jdong> if it's not acceptable as a hard-coded default, at least give us a /etc/default/readahead way of specifying fg vs bg
<Keybuk> and have those files aggregated and sorted each time for each boot based on the installed packages
<jdong> Keybuk: how long's it take to sort though?
<Keybuk> jdong: nanoseconds
<Keybuk> depending on the size of the list, obviously
<jdong> :)
<jdong> my edgy box has like 1500 files in its readahead list now
<jdong> but it takes only a few seconds to read off
<jdong> reprofiling + foregrounding readahead has done WONDERS to my bootup speed
<jdong> it's now half what it used to be
<Keybuk> it'd be an interesting experiment
<Keybuk> modify readahead-list to do FBIOMAP and sort the list before readahead()
<Keybuk> you have to open the files *anyway* after all
<Keybuk> so instead of 
<jdong> ooh
<Keybuk> fd = open (...)
<Keybuk> readahead (fd, ...)
<Keybuk> do
<Keybuk> fd = open (...)
<Keybuk> ioctl (fd, FBIOMAP, ...)
<Keybuk> /* resort */
<jdong> ooh, then it'd always be read in the right order
<Keybuk> I wish inotify didn't suck
* jdong wonders if defragging the files in the readahead list would make any impact....
<Hobbsee> Keybuk: write that after upstart?  *ducks*
<Keybuk> you should be able to do a recursive inotify on the entire filesystem
* jdong checks fragmentation for curiousity
<Hobbsee> s/write/rewrite/
<Keybuk> jdong: unless you're running a stupid filesystem, they shouldn't be fragmented
<Keybuk> ext3 generally tries to keep them unfragmented
<jdong> Keybuk: generally, yes... do they get 2 or 3 fragments from time to time? yes
<jdong> and I don't think linux has any filesystem THAT stupid :P
<Keybuk> sometimes
<Keybuk> reiser
<jdong> only on large files though
* Mithrandir should really fix up his monitoring kprobe to be able to replace inotify.
<jdong> so as far as running readahead as foreground, what is the opposition right now?
<jdong> about 25% of the files in the list are fragmented, though usually it's just 2 fragments... so not worth it :)
<Lathiat> 
<Mithrandir> 
<ogra>                           ?
<jdong>    .
<Fujitsu>                          !
<Hobbsee>              *
* Hobbsee tickles Mithrandir 
* Mithrandir ruffles Hobbsee 
<Hobbsee> hey!  which bit of me are you ruffling there?
* Hobbsee smoothes out her hair again.
* Fujitsu steals Hobbsee's hair.
<Hobbsee> you cant.  it's on my *head*
<Hobbsee> and you cant steal my head.
<Mithrandir> stealing people's heads is considered rude, yes.
* Fujitsu steals Hobbsee's hair anyway.
<Hobbsee> Mithrandir: hehe
* Hobbsee defenestrates Fujitsu 
<Fujitsu> :O
<Fujitsu> How dare you!
* Fujitsu climbs back in the window.
* Hobbsee defenestrates Fujitsu again, and closes the window this time.
<Fujitsu> Darnit.
* Fujitsu opens the window.
<Hobbsee> you cant join us again
* Fujitsu climbs up Hobbsee's hair.
<Hobbsee> it's locked.  i do a better job than that.
<Fujitsu> Aw... Why not?
<Fujitsu> Damn...
<Hobbsee> hah.  it's far too short for that.
* Fujitsu cuts hole through window.
* Hobbsee burns Fujitsu's eyes out with her laser.  you cannot win against the very powerful Hobbsee!
<Fujitsu> Hm.
<Hobbsee> "RESISTANCE IS FUTILE"
<Hobbsee> </end sillyness>
<Fujitsu> Yes, MOTU-Hobbsee shall always win against nothing-Fujitsu. :P
<Hobbsee> heh
<ivoks> Keybuk: thanks for live-f1 :)
<abattoir> ivoks: where?   :P
<ivoks> abattoir: ftp://ftp.netsplit.com/pub/live-f1/0.2/
<ogra> hmm
<ogra> Kamion, do i need to add the new recommends stuff to output_seeds in edubuntu-metas update.cfg ? 
<ogra> i dont get the listing i saw in ubuntu-meta for the recommends
<ogra> (in the changelog)
<ogra> i only see removals ...
<Kamion> ogra: no, you shouldn't; and that's normal for new seeds
<Kamion> (it's arguably a bug, but at present it's normal)
<Kamion> I mean for new outputs
<Kamion> your next upload will include recommends changes
<Kamion> I'd just add a note to the changelog saying that the above depends have become recommends, or similar
<_ion> Oh, wow. I ate a dinner, and my box is still building console-setup 1.7ubuntu7. :-)
<_ion> It's been at it for almost an hour.
<Kamion> yeah, takes ages to build all the fonts
<Kamion> wish I could work out why Alt+Shift toggling only appears to work in one direction
<_ion> Nice, a deb is already available. https://launchpad.net/+builds/+build/243937/console-setup
<_ion> kamion: It installed correctly.
<Kamion> _ion: great, thanks
<Keybuk> jdong: massively slows down the Live CD, iirc
<Keybuk> and people file bugs that readahead takes up an amount of their boot process
<Keybuk> without realising that it reduces the rest by more than it takes
<Keybuk> and there's variable data on that sadly
<Keybuk> seems to depend largely on the drive speed, for example
<Keybuk> ideally, we should be able to mark a file in the system as not suitable for fragmentation
<Keybuk> do that for files read at boot
<Keybuk> readahead them in block order
<Keybuk> etc.
<Keybuk> in fact, I'd go as far as even trying to arrange them sequentially on the disk
<Keybuk> but that kind of low-level filesystem engineering is ... complicated
<Mithrandir> especially since the consecutive blocks the FS sees might not be consecutive on-disk.  Think raid-0, LVM and similar cases.
<Keybuk> indeed
<Keybuk> though we could always just let those users suffer <g>
<Keybuk> if you're using RAID, you don't care about filesystem speed anyway, just reliability
<Keybuk> and probably aren't a boot speed ricer
<Mithrandir> true, since initialising your SCSI card is going to take 30 seconds _anyhow_
<_ion> Since when do you need SCSI to do RAID? :-)
<Keybuk> _ion: even if you don't, RAID is slow
<Keybuk> it's not supposed to be fast
<Keybuk> it's supposed to just corrupt your data in more interesting ways when it goes wrong
<Keybuk> err, I mean, be more reliable :p
<_ion> Hehe.
<_ion> Re: boot speed, this is interesting. https://features.launchpad.net/distros/ubuntu/+spec/fcache
<Keybuk> _ion: sounds a bit similar to a crackful idea I had
<Keybuk> make the standard install a squashfs, and readahead that before loop mounting it :p
<Keybuk> I didn't tell Mithrandir, for fear that he would implement it :p
<_ion> Hehe.
<Mithrandir> Keybuk: this is now I should tell you I have toyed with the idea?
<Mithrandir> Keybuk: we _do_ actually support it.
<Mithrandir> fsvo support
<Keybuk> it doesn't surprise me :p
<tseng> Mithrandir: you're nuts
<Mithrandir> tseng: nah, not really.  It made my testing a lot quicker when I could just drop stuff onto a USB drive instead of burning CDs.
<Mithrandir> also meant I don't have to use a CD/DVD drive for my x40
<Keybuk> one way we could do it is reserve an initial amount of the disk
<Keybuk> say the size of the available memory
<Keybuk> mark it as a special/reserved block
<Keybuk> and read from that
<Keybuk> arranging the boot files in there sequentially, etc.
<Keybuk> in fact
<Keybuk> what we need is a magic partition that can directly seed the page cache in such a way that it's fooled into believing it has the same data as on the real partition
<Keybuk> without risking problems with the magic being out of date
<Keybuk> of course, the more crackful you get, the more difficult it is to maintain :p
<_ion> Hmm, doesn't the "fcache" thing do something like that?
<Treenaks> Keybuk: we just need to stop people rebooting! :)
<Keybuk> _ion: yeah, basically
<Hobbsee> Treenaks: heh.  fix suspend/hibernate, and we wont have to!
<Keybuk> suspend is fine
<Keybuk> it's resume that's the problem :p
<Treenaks> Keybuk: not for my laptop
<Treenaks> Keybuk: (but that might be Radeon/R200 related)
<LarstiQ> Keybuk: heh, just like flying ;)
<Keybuk> flying is easy, it's landing that's difficult? :p
<Keybuk> or landing gently
* LarstiQ nods
<Hobbsee> Keybuk: hehe.  true that
<Hobbsee> Keybuk: and no, "Crash and burn" is not an acceptible solution :P
<Mithrandir> Hobbsee: I think Scott's laptop know all about the "burn" part at least.
<Hobbsee> Mithrandir: hehe.  true that
<Keybuk> Mithrandir: hmm?
<Mithrandir> Keybuk: you had some fun when we loaded the fan module a bit late, IIRC?
<Keybuk> Mithrandir: it still has problems with that
<Keybuk> using ondemand instead of powernowd has made a big difference to the fan noise though
<Hobbsee> hmmmm, now you've reminded me.
* Hobbsee wonders when her laptop will come to a grinding halt.
<_ion> Sigh, yet another situation apt's dist-upgrade can't handle.
<_ion> The following packages have been kept back:
<_ion>   libggi2
<_ion> smartpm naturally handles that without a hitch.
<Keybuk> _ion: by removing half of your system in retaliation? :p
<Keybuk> does aptitude handle it?
<_ion> keybuk: smartpm: Upgrading packages (1): libggi2_1:2.2.1-4ubuntu1   Installing packages (2): libgii1_1:1.0.1-2 libgii1-target-x_1:1.0.1-2   Removing packages (2): libgii0_1:0.9.1-0.2 libgii0-target-x_1:0.9.1-0.2
<Keybuk> the problem with smart is that it's only demonstratibily different to apt
<Keybuk> there's a lot of things smart gets wrong that apt just works with 
<Keybuk> it's not better
<Keybuk> or, at least, cannot be demonstrated to be so
<HiddenWolf> my dist-upgrade only took 3 tries and some manual apt-get magic to get right. =)
<Keybuk> and smart has huge problems of its own
<Keybuk> e.g. it becomes impossible to ever upgrade python <g>
<_ion> keybuk: aptitude handles it correctly as well.
<Keybuk> aptitude has been the "standard" dist-upgrade tool for a while, remember
<Keybuk> Debian no longer recommend "apt-get dist-upgrade"
<Hobbsee> Keybuk: hehe.  well, why would you want to update python anyway?
<Keybuk> Hobbsee: you don't want python 2.5?
<_ion> I slightly dislike aptitude's way of handling manually/automatically installed packages. Debfoster seems to handle it better.
<Hobbsee> Keybuk: well...
<bddebian> Howdy folks
<pygi> hey ho bddebian 
<bddebian> Hi pygi
<bddebian> pygi: Well I'm close I think
<bddebian> I don't know wtf the package config files are though :'-(
<pygi> bddebian, ah, no worries
<pygi> anyway, gotta run
<pygi> talk to you later
<Kamion> ogra: there's another problem with x11-common/debootstrap; fixing it now
<ogra> ah, i was already wondering if the publisher cronjob had dies ;)
<ogra> *died
<Kamion> nah, /etc/init.d/x11-common wasn't coping with /etc/default/rcS not existing
<ogra> ah, upstart fun :)
<Kamion> no
<ogra> oh ? 
<Kamion> absolutely nothing to do with upstart
<Kamion> /etc/default/rcS isn't created by debootstrap - it's created by other parts of the installer
<ogra> ah, k
<ogra> i thought it came from sysvinit 
<Kamion> please don't blame everything to do with /etc/init.d/* on upstart :-)
<Hobbsee> Kamion: why not?  it's scott's week for being blamed :D
<Kamion> heh, actually it's created by initscripts
<Kamion> (but that's still used by upstart)
<Kamion> however:
<Kamion> I: Configuring x11-common...
<Kamion> I: Configuring initscripts...
<ogra> oh :)
<Kamion> I don't feel like adding a Depends to avoid that, though
<ogra> hmm, what else would work then ? 
<Kamion> not bothering to source /etc/default/rcS if it's not there
<Kamion> read the init script - the only thing it's used for is $VERBOSE
<Kamion> that can trivially be ignored
<ogra> yeah :)
<ogra> i wonder how debian solves that
<ogra> they will have the same prob, no ?
<Kamion> it doesn't need to, because Debian does not install x11-common from debootstrap
<ogra> ah
<Kamion> we've only just started doing that, because we've moved to console-setup
<Kamion> Debian hasn't yet
<ogra> yup
<Kamion> I'm sure they will - it's a much better solution and it's written by Debian folks
<Kamion> but it's a bit uncomfortable at this point in the etch release cycle
<ogra> when do they freeze ? 
<ogra> must be soon if they want to release in december
<Mithrandir> ogra: Debian has a gradual freeze which has already started.
* Keybuk tsks at ogra
<ogra> Keybuk, ?
<ogra> you dont belive they make it this year ? :)
<ogra> Mithrandir, ah
<Keybuk> ogra: always blaming me for everything
<ogra> sorry ... comes in so handy with such a big change :)
<jsgotangco> haha
* jdong notes his kdm still doesn't power down :-/
<Keybuk> the next time you make a change as big, and only get trivial/minor bugs, then you can tease as much as you like :D
<ogra> :)
<Hobbsee> jdong: did you kill g-p-m first?
* ogra actually ditnt have *any* probs with it, not even in ltsp
<Hobbsee> jdong: actually, yeah, i noticed that.
<jdong> Hobbsee: it's Keybuk's fault... I swear
<Keybuk> jdong: it is
<jdong> seriously, this time it is :)
<Keybuk> keybuk didn't do the second part of that patch
<Mithrandir> Keybuk: I can blame you for kinda-breaking casper. :-P
<Keybuk> shutdown -h now will work properly now, of course
<Hobbsee> jdong: what do you mean "this time?"
<Keybuk> Mithrandir: oh?
<Keybuk> jdong: actually, it's KDE's fault for using the wrong damned command to shutdown
<Hobbsee> jdong: if in doubt, blame Keybuk.  in fact, blame him anyway :P
<Mithrandir> Keybuk: casper rewrites inittab, and, well, there's no more inittab, so autologin on the consoles don't work any more.
<Mithrandir> Keybuk: absolutely trivial to fix, though
<Hobbsee> Keybuk: what should we be using?  /sbin/poweroff?
<Keybuk> Hobbsee: /sbin/shutdown
<Hobbsee> ah
<ogra> Hobbsee, hey, thanks for the merge :)
<Keybuk> Mithrandir: oh, what does it do ?
<Hobbsee> ogra: which one?
<ogra> electricsheep
<Hobbsee> ogra: oh.  not a problem :)
<wasabi> good morning freedom lovers
<Mithrandir> Keybuk: it seds the inittab.
<Mithrandir> Keybuk: don't worry though, I'll fix it myself.
<Keybuk> Mithrandir: yeah, I mean what change does it make?
<Keybuk> (just out of curiousity, I didn't know you even did that)
<ogra> oh...
* ogra was planning to do that for ltsp ...
<ogra> how do i disable consoles now ? 
<Mithrandir>     sed -i -e "s|^\([^:] *:[^:] *:[^:] *\):.*getty.*\<\(tty[0-9] *\).*$|\1:/bin/login -f $USERNAME </dev/\2 >/dev/\2 2>\&1|" /root/etc/inittab
<Keybuk> Mithrandir: oh, I see! :p
<jdong> my... god... :)
<jdong> duh
<Keybuk> yeah, just sed the getty files :p
<jdong> why didn't I think of that :P
<Keybuk> ogra: "disable" ?
<ogra> Keybuk, in ltsp i need only one console ... and want an option to even disable that one in the future 
<Keybuk> ogra: you futz the filesystem, rather than adjust things in the packages, yes?
<ogra> i was planning to sed thrugh inittab during the chroot creation 
<Keybuk> ok
<Keybuk> easy then
<Keybuk> rm /etc/event.d/tty[2-6] 
<ogra> ah, cool !!
<Keybuk> don't rm tty1 though, you'll upset upstart :p
<ogra> ok
<ogra> but that saves 500k-1M per tty :)
<Keybuk> if you want to replace it with tty, you'll need to replace it with *something*
<Keybuk> upstart gets grumpy if there are no jobs running
<Keybuk> so if you remove tty1, you either need to also remove sulogin
<ogra> well, i can live with one ... even though its useless to have with no user account 
<Keybuk> or replace it with something else
<Keybuk> otherwise upstart will just start a /bin/sh on /dev/console :p
<ogra> heh
<Keybuk> you may not mind it doing that, of course
<Keybuk> does remind me that if you rm /
* LarstiQ encountered that today
<ogra> well, i dont disable console switching so having a open /bin/sh ....
<Keybuk> rm /etc/event.d/tty... it should immediately kill the ttys :p
<Keybuk> LarstiQ: oh?
<LarstiQ> Keybuk: for some reason my machine froze in the middle of an upgrade
<LarstiQ> Keybuk: so on reboot it wasn't really functional
<Keybuk> LarstiQ: odd
<LarstiQ> Keybuk: now it all works again, thanks to a breezy live cd :)
<Tonio_> who should I poke for python 2.5 related issues ?
<Tonio_> we have a problem to build kde apps with python 2.5
<Kamion> Tonio_: doko
<Tonio_> Kamion: thanks :)
<Kamion> smurf: would you mind if I uploaded keymapper to Debian at some point?
<Kamion> I'd really like to start getting rid of some of the big complicated diffs connected to that that we've been carrying. :-)
<smurf> Kamion: no problem
<koke> btw, it seems ubiquity doesn't detect correctly the newworld bootstrap partitions
<bluefoxicy> Has anyone considered Blender for a UVF exception?
<bluefoxicy> Their versioning scheme is bull shit.
<bluefoxicy> http://www.blender.org/cms/Blender_2_42.727.0.html
<bluefoxicy> THIS is what's new in 2.42 that wasn't in 2.41, what the hell?  I would have called that 3.0
<ogra> bluefoxicy, afaik lfittl wanted to care for it ... t just moved to universe recently
<bluefoxicy> ogra:  it says it's in main here, this must be really recent.
<tseng> the source is in main
<Nafallo> the binary aswell
<Nafallo> apt-cache madison blender
<ogra> right, so its not demoted yet
<ogra> we cant upgrad eit in main
<ogra> it has a hard dependency on ffmpeg
<ogra> (the new version)
<bluefoxicy> thought not.  Was worth a shot.
<ogra> bluefoxicy, Nafallo, http://people.ubuntu.com/~cjwatson/anastacia.txt its listed for demotion ...
<bluefoxicy> ah ok.
<Nafallo> but it's not there yet :-)
<bluefoxicy> It doesn't matter, I'm not using it
<bluefoxicy> I'm just trying to lure a Mephis user over ;)
<bluefoxicy> (originally I was just going to say 2.41 and 2.42 were basically equivalent but the release notes say there's significant UI changes and new features, which is a WTF)
<bluefoxicy> "A lot of work has been done to improve the non-linear video editor in Blender. The highlights include a much better memory management (edit up to hours near-real time) and for Linux users, FFMPEG was added for a wide range of video/audio codecs."
<bluefoxicy> ogra:  found the dependency on ffmpeg ;)
<ogra> heh
<bluefoxicy> Personally I would have used gstreamer (gstreamer has an ffmpeg plug-in!) and helped with the porting effort if I wanted a wide range of video/audio codec support
<bluefoxicy> anyway, back to other useful things.
<Kamion> mbiebl: console-tools provides programs that console-setup uses to do its job; console-setup is a higher-level tool
<Kamion> s/tool$/system/
<Kamion> mbiebl: note how console-setup depends on console-tools
<mbiebl> Ok.
<Kamion> mbiebl: the redundancy is not between console-tools and console-setup, but between console-data and console-setup; however I haven't yet disentangled enough bits to be sure that it's safe to take out console-data, so for the meantime it doesn't do too much harm to leave them both there
<Kamion> oh, heh, console-setup only recommends console-tools - but you get the idea
<mbiebl> Still I have the prob, that somehow the console-setup script is not executed.
<Kamion> you don't really want to have it without kbd or console-tools, though, as you wouldn't be able to load keymaps
<mbiebl> during startup.
<Kamion> mbiebl: could you rephrase that in a more verbose way?
<Kamion> there is no script called "console-setup"
<mbiebl> I have to call setupcon manually after logging in on the console.
<Kamion> so I need to know what your actual problem is. :)
<Kamion> OK.
<mbiebl> S49console-setup doesn't do it's job ;-)
<Kamion> what happens if you run 'sudo /etc/init.d/console-setup start' by hand?
<Kamion> from a console, not X
<mbiebl> Then it works.
<mbiebl> I get the nice looking terminus font and the german UTF-8 keyboard layout.
<Kamion> do you have /usr and/or /var mounted separately from /?
<mbiebl> no
<Kamion> (shouldn't make any difference anyway - console-setup comes after mountall)
<Kamion> Do you have upstart-logd installed?
<mbiebl> /var/log has this message: Sep 10 20:29:13 rcS: stty: standard input: Invalid argument
<mbiebl> Guess this is the root of the problem.
<Kamion> oh, I noticed that myself, hadn't tracked down what script it was from yet
<Kamion> console-setup doesn't call stty directly though
<mbiebl> Well, the console-setup init script should output "Setting up console font and keymap..."
<mbiebl> But I don't have this message in the /var/log/boot
<mbiebl> Only the above error mesasge
<Kamion> yeah, me neither now you mention it
<Kamion> ok, since this is something I see too, it should be relatively straightforward to track down
<Kamion> thanks for bringing it to my attention
<mbiebl> np
<slomo> doko: ping?
<crimsun> Mithrandir: ping, do you mind if I merge sane-backends? [The relevant change in Debian's 1.0.18-3 addresses (the dupes) Ubuntu bugs 56317, 59141, 59390, and 59753] 
<Mithrandir> crimsun: feel free
<crimsun> Mithrandir: thanks
<Kamion> crimsun: heh, I'm glad you drew my attention to that - I had just written a patch to fix that, independently
<Kamion> I won't bother now
<Kamion> although I think my patch was better, as it actually checked line length properly, but no matter :)
<Keybuk> heh
<Keybuk> that bug is increasingly annoying
* _ion hopes totem-mozilla were moved from ubuntu-desktop's Depends to Recommends. I prefer the MediaPlayerConnectivity extension much more.
<_ion> Should i file a bug report, or is there no chance of that happening?
<Kamion> sigh. I would like to know how the usplash bogl backend got so utterly wedgied
* Kamion attempts to figure out the changes in order to patch it back together
<pitti> Kamion: good luck
<Kamion> oh. oh dear. somebody entirely forgot to teach bogl-[pt] cfb.c about colour maps larger than 16
<Kamion> I wouldn't be surprised if it were randomly widdling over its stack
<xav> is it possible to remove anything but the core system?
<Kamion> ooh, a usplash
<Keybuk> heh
<Keybuk> you sound so please
<Keybuk> +d
<mjg59> Kamion: On PPC?
<Kamion> mjg59: yep
<mjg59> With correct colours?
<Kamion> apparently, but I'll look later
<Kamion> want to go and play games with Kirsten now
<mjg59> Super
<mjg59> Can you check it in?
<Kamion> not right now, but tonight
<mjg59> I can simulate with vesafb for testing
<Kamion> give me an hour or so to go and be social while K is still awak
<Kamion> e
<mjg59> No problem
<AlinuxOS> mjg59, hello, sorry me if I disturb. Maybe some news about ttf-bpg-georgian-fonts ? is problem solved ?
<mjg59> AlinuxOS: Nope
<mjg59> Needs fontconfig changes
<mjg59> I'm working on it
<AlinuxOS> mjg59, so you don't need my or someones(who wrote some comments on malone https://launchpad.net/distros/ubuntu/+source/ttf-bpg-georgian-fonts/+bug/55966 ) ?
<Ubugtu> Malone bug 55966 in ttf-bpg-georgian-fonts "ttf-bpg-georgian-fonts.conf problem." [Untriaged,Confirmed]  
<AlinuxOS> mjg59, ok. So if there is some news... I'll help you in testing.
* desrt whacks mjg59 
<desrt> you dup'd my bug in the wrong direction :p
<mjg59> desrt: Didn't I dup the newer one to the older one?
<desrt> you did
<desrt> but i filed the newer one, damnit :p
<mjg59> Learn to search the FBTS :p
<desrt> fbts?
* jdub hugs mjg59 
<mjg59> Bug Tracking System
* desrt goes by the "dup the bug with less useful information in it" rule
<Keybuk> see, I believe the opposite
<Keybuk> I wish people would NOT search the BTS
<Keybuk> or, at most, file a new bug and mark it as a dup themselves
<Keybuk> because that way, when they turn out to be wrong, I don't have one bug with two different people with two different problems
<Keybuk> in fact, I wish it was just two ... usually it's as few as seven or more people on one bug
<jdub> hrm
<jdub> how good is the desktop CD for rsyncing?
<jdub> if i start downloading edgy images now, should i get alternate or desktop?
<Kamion> jdub: pretty good
<Kamion> whichever you want
<jdub> (note: tin cans and string on an island)
<mjg59> Keybuk: In this case, two bugs with identical titles referring to identical problems on identical hardware
<jdub> Kamion: hmm - is it certified AUSTRALIA / SOUTH AFRICA SAFE?
<jdub> Kamion: last daily is good, or should i get knot 2?
<mjg59> Now that it takes me about 10 minutes to download an iso /anyway/, I've stopped worrying so much about rsync
* jdub SMACKS mjg59 
<jdub> i need to get a new adsl modem
<Keybuk> mjg59: *shrug* I'd still rather receive the dups than not
<Kamion> mjg59: yep, I've checked all the colours and they're right
<Kamion> jdub: *shrug* dunno about current daily, depends how edgily you want to live
<Keybuk> "udev hangs for three minutes on boot"
<jdub> Kamion: I LOVE EDGY!
<mjg59> Kamion: Super
<Kamion> jdub: oh, debootstrap will probably fail on current alternate daily
<Kamion> should be fixed tomorrow
<jdub> Kamion: i'll suck down desktop
<jdub> thanks!
<jdub> hopefully today i'll have new hardware to test on
<Kamion> mjg59: ok, grab r59
<Kamion> I'm off to bed
<Kamion> works for me at native resolution (1280x854), 1024x768, and 800x600 with the testcard
<Kamion> native resolution is important to test separately because in that case I made bogl not bother to change resolution
<mjg59> Kamion: Cool
<AlinuxOS> doko, hello, ping
<doko> AlinuxOS: pong
<AlinuxOS> doko, I've sent you some mails regarding Georgian OO.org package.
<AlinuxOS> doko, do you have some news maybe ?
<doko> AlinuxOS: not for 2.0.3, it maybe included, if we upgrade to 2.0.4
<AlinuxOS> OOo_2.0.4-ka-GE.gsi is ready
<AlinuxOS> ah ok
<doko> I'll send out a mail for 2.0.4 tomorrow 
<AlinuxOS> the latest corrected (translation correciton) www.gia.ge/zzz/OOo_2.0.4-ka-GE.rar is here.
<doko> AlinuxOS: I would prefer just a GSI file
<AlinuxOS> doko, ok... I's beta version...so it will be great to have Georgian OO.org in Ubuntu too..in this mode we can improve it.
<AlinuxOS> doko, OOo_2.0.4-ka-GE.rar -- GSI is inside.
<jdong> I don't think doko likes rar files
<jdong> AlinuxOS: try appeasing him with a more open format ;)
* doko slaps jdong ;-)
<jdong> hehe
<AlinuxOS> jdong, thank you..doko you are right.
<AlinuxOS> just a moment so D
<AlinuxOS> doko, I' send you e-mail with GSI file.
<doko> AlinuxOS: please send just a URL
<AlinuxOS> doko, you just tell me what you need :) Alinux (dude) abides :)
<jdong> AlinuxOS: doko is very picky :)
* jdong ducks
<AlinuxOS> doko, ok url with GSI directly ?
<doko> AlinuxOS: don't listen to jdong, just send what you want
<jdong> hehe
<jdong> doko: so are my OOo fonts gonna stop being ugly soon?
<jdong> doko: namely bug 54776
<Ubugtu> Malone bug 54776 in openoffice.org "[Edgy]  font hinting does not work with libfreetype6 v. 2.2.1" [Untriaged,Confirmed]  http://launchpad.net/bugs/54776
<jdong> a patch is linked
<AlinuxOS> doko, I'll give URL in some second ;)
<AlinuxOS> seconds :D
<AlinuxOS> brr
<doko> jdong: on my list ...
<jdong> doko: cool man, no hurry
<jdong> I'll stop annoying you now :)
#ubuntu-devel 2007-09-03
<Crisps> which channel do I need for application development on ubuntu?
<ion_> Depends on what language and libraries you use.
<ion_> For instance, if youre using Gtk, look for the Gtk channel.
<Crisps> looking at GUI based stuff, in C++
<dobey> there's nothing really ubuntu-specific unless you're doing something with packaging, or system configuration
<Crisps> I really don't know a great deal about the x/gnome/kde interfaces. all my exp is on win32
<wasabi> Anybody aware of LVM's pvmove being broken in 2.6.22 and whether it was patched?
<Moniker42> hey, where are some of the artwork team members?
<funman> hi
<funman> i'm looking for crimsun
<funman> do you know which time he has ? (GMT+?)
<Moniker42> funman, you could track down his launchpad or forums profile...
<funman> he sorry i don't use these
<kenro> Heavy question, in and out of topic: Is it possible to combine the best of text RPG (MUSH) and the best of graphical MMORPG into one *nix-based suite?
<Hobbsee> ....
<Hobbsee> dude, #ubuntu-offtopic
* RAOF waves to Hobbsee 
<Hobbsee> hiya RAOF
<Chipzz> heya Hobbsee
<ajmitch> hello
* RAOF watches the hello avalanche gain momentum.
<Hobbsee> hi Chipzz
<RAOF> Hey ajmitch
<Hobbsee> hi ajmitch
<ScottK> Hello Hobbsee
<ScottK> Hello ajmitch
<ScottK> hello RAOF
<ScottK> Heya Chipzz
<RAOF> Hi ScottK :)
<ScottK> Happy now?
<Chipzz> kenro: dude, beside the fact that that question really is off-topic, what even makes you think you're going to get an answer here (ie anyone at all plays let alone develops these kind of games)?
<Chipzz> hi ScottK :)
<ScottK> kenro: Yes.
<kenro> Chipzz:  Know a #ubuntu-hackers or #ubuntu-grapics_developers? Hell, I'll even take a #ubuntu-games_developers.
* ScottK believes lots of things that aren't true however.
<IntuitiveNipple> kenro: http://www.projectdarkstar.com/
<Chipzz> ScottK: heh :)
<RAOF> I think that was a satisfactory greeting avalanche, yes.
<Chipzz> ok, really baffled that anyone knew an answer to that (IntuitiveNipple) :)
<Hobbsee> er, how can i tell why a package was installed?
<ajmitch> RAOF: I don't know anyone who'd play those games, do you? :)
<Chipzz> Hobbsee: look at reverse dependencies/suggest/recommends with grep-dctrl?
<Hobbsee> Chipzz: was looking thru them, but i cant get higher than x11-common
<Chipzz> grep-status even
<RAOF> ajmitch: No, not really ;)
<Chipzz> Hobbsee: but I'm sure you knew that ;)
<ScottK> Hobbsee: One option is to try and remove it and then see what apt wants to take with it.
<Chipzz> ScottK: that won't work for recommends/suggests ?
<Hobbsee> ScottK: oh, good poing
<Hobbsee> er, point
<Chipzz> or if the package is in the seeds (which I assume it's not in this case)
<Hobbsee> that still doesnt help - it now wants to remove a heck of a lot of stuff
<Hobbsee> it's not in the seeds, i checked that :)
<Hobbsee> oh, it looks like everything X based depends on it
<Chipzz> Hobbsee: you probably would have known if it was anyway I assume ;)
<Hobbsee> that's enough for me to answer the question :)
<Hobbsee> Chipzz: well, i thought so, but some of the X stuff was named confusingly, so...
<Chipzz> Hobbsee: yeah, the X packages are a twisty maze I guess :)
<kenro> IntuitiveNipple:  I refuse to truncate your nick. I don't nip. But thanks for the url.
<Chipzz> and the packages having had different names over the course of the years also doesn't help (xfree/xorg etc)
<IntuitiveNipple> lol
<IntuitiveNipple> kenro: I've been experimenting with a 'virtual world'  source-code and package explorer using it
<Chipzz> Hobbsee: oh btw, I have been playing with writing a program which visualizes dependencies etc in a graph quite some time ago
<Hobbsee> Chipzz: cool :)
<Chipzz> Hobbsee: gave up on it due it being impractical due to the sheer amount of packages installed by default though, which makes the graph too complucated
<Chipzz> Hobbsee: I can throw the source code your way if you want to look (and if I find it)?
<Chipzz> Hobbsee: written in pygtk though ;P
<Hobbsee> heh, nah, i'll be right
<IntuitiveNipple> I wrote something similar a while back, but using Google Earth to model it
<Hobbsee> i can read rdepends mostly
<kenro> ScottK:  I... sorta half-believe about David Icke's Illuminati terrorists/social engineers... I tink ocaml might be a good graphics base for this thing.
<Chipzz> IntuitiveNipple: how do you handle laying out the packages?
<IntuitiveNipple> base packages closer to the ground; higher level at increasing altitudes, with paths drawn between dependencies
<\sh> gnarf...can anybody reproduce some segfaults with firefox when going in p.u.c and scrolling down via mouse wheel?
<Chipzz> IntuitiveNipple: yeah, but doesn't that still leave you with the problem of finding suitable x/y coordinates?
<IntuitiveNipple> Chipzz: I played around with that... I assigned the various package categories to different countries
<IntuitiveNipple> There's all sorts of messing about you can do at the level to position them on the surface
<Chipzz> IntuitiveNipple: that does waste an awefull lot of perfectly well oceans though ;)
<Chipzz> s/well/good/
<IntuitiveNipple> there's no cities in the oceans to act as anchors for the various packages though :)
<Chipzz> sure there is! atlantis :)
<IntuitiveNipple> You could do anything in that sense, but I was enjoying myself.... and I found it becoming quite intuitive to visualise the dependencies
<IntuitiveNipple> One day I might finish it and put it online :)
<IntuitiveNipple> 64-bit Gutsy certainly flies compared to 32-bit - I just got Google Earth installed on tribe-5, but been building packages and it's at least 40% faster
<Hobbsee> good morning cjwatson
<sbalneav> Anyone having problems pushing to bazaar.launchpad.net?  Have I missed a downtime announcement?
<Fujitsu> sbalneav: LP died a little while ago, and one of the sysadmins is uncontactable... might be a little while.
<sbalneav> ah, ok
<sbalneav> Just wanted to make sure it wasn't me.
<fabbione> morning
<mpt> s/one/both/
<sbalneav> Morning fabbione
<Fujitsu> Hey fabbione.
<Fujitsu> mpt: Who's the other? mthaddon?
<mpt> yes
<Hobbsee> greetings sbalneav, fabbione
<sbalneav> Hey hobsee.
<sbalneav> err, Hobbsee
<Hobbsee> heh
<\sh> re
<MacSlow> Greetings everybody!
<desrt> greetings, excessive cross-poster!
<MacSlow> hi desrt
<dholbach> good morning
<mdke> hi dholbach!
<dholbach> hey mdke
<mdke> dholbach: how are you?
<dholbach> mdke: quite well - how are you?
<mdke> dholbach: good thanks.
<mdke> dholbach: would you mind doing an ubuntu-docs upload soonish?
<dholbach> mdke: I have a bunch of other things to do atm, but I set it on my todo list
<mdke> dholbach: great, not super urgent
<dholbach> ok super
<mdke> dholbach: the other question I wanted to ask - I saw the gnome-docs upload went through, did you need to do something else to make it build?
<dholbach> mdke: no - it seems to work nicely just like that
<mdke> dholbach: hmm. I got a build error back from LP about dpkg being the wrong version, did you see that?
<dholbach> mdke: uh - no; maybe that was a one-time error due to something else?
<mdke> dholbach: http://paste.ubuntu-nl.org/36147/ was the error
<dholbach> mdke: ok, we should fix that - can you add that pre-depends?
<dholbach> mdke: looks like a warning to me - did the build stop then?
<mdke> dholbach: that was everything in the email, it says rejected
<dholbach> ok
<dholbach> then we should fix that
<mdke> but I saw the upload on the changes mailing list, which is why I thought perhaps you'd done it again
<dholbach> no, I did not
<dholbach> I was too busy to see that happened
<mdke> ok, perhaps the changes mailing list carries rejected uploads too?
<dholbach> I think it was accepted on the buildd, but then failed to build
<mdke> ok
<mdke> I'm not very confident with adding something like that with a version number, but if you tell me what it should look like I'll do it
<dholbach> Pre-Depends: dpkg (>= 1.10.24)
<mdke> ok
<dholbach> I'll do another upload of that later on as well
<dholbach> at some stage it'd be nice if the doc team made use of the sponsoringprocess
<dholbach> that way you're not blocked on me, but anybody can do uploads for you
<mdke> dholbach: ok. I'm sorry to chase you about it all the time
<dholbach> no no, no problem
<dholbach> I just thought it might be better, if you weren't blocked on me
<dholbach> right now the packages are in a good enough shape so that anybody can take care of them
<mdke> ok. Sometimes I bug Laserjock too :)
<mdke> alright, I've made the change and pushed it up to lp
<dholbach> rock
<mdke> thanks for the help
<dholbach> anytime :)
<saispo> Fetch failure: git://kernel.ubuntu.com/ubuntu/ubuntu-feisty.git <- it's normal ?
<dholbach> can somebody move ubuntu-dev-tools out of NEW?
<seb128> dholbach: having a look
<dholbach> seb128: you ROCK :)
* dholbach hugs seb128
* seb128 hugs dholbach ;)
<seb128> 404main, weird name ;)
* dholbach is not author of that one :)
<seb128> dholbach: looks good, you just forgot to list Canonical to the list of copyright holders
<seb128> dholbach: I will accept it now, would be nice to fix it in bzr though
<dholbach> I'll do that
<seb128> thanks
<dholbach> I want to add a tool to upload to PPA and automatically mark/tag bugs soon anyway
<dholbach> (once the new pylpbugs is up and I managed to do a bunch of other things)
<seb128> isn't uploading to ppa just a matter to change the dput config?
<dholbach> yes
<dholbach> but I'd like to just run       revuput my-ppa       to let the tool automatically run debuild, upload and make sure to add a comment, etc to the bug that is mentioned in (LP #xxx)
<dholbach> (all according to SponsorshipProcess)
<dholbach> maybe even file bugs at some stage
<dholbach> it's just a shame we only have the mail interface for filing bugs atm
<dholbach> thanks a lot again seb128
<seb128> you're welcome
<seb128> speaking about Process
<seb128> do we have a script for uvf exception requests?
<dholbach> no, not yet
<dholbach> but I agree, we should have one
<dholbach> it'd be nice
<dholbach> do you think the idea I outlined does make sense?
<seb128> yes
<dholbach> good :)
* dholbach hugs super-seb128
* seb128 hugs super-dholbach
<dholbach> ;-)
<Riddell> Mithrandir: tribe 6 posting to u-d-a needing approval
<Mithrandir> Riddell: approved
<StevenK> Mithrandir: Can I beg you for a sync without filing a bug or waving a UVFe around? :-)
<StevenK> Mithrandir: (There are no Ubuntu changes)
<Mithrandir> StevenK: what package?
<StevenK> Mithrandir: kbuild
<soren> StevenK: Any particular reason why you haven't uploaded virtualbox yet?
<StevenK> soren: Because it doesn't build, and requires the new kbuild to do so anyway.
<soren> StevenK: Ah. I must have misinterpreted your "If you guys want to see build logs and such, happy to attach them"  remark :)
<soren> StevenK: I naively assumed that those build logs would show *succesful* builds :)
<soren> That'll teach me not to make assumptions.
<StevenK> soren: I filed the bug before I tried to build it. I added the adduser dependancy, filed the bug, and then tried to test build it.
<StevenK> soren: I also naively assumed that since it built for Debian it would build for us, too. :-)
<StevenK> Mithrandir: Oh, do you have a sec for a dorky archive question?
<Mithrandir> StevenK: sure
<StevenK> Mithrandir: Why is napi in supported?
<StevenK> Er, nabi, sorry
<Mithrandir> nabi                                     | nabi                            | Gutsy supported seed          | Changwoo Ryu <cwryu@debian.org>                                |          428378 |            1008
<Mithrandir> no idea _why_ it's in the supported seed, though
<StevenK> It was added to supported during hoary's development.
<StevenK> And is at the moment in DEPWAIT due to a library it wants that isn't in main.
<StevenK> Hrm. Two Mithrandir's. Neat.
<soren> StevenK: nabi looks like something Koreans want. Any particular reason why it wouldn't be in main?
<soren> IIRC we have another few packages in main that are there to enable some sort of exotic input methods?
<StevenK> Hrm. Fair enough.
* StevenK will look at patching together a MIR
<soren> StevenK: kbuild is only used by VirtualBox. Do you see any reason why we shouldn't uvfe it?
<StevenK> soren: [18:46]  < StevenK> Mithrandir: Can I beg you for a sync without filing a bug or
<StevenK>                    waving a UVFe around? :-)
<StevenK> I'm handling it, I assure you.
<soren> Oh. :)
<soren> StevenK: I'll scurry off and try to make myself useful again then :)
<StevenK> Mithrandir hasn't answered me yet, though. *hint* :-)
<seb128> soren, StevenK: I would like to sync the new pigment and elisa from Debian for the cool effect (the current versions we have are really outdated, it was not available previous cycle so no regression, etc), could I get an approval without spending work on filling bugs, attaching logs, etc? ;)
<Mithrandir> seb128: well, I'd probably sync and review together if I ended up approving SK's request.
<Mithrandir> StevenK: I need to finish writing this mail and poke a look at it, then I can give you an answer.
<soren> seb128: It's ok with me.
<StevenK> seb128: My rationale is so I can get virtualbox into Gutsy. And according to soren, virtualbox is the only thing that uses kbuild. So they are two very different situations.
<soren> Mithrandir: FWIW I'm giving a very enthusiastic +1 on the kbuild uvfe.
<seb128> StevenK: you want to speak to Mithrandir I think ;)
<StevenK> Mithrandir: ^
<StevenK> seb128: Sure, but I wanted to tell you that I'm not just doing it on a whim.
<ogra> mjg59, have a look at bug 48212, would it make sense to have dhcp3-server by default in the config ?
<ubotu> Launchpad bug 48212 in ltsp "ltsp's dhcpd fails after server is hibernated" [Wishlist,In progress]  https://launchpad.net/bugs/48212
<seb128> StevenK: so that's ok from you for the uvf exception? ;)
<Le-Chuck_ITA> Hi all
<Le-Chuck_ITA> I don't know if this is the right place to discuss this
<seb128> Le-Chuck_ITA: "this" being?
<Le-Chuck_ITA> well
<Le-Chuck_ITA> we have apprenticeships at university here
<Le-Chuck_ITA> and I might be involved in the organization of some of them
<Le-Chuck_ITA> I was thinking about giving some LP blueprint
<Le-Chuck_ITA> as topic
<Le-Chuck_ITA> the student has to implement a simple software project
<seb128> good ;)
<Le-Chuck_ITA> the problem is we would need mentoring from inside ubuntu
<Le-Chuck_ITA> and a final short relation discussing the merits of the student
<Le-Chuck_ITA> mentoring would be useful to ensure that, if the blueprint is implemented right
<Le-Chuck_ITA> it makes into ubuntu soon
<Le-Chuck_ITA> and the final relation is used to grade the student
<Le-Chuck_ITA> the former is just to attract students
<Le-Chuck_ITA> but the latter is very important
<soren> Le-Chuck_ITA: Hmm... That sounds like quite a bit of work to commit to just like that :) Maybe you could post to the mailing list and provide a bit more detail of what (and how much) would be expected from Ubuntu?
<iwj> OMG WTF if you write `LIBC_' anywhere in the template for the libc postinst it sedderies it to `libc6_'.
<Le-Chuck_ITA> that would be the next step, I was here just to understand if such a thing would be possible
<Le-Chuck_ITA> what do you mean with "quite a bit of work"?
<Le-Chuck_ITA> of course mentoring would be done at university too
<Le-Chuck_ITA> in the end, we have a student working for a couple of months
<Le-Chuck_ITA> and we only need two persons to periodically check that progress is in the right direction
<Le-Chuck_ITA> one here and one there :)
<soren> Le-Chuck_ITA: Oh, I see.
<soren> Le-Chuck_ITA: Still, a post to the mailing list with that bit of information and a rough schedule would be good. It's easier to get the right people (the ones who have the power to commit a bit of man power to this) into to loop that way.
<Le-Chuck_ITA> that's fine
<Le-Chuck_ITA> what mailing list do you suggest?
<soren> ubuntu-devel-discuss, I think.
<soren> https://lists.ubuntu.com/mailman/listinfo/Ubuntu-devel-discuss
<Le-Chuck_ITA> ok, thanks
<Le-Chuck_ITA> oh
<Le-Chuck_ITA> sorry I still have to learn not to close IRC windows :)
<Le-Chuck_ITA> in gaim, I mean, where I use to close them all the time
<Le-Chuck_ITA> bye and thanks
<asac> stgraber: https://code.launchpad.net/~asac/network-manager/ubuntu.0.6.x.dev.opennet ... should bring the ultimate healing :)
<asac> (of course only in combination with https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac)
<Mithrandir> StevenK,soren: you've tested the new version with virtualbox?
<dholbach> hrm, why does my backlight switch back to dark every now and then?
<Company> dholbach: because your machine is idle?
<geser> Mithrandir: can you please give-back xmms-crossfade on lpia. Thanks.
<Ng> dholbach: I get that, and sometimes it then goes back to being bright again (even if the machine isn't idle, but I think g-p-m and idleness are broken atm in gutsy)
<Adri2000> Mithrandir: please give back djplay on sparc and amd64
<Ng> e.g. my g-p-m settings say to sleep if idle for 15 minutes, but it does it after 5 as per #135813)
<Mithrandir> Adri2000,geser : given back
<dholbach> Company: my machine is not running on battery
<dholbach> Ng: ok
<Company> my macbook ponly goes idle when on battery
<Company> when _not_ on battery
<Ng> for bonus points, my machine now suspends when I pull the AC
<Adri2000> Mithrandir: thanks
<dholbach> I have that every now and then too :-/
<Company> Ng: does it come back when you plug the ac back in? ;)
<Ng> Company: no ;)
<Ng> I've not filed a bug about that yet though, because I wanted to make sure it was always happening, but it is :(
<Company> luckily g-p-m lists events in its graphs
<Company> so you can check if it's g-p-m's fault or not
<StevenK> Mithrandir: virtualbox won't build with the old kbuild.
<Mithrandir> StevenK: well, I approved and did the sync, so. :-)
<StevenK> Mithrandir: Heh, thanks. :-)
<StevenK> Now to see if virtualbox runs, now I have it building on both amd64 and i386.
<Mithrandir> shiny
<StevenK> Hopefully, this will make the tribe6 release notes.
* StevenK will make one more change if it works, in that it requires the newer kbuild.
<StevenK> By rights, the Debian boffin in charge of this thing should do the same.
<StevenK> Woot! It runs.
<StevenK> Now to see if boots a VM
<StevenK> if it, even
* StevenK points jigdo at his local mirror, and waits a few minutes.
<StevenK> Mithrandir: What would say to a virtualbox-modules package that Build-Depends on virtualbox-source, linux-headers-2.6.22-* and built modules for -386/-generic for i386 and amd64?
<StevenK> Hold on a second, surely Debian has already done the work for this ...
<Mithrandir> StevenK: sounds like something that could well be part of linux-ubuntu-modules?
<StevenK> That sounds like a better idea.
<StevenK> Mithrandir: Except that linux-ubuntu-modules-2.6.22 is in main.
* StevenK makes a backport of kbuild to feisty so he can install and build the module.
<seb128> StevenK: so, are you ok with the elisa uvf exception?
<StevenK> seb128: I didn't know that was a serious question, sorry.
<seb128> StevenK: what do you think that was? ;)
<seb128> I need 2 motu-uvf members approval ;)
<StevenK> seb128: A jab about what I asked Mithrandir? :-)
<seb128> ahhhh
<StevenK> seb128: Is there a bug?
<seb128> no, I asked soren and you because I want to sync it and I don't want to spend an hour doing diffstats, etc
<seb128> no, that was the reason I asked on IRC, going faster
<seb128> as said we didn't ship it before so there is no regression and the current version is really outdated
<StevenK> seb128: Okay, that's fine. Rationale and main differences?
<StevenK> Ah, that answers the rationale bit.
<seb128> nothing uses pidgment out of elisa
<seb128> so that's basically updating a new application
<seb128> which will make users and upstream happier
<StevenK> seb128: Okay, +1, go ahead
<seb128> thanks
<StevenK> seb128: Sorry for the misunderstanding
<seb128> that's alright ;)
<StevenK> Come on kbuild, build quicker.
<seb128> who gives approval for new universe packages?
<seb128> bug #136972
<ubotu> Launchpad bug 136972 in libcairo-perl "autopkgtest gutsy libcairo-perl: erroneous package!" [High,New]  https://launchpad.net/bugs/136972
<StevenK> motu-uvf, I guess
<asisak> seb128: now? MOTU-UVF as well
<seb128> libcairo-perl Build-Depends on libtest-number-delta-perl
<seb128> can we sync it to fix the FTBFS? ;)
<StevenK> seb128: It sounds fine to me, it's impact looks to be minimal
<seb128> thanks
<seb128> soren: ok for you? ;)
<StevenK> soren, Mithrandir: virtualbox uploading
<soren> seb128: Huh?
<soren> seb128: If it's kbuild, sure.
<StevenK> Mithrandir: Can I sweet talk you into pushing virtualbox through NEW? :-)
<seb128> soren:
<seb128> <seb128> libcairo-perl Build-Depends on libtest-number-delta-perl
<seb128>  can we sync it to fix the FTBFS? ;)
<seb128> soren: libcairo-perl has been synced on Debian but libtest-number-delta-perl is not available in Ubuntu yet
<Mithrandir> StevenK: preferably not, I'm in the middle of something a bit urgent.
<StevenK> Maybe I'll sweet talk seb128. :-)
<seb128> StevenK: is that something easy to review? ;)
<soren> seb128: Sure.
<StevenK> seb128: Hopefully. It passed Debian's NEW for main, so there shouldn't be anything to drastic in it
<seb128> k
<seb128> StevenK: virtualbox accepted to universe
<StevenK> seb128: Yay, thanks
* sits fails to get network manager doing dhcp going on an out of the box Gutsy install
<seb128> iwj: could you teach autopkgtest to not file duplicates?
<seb128> bug #127986
<ubotu> Launchpad bug 127986 in libelf "gutsy/amd64: ftbfs / autopkgtest failure" [Undecided,New]  https://launchpad.net/bugs/127986
<seb128> bug #128022
<ubotu> Launchpad bug 128022 in libelf "gutsy/amd64: ftbfs / autopkgtest failure" [Undecided,New]  https://launchpad.net/bugs/128022
<iwj> seb128: it's supposed to.
* iwj looks.
<seb128> bug #136986 also
<ubotu> Launchpad bug 136986 in libelf "autopkgtest gutsy libelf: erroneous package! (dup-of: 127986)" [High,Invalid]  https://launchpad.net/bugs/136986
<ubotu> Launchpad bug 127986 in libelf "gutsy/amd64: ftbfs / autopkgtest failure" [High,New]  https://launchpad.net/bugs/127986
<seb128> I've just dupped those
<iwj> Bear with me, and it's probably not worth doing much about it yourself since if it's doing this lots I should fix them all up in batch mode.
<seb128> doesn't look like it's doing that a lot
<seb128> I only spotted those
<iwj> OIC those bug reports are the ones I forwarded manually.
<iwj> I'm afraid it can't see those when it looks for duplicates.
<seb128> ok, so we should keep the new one and close the ones you filed manually as dups?
<iwj> Yes.  I'll do that.
<seb128> in fact you sent many bugs twice
<iwj> Yes.
<iwj> It was getting so I couldn't remember which were dupes and I didn't have any useful record.
<iwj> That's why I automated it.  But sorry about the stuff from before.
<seb128> that's alright
<seb128> http://tinyurl.com/2t57hz has a list of autopkgtest sorted by product if you want
<seb128> it's easy to spot duplicates from it
<seb128> if somebody wants to clean those ;)
* LongPointyStick pokes around
<iwj> Yes, that should be fixed up.  Also the others should be milestoned.
<iwj> I'll take care of it.
<iwj> Thanks and sorry to cause you extra work.
<seb128> no problem ;)
<dholbach> mako: CC meeting?
<Riddell> mdke: are you getting e-mailed about all my kubuntu-members ppa uploads?
<StevenK> seb128: Could I also sweet-talk you into promoting libhangul, as per https://wiki.ubuntu.com/MainInclusionReportLibhangul ?
<StevenK> infinity: Ping, once more with feeling.
<seb128> StevenK: done
<StevenK> seb128: Thanks
<seb128> you're welcome
<StevenK> Hrm. virtualbox doesn't appear in P-a-s.
<stgraber> asac: I'm at school, I'll sync and test it a bit later
<asac> stgraber: thanks.
<seb128> Riddell: does kpdf uses poppler in gutsy?
<iwj> Is there an (unofficial) freeze ?  What do people think of the idea of me uploading libc with the ldconfig wrapper which arranges to run ldconfig just once, using dpkg triggers ?
<Treenaks> iwj: only if you also do the fonts + fc-cache ;)
<seb128> iwj: I don't think there is any freeze official or not at the moment, no real opinion about the trigger, I would say better to do it now than later
<ogra> ++
<ogra> we wont have a freeze afaik
<iwj> That was my feeling (or I wouldn't have asked, really).
<ogra> but should solve milestone bugs
<iwj> It's a nice small diff and I'm reasonably confident about it provide I wasn't told lies about ldconfig ...
<ogra> (and i guess the dailies should stay somewhat useable, since they were pointed to in the announcement)
<iwj> Right, as you say.
<iwj> I don't think this will break the dailies.
<Riddell> seb128: not currently, it didn't work with the old version we have, now we have a 0.6 beta I can try and port the poppler patch again
<Riddell> iwj: there's no freeze, just try to fix more than you break
<seb128> Riddell: ok, I was wondering because there was a bug that looked a poppler issue where the submitter wrote that kpdf works correctly
<Riddell> seb128: so it probably is a poppler issue in that case
<seb128> right
<seb128> thanks
<Riddell> seb128: did you test the gtk flash initialisation patch?
<seb128> Riddell: with opera yes
<Riddell> seb128: did it work?
<seb128> yes
<Riddell> seb128: excellent, is it uploaded?
<seb128> and acroread starts again also
<Riddell> ooh, bonus
<seb128> yes, I did upload on friday afternoon
<Riddell> seb128: great, I'll try kdebase with our gtk patch removed then
<iwj> Riddell: Right.  I was thinking I might clean up some of the easier autopkgtest ftbfs's.
<soren> Um.... I've got pkg-create-dbgsym installed in my sbuild chroot, and the build logs shows that they're created, but they don't end up in my $cwd.. Is there a magical setting to tweak somewhere?
<sits> how do you rebuild a deb without a patch when the deb is using quilt?
<seb128> sits: comment the corresponding line in debian/patches/series?
<sits> seb128: hmm ok let's give that a go
<sits> and with that tip I now realise that the patch in question was already disabled...
<sits> hmm no joy. I just can't get the hang of this deb/quilt business. My network manager problem will just have to stay for now
<seb128> sits: https://wiki.ubuntu.com/MOTU/School/PatchingSources
<seb128> sits: you have a basic example of quilt usage on this page, should be enough to add or edit a patch
<sits> hmm
* sits gets an email for a bug that seems to have slipped away from the reported bugs page
<Keybuk> Metal Singer Required [...]  # Have a good ear for rhythm, tonality and diversity.
<Spads> DOES NOT COMPUTE
<Keybuk> clearly Jono doesn't realise the inherent contradiction in his requirements
<pygi> :D
<highvoltage> how does one "sing" metal?
<Spads> http://zork.net/~sneakums/fortunes/sneakums/542 <-- Keybuk
<Keybuk> Spads: "there is good service on all lines, except the Circle line which is delayed as usual"
<Keybuk> the sound of everybody in a packed underground station laughing is quite extraordinary
<Spads> Keybuk: "We'll be delayed here at Gloucester Road for a few minutes, but you take what you can get when you ride the District line"
<mathiaz> kylem: did you manage to build a kernel with the latest apparmor ?
<mathiaz> kylem: or when will be the next kernel upload ?
<kylem> today. and yes.
<mathiaz> kylem: According to the git tree, the kernel still provides apparmor-modules-2.0
<mathiaz> kylem: actually, it's l-u-m that provied apparmor-modules-2.0.
<kylem> yes.
<kylem> because i haven't pushed it yet, because i had to update unionfs.
<mathiaz> kylem: will the next l-u-m provide apparmor-modules-2.1 ?
<kylem> yes.
<mathiaz> kylem: excellent.
<Hobbsee> seb128: if you make a script for uvf exceptions, i will shoot you.
<seb128> Hobbsee: hey
<seb128> Hobbsee: why? ;)
<Hobbsee> or at least, if you ever make it public.
<Hobbsee> maybe it can have a disclaimer: "by using this script, i will actually look at the changes, and i will not mass-file UVFe's.
<StevenK> "Lest the motu-uvf / ubuntu-release team brutally slaughter me."
<Mithrandir> Hobbsee: if that happens, we'll mass-reject them and strip the person of their groups, then roll them in tar and feathers and parade them around.
<StevenK> My way sounds much more fun.
<jdong> hmm... if I wanted to install a Gutsy today, should I install the latest tribe or daily? :)
<Hobbsee> Mithrandir: ROFL!
<jdong> i.e. is today's daily working :D
<Hobbsee> seb128: because i've seen people misuse the requestsync script as well.
<Hobbsee> StevenK: yes, well.  we have to get down to some slaughtering of abusive people.
<Hobbsee> at some point
<seb128> Hobbsee: well, better to have a tool standardizing the format to use, etc
<Hobbsee> seb128: seriously, you're a core dev.  just ask.
<Hobbsee> oh wait, that's after i push the next component of the master plan.
<Hobbsee> seb128: depending on whther the decision is to leave a paper trail or not, you can probably just ask as a first step, and we'll say "sure", or "can we see more info on that, eg diffstat, changelog" or "no, you're on crack"
<seb128> Hobbsee: right, that's what I've been doing today, I asked
<Hobbsee> seb128: the point at where you're filing mass diffstats while knowing that there's no point...suggests that our proceedure is too complex
<seb128> not too complex
<seb128> there is just lot of things to do
<Hobbsee> seb128: badly worded.  that it's causing needless work.
<Hobbsee> seb128: really, we should only need the stuff if we cant see an immediate "yes, we should do this"
<seb128> and I would like to have something that does the diffstat, changelog diff, etc for you
<seb128> right
<Hobbsee> true.  i just hope that doesnt lead to people filing it without looking.
<Hobbsee> seb128: i have various plans for the motu-uvf team.  one step in world domination at a time.
<StevenK> I'm not sure I want to be bent to Hobbsee's will.
<Hobbsee> StevenK: sure you do!
* Hobbsee suddenly thinks of vogon poetry
<StevenK> Eek
<StevenK> There's imagery I don't need.
<Hobbsee> haha
<Kopfgeldjaeger> hi
<Hobbsee> StevenK: it was more a "you'll bend voluntarily, or you'll get attacked by the Long Pointy Stick of DOOOOM!!!!!!!!!!!!!!!! first"
<StevenK> Ah. Bend, or break. :-P
<soren> StevenK: Hm. VirtualBox seems to be working nicely.
<Mithrandir> StevenK: you might not have a choice.
<stgraber> asac: package is building
<soren> StevenK: Gah, I jinxed it.
<StevenK> soren: Hmph
<Hobbsee> Mithrandir: oh, he has a choice.  to cooperate peacefully, or to cooperate by force.  that is a choice :P
* StevenK is only teasing, anyway
* lamont wonders how to tell d-i that an install step succeeded, even though it failed...
<iwj> Boggle
<iwj> /work/AutomatedTesting-packages/build/tcl8.4-8.4.15/unix/../compat/memcmp.c:55: warning: dereferencing 'void *' pointer
<cjwatson> d-i> edit the postinst, make it exit 0, run it again
<ogra> hrm
<asac> stgraber: drum roll ...
<sits> hey asac
<sits> asac: do you know of any obvious network manager dhcp issues?
<Hobbsee> greetings, asac
<asac> Hi Hobbsee
<asac> sits: well ... what chipset?
<Hobbsee> asac: FWIW, i tried the iwl3945, instead of the ipw3945 module earlier.  no dice.
<sits> asac: ipw3945
<iwj> Jesus H Christ.  tcl has a memcmp.c which (a) it is using but which (b) IS BUGGY.
<sits> asac: no WEP/WPA
<asac> sits: yeah ... its a driver issue
<sits> asac: hng
<asac> sits: if you want you could try my ipw3945 kernel module branch
<sits> asac: is it just racy when the interface is brought up?
<sits> asac: (yeah sure I'll try your branch if it's prebuilt)
<asac> sits: well ... there are multiple issues
<sits> asac: good grief
<asac> sits: no not prebuild ... https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac
<asac> i have no idea how to ship it prebuild
<asac> just want a few more confirms before submitting this patch to the kernel-team
<sits> asac: can I build your module without the kernel source to hand?
<asac> Hobbsee: you wanna try the branch above?
<asac> sits: i think you just need -headers
<Hobbsee> asac: not currently, but perhaps later.
<sits> asac: that's good enough
<Hobbsee> it does need to work at uni, in some form or another, too.
<asac> sits: make IEEE80211_IGNORE_DUPLICATE=y SHELL=/bin/bash
<asac> sits: instdie the branch
<asac> Hobbsee: thanks ... ping me ... or just try when you have time (read above)
<Hobbsee> asac: how do you revert back to the original?
<asac> Hobbsee: i think you have to copy the ipw3945.ko module somewhere as a backup
<Hobbsee> asac: ah right.  will remember that.
<sits> asac: bzr checkout intructions?
<mantiena-baltix> hi all
<Hobbsee> sits: bzr get <address as listed above>
<asac> sits: bzr branch https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac
<asac> yeah ... or get ... or checkout ... or clone?
<sits> python errors
<asac> python errors?
<sits> bzr: ERROR: exceptions.KeyError: 77
<Hobbsee> asac: didnt think you could checkout if you werent a part of the team.
<asac> sits: are you running gutsy?
<sits> let me try again
<sits> asac: yes
<Hobbsee> unless it's a read-only checkout, which i thought was something else
<asac> Hobbsee: i think they should all work ... but usually i just do bzr branch
<sits> neither branch nor get seem to work
<Riddell> mvo: ping
<mvo> hello Riddell
<Riddell> mvo: knetworkmanager in feisty is now network-manager-kde in gutsy
<asac> sits: did you install anything manually at some point?
<Riddell> mvo: how do I get DistUpgrade to install the other?
<Riddell> mvo: both packages provide the other, the name was swapped around
<mvo> Riddell: the easiest is probably a transitional package (empty knetworkmanager)
<asac> sits: haven't seen a Key Error ... maybe its a bad bzr plugin?
<sits> asac: not that I'm aware of
<sits> just installed bzr this very moment
<mvo> Riddell: just create a empty knetworkmanager package in the network-manager-kde build
<asac> sits: try bzr plugins
<Riddell> mvo: and remove the Provides?
<sits> I tried quoting the URI but the same
<sits>  /usr/lib/python2.5/site-packages/bzrlib/plugins/launchpad
<sits>         Launchpad.net integration plugin for Bazaar
<asac> sits: ok is debian-python installed?
<sits> probably not...
<asac> aeh python-debian
<sits> hmm space is going to get tight...
<asac> python-debian is just 48K
<sits> ah ok
<mvo> Riddell: yes
<sits> asac: same problem
<sits> (with python-debian installed)
<asac> sits: ah i think its python-pycurl
<sits> ah you're right
<Riddell> mvo: ok.  also how can we get kubuntu-restricted-extras into app-install-data?
<sits>    File "/usr/lib/python2.5/site-packages/bzrlib/transport/http/_pycurl.py", line 179, in _get_full
<sits>     self._curl_perform(curl, header)
<sits>   File "/usr/lib/python2.5/site-packages/bzrlib/transport/http/_pycurl.py", line 269, in _curl_perform
<sits>     e[0] , _pycurl_errors.errorcode[e[0] ] , e, url)
<sits> KeyError: 77
<Hobbsee> Riddell: binary or source?
<mvo> Riddell: sure, I can add it right away
<asac> sits: do you have a minimal gutsy install?
<sits> asac: it's fairly standard off the CD then updated yes
<sits> it's not super slim - it was  standard GNOME install
<asac> well please ask on #bzr ... they probably know it right away
<Riddell> Hobbsee: .desktop
<asac> sits: sorry for the inconvenience ... but i never had anyone who couldn't run a basic bzr branch
<sits> asac: oh for a HTTP'd tarball : )
<Hobbsee> Riddell: errr....
<Hobbsee> Riddell: just as long as you're aware that k-r-e source doesnt exist anymore
<Riddell> it doesn't?
<Hobbsee> it's in u-r-e
<Riddell> Hobbsee: the binary package seems to be
<Hobbsee> as is the x-r-e binary
<Hobbsee> Riddell: the binary package is in u-r-e, k-r-e as a source package no longer exists.
<mvo> Riddell, Hobbsee: the binary name is all that g-a-i cares for (and adept_installer)
<Hobbsee> mvo: ah, excellent.
<mvo> Riddell: it should be available in the next upload
<Riddell> thanks
<asac> sits: http://people.ubuntu.com/~asac/ipw3945-1.2.1.asac.tar.gz
<mantiena-baltix> tormod, hi
* sits scrolls up
<mantiena-baltix> tormod, are you responsible for grub in ubuntu ?
<tormod> mantiena-baltix: no, that would be the core-dev team.
<sits> asac: wish me luck
<asac> sits: you need the kernel headers installed ... at best install module-assistant and then run module-assistant prepare
<tormod> mantiena-baltix: I just prepared the last versions.
<asac> sits: luck?
<mantiena-baltix> tormod, yea, I saw your name in changelog :)
<asac> sits: build succeeded?
<sits> asac: it's compiled I'm about to rmmod the old one
<tormod> mantiena-baltix: you can still try asking :)
<mantiena-baltix> :) there is one, pretty importat, but very easy to fix bug in Ubuntu's grub - bug #8\3690
<mantiena-baltix> bug #83690
<ubotu> Launchpad bug 83690 in grub "update-grub hardcodes to 'Ubuntu'" [Undecided,New]  https://launchpad.net/bugs/83690
<asac> sits: ok cool :)
<mantiena-baltix> lsb_release should be used instead of hardcoding Ubuntu in grub's menu.
<mantiena-baltix> tormod,  title=`/usr/bin/lsb_release -s --description`
<asac> stgraber: any info how to best replace the old module with the new one? i think one has to restart the daemon as well, right?
<sits> bad news
<sits> asac are you there?
<sits> asac: bad news no change
<sits> it still doesn't get a dhcp lease
<tormod> mantiena-baltix: that should better be fixed in Debian, so that Ubuntu also doesn't have to change it :)
<sits> dmesg says
<sits> ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.2mp
<asac> sits: thats not the module i provided
<sits> ah fish
<sits> hang on
<asac> mine is 1.2.1 atm
<mantiena-baltix> tormod, yea
<cypherbios> hi mvo, did you receive my email?
<mantiena-baltix> yea, new packages search page and results at http://packages.debian.org looks great
<mantiena-baltix> impresive - debtags are also integrated ! http://packages.debian.org/sid/grub
<sits> test
<sits> asac: are you sure the module you gave me was correct?
<asac> sits: look in ipw3945.c
<asac> there is a ipw3945.c:#define IPW3945_VERSION "1.2.1"
<asac> you see that?
<stgraber> asac: ok, I have the results from my tests (sorry I'm not at home so I had to simulate a public hotspot using a laptop+madwifi)
<stgraber> asac: that seems pretty good (except some NM crash due to stress I think)
<stgraber> asac: I can connect to WPA, then switch to public without any problem
<asac> stgraber: do you still run into stale/deadlocked states?
<asac> stgraber: you can run NetworkManager from the src/ directory directly with gdb
<asac> e.g. gdb .libs/lt-NetworkManager
<asac> then
<asac> run --no-daemon
<sits> #define IPW3945_VERSION "1.2.1" VD VM VP VR VQ
<sits> the original is much smaller than what I currently have
<asac> and when it crashes, please give me the backtrace
<asac> stgraber: what does sits need to do to load the module?
<asac> sits: how did you install/load the module?
<asac> sits: the make command doesn't copy it to the right directory (in case you assumed it does)
<sits> mv the module in to the main tree, run depmod then use modprobe
<sits> rename old module
<asac> sits: did you restart the regulatory daemon as well?
<stgraber> asac: I just unloaded everything, then did the following :
<stgraber> wired -> WPA -> wired -> public -> WPA -> public -> wired -> public -> wired
<sits> asac: that seemed to die at its own volution when the interface was shut down
<asac> stgraber: how unloaded? just rmmod ipw3945?
<asac> stgraber: great ... does the crash happen at that time?
<stgraber> killed ipw3945d, rmmod ipw3945, modprobe ipw3945, /etc/dbus/event.d/*Network* stop/start
<stgraber> asac: no
<sits> asac: I will try again - I only renamed the old module
<stgraber> asac: only thing I had was a delay once switching from public to wired (due to AP_SCAN 0 it seems)
<asac> sits: yes ... try what stgraber says above
<stgraber> asac: but only occured once on the two try I did
<stgraber> (it was the first public -> wired switch, second went correctly)
<asac> stgraber: well wpasupplicant has really high latency ... which is why we got the cannot connect issue
<stgraber> imo, the NM+ipw3945 we currently have rocks, only thing that can be done at this point is trying to have something a bit faster
<asac> yeah ... i am not sure why it takes so long ... i hope its just a wpasupplicant problem
<asac> e.g. bad polling for something
<asac> stgraber: ok thanks ... i just want one more who can confirm that things are rocking now ... then i will submit the ipw3045 patch to kernel team and upload new nm once they uploaded new lum
<stgraber> it seems to try to associate 2 or 3 times before it works (looking at iwconfig, you see the ESSID, then the MAC, then the key is flickering 2-3 times, then you have the key+associated)
<asac> stgraber: during what stage is that?
<stgraber> hmm, end of stage2 I'd say (after the WPA config is sent to wpa_supplicant)
<asac> ok ... so it takes time until nm gets the connect event ... after enable_network ... right?
<stgraber> yes, but that's not NM fault
<alex-weej> mvo: hey you there?
<asac> stgraber: anyway since i see this long blocking of wpa for other drivers as well ... it appears to be driver unrelated
<asac> or if in kernel the whole subsystem has an issue
<stgraber> ok
<stgraber> I have something strange with the hardware I have at home
<asac> stgraber: just one thing ... how did you enable debugging?
<stgraber> my Trendnet AP associate after the 3-4 try
<asac> i want to setup a debuggingNM page
<asac> with instructions on how to get kernel log messages
<stgraber> when my Buffalo one (openwrt) associate the first time
<stgraber> asac: load the driver with debug=1, modprobe ipw3945 debug=1
<sits> asac: I'm sure it's loading the right module
<sits> asac: modinfo shows the kernel it was compiled against has changed
<stgraber> then : echo 6252 > /sys/bus/pci/drivers/ipw3945/debug_level
<stgraber> that should enable most interesting debug detail
<stgraber> debug output ends up in syslog
<sits> asac: are you sure that the issue is module related? The card is definitely connecting to the AP and dhclient eth1 is working as expected...
<asac> stgraber: what version does dmesg show for the module when you load it?
<asac> sits: yes i am 99.9% sure
<sits> asac: OK.
<stgraber> asac: it doesn't give a version number, but modinfo says 1.2.1d
<sits> modinfo here says:
<sits> version:        1.2.2mp
<sits> vermagic:       2.6.22-10-generic SMP mod_unload 586
<asac> sits: hmm your version info is still the old one ... sorry ... now away for a few hours
<asac> sport
<asac> cu later
<Luke> WPA-Enterprise doesn't work with Ubuntu (even Gutsy) at Purdue University and I'm talking with the head wifi IT guy to try to get it worked out. Who should I talk to on the Ubuntu side? I don't know enough about wifi to be able to pinpoint the problem.
<asac> Luke: ping me tomorrow
<mvo> alex-weej: yes
<Mithrandir> Luke: asac would be your man, I believe.
<alex-weej> mvo: i fixed up some more notification daemon theme goodness: https://bugs.launchpad.net/ubuntu/+source/notification-daemon/+bug/136660
<Luke> Mithrandir: thanks
<ubotu> Launchpad bug 136660 in notification-daemon "Patch to improve shaping and border rendering in uncomposited environment; add RGBA support for composited" [Undecided,New] 
<alex-weej> mvo: how come the ubuntu theme isn't in its own package anyway?
<Luke> asac: you around?
<mvo> alex-weej: historical reasons
<mvo> alex-weej: the current approach with the patch is a pita maintaing wise
<alex-weej> yeah i'll bet
<alex-weej> should i open a bug against making a new package then?
<sits> asac: I don't think the problem is the driver in my case
<mvo> alex-weej: its a bit late for this for gutsy, I will do a diff of the old and new tree for now to see what actually changed
<alex-weej> mvo: it's really not that much... :/
<mvo> alex-weej: but we totally should either get it into its own package or submit it upstream (later is probably better)
<alex-weej> have the ubuntu theme upstream?
<mvo> alex-weej: not much is good, as this means better chances to get it in :) (as its late in the release cycle)
<alex-weej> ok, i can diff the patches if you want
<mvo> alex-weej: yeah, it probably will have to be renamed to something like "yellow" :)
<alex-weej> or i guess i could diff the theme.c's
<alex-weej> save you some time
<alex-weej> i'll go do that so you can see easier
<mvo> alex-weej: that would be welcome
<alex-weej> mvo: first and foremost though, it's a bug fix :P
<sits> asac: I don't think the issue is the wifi driver
<sits> asac: (in my case)
<sits> asac: I've just grabbed my emergency PCMCIA card and I have exactly the same issue wrt to DHCP on that
<mvo> alex-weej: :)
<tonyyarusso> Say, is there an IRC channel where one could observe Archive admins processing packages from the NEW queue?
<alex-weej> mvo: http://launchpadlibrarian.net/9101987/diff i don't know why there are loads of !'s in it...
<alex-weej> it was a diff -p
<Luke> asac: I've sent you an email about Purdue University wireless connectivity with NM if you wouldn't mind looking through it when you get a chance
<alex-weej> all of the code outside of draw_border was copied verbatim from the standard theme
<alex-weej> for the "enable_transparency" stuff
<alex-weej> ah i see what the !s are for, clever
<alex-weej> makes it more readable :o
<mvo> alex-weej:  I'm more used to reading diff -u outputs TBH
<alex-weej> i normally just do svn diff and don't look back, so i'm not used to diff options
<glatzor> ping bryce
<alex-weej> mvo: http://launchpadlibrarian.net/9102019/diffu ;)
<mvo> alex-weej: thanks :)
<cjwatson> svn diff defaults to -u
<alex-weej> ah yeah
<alex-weej> that looks more familiar
<cjwatson> I suppose you might need to say -pu if you're using -x
<alex-weej> i did pu anyway
<mvo> alex-weej: -	draw_rounded_window(mask_cr, 0,1,w,h-2, windata);
<mvo> +	draw_rounded_window(mask_cr, 0, 0, w, h, windata); <- that looks suspicious, the small offset was added to add a small space between two notifications
<mvo> alex-weej: same some lines earlier
<alex-weej> mvo: what's the intention, 1 pixel all the way around?
<alex-weej> in the original draw_border we were drawing the background with draw_rounded_window(cr, 0, 0, w, h, windata);
<alex-weej> that's what threw me off i guess
<mvo> alex-weej: that might be a bug in the old code, I just noticed that the update does no longer have the small gap between two notification that used to be there
<alex-weej> mvo: well we can probably put it back in, but it only actually affects the stackable notifications (i.e. the ones that aren't attached)
<alex-weej> i'd say the best ultimate place for spacing code would be in the positioning code
<mvo> alex-weej: I agree, it should be fixed there
<zasf> mvo: I have a question about bug #134918 if you have 1 minute
<ubotu> Launchpad bug 134918 in restricted-manager "Misleading error message - software source for package is not enabled" [Undecided,Confirmed]  https://launchpad.net/bugs/134918
<alex-weej> yay, stack.c
<mvo> zasf: sure
<zasf> mvo: is there a way to know wich repository a package belongs to if that repo is not enabled??
<mvo> zasf: not in general, but we have that information in /usr/share/app-install/desktop for a lot of packages
<zasf> mvo: ok, that's what gnome-app-install uses for codecs I guess
<mvo> zasf: the strange thing about this bug is that restricted should be enabled by default and repository information should be availalbe too
<mvo> zasf: I read in the report that you tried to reproduce it?
<zasf> mvo: yes
<zasf> mvo: tribe5 workes fine here
<zasf> mvo: no "sources need to be reloaded" issue
<zasf> mvo: not talking about the reported issue with nvidia-glx or nvidia-glx-new, restricted-manager has a problem wich bcm43xx-fwcutter
<mvo> zasf: a problem in what sense?
<zasf> that's in universe and that's why we have this message "the software source for bcm43xx-fwcutter is not enabled"
<zasf> how does r-m know about bcm43xx-fwcutter if user has not universe enabled?
<mvo> zasf: hm, I see. r-m has it hardcoded, it should get promoted to restricted then
<zasf> it would be nice if r-m could call gnome-app-install or other app (command-not-found?) and get info about packages whose repos are not enabled
<zasf> that would be smarter and would reuse g-a-i code to let user enable universe
<glatzor> zasf: not really. non-graphical applications have to be added manually to g-a-i too
<glatzor> zasf: the number of har coded packages is quite small for restricted manager, right?
<zasf> mvo: r-m would face the same problem if user disables restricted and then wants to enable fglrx
<zasf> mvo: but i see this nice thing here /usr/share/app-install/desktop/fglrx-driver.desktop
<zasf> mvo: yes the number is small at the moment
<mvo> zasf: I think the best way for r-m would be to run gnome-app-install and ensuring that a desktop file is available for all packages. this way it gets repository enabling code for free
<mvo> zasf: oh, you said that earlier :)
<zasf> mvo: hehe nice :)
<mvo> zasf: could you add a excerpt from our conversation to the bug page please?
<zasf> mvo: I'll update https://wiki.ubuntu.com/RestrictedManagerImprovements2
<zasf> mvo: so that I let pitti know when he's back
<mvo> zasf: what is this bit about command-not-found in the spec? if you need anything from c-n-f, that could probably be arranged
<zasf> mvo: that was a first idea I had
<glatzor> zasf: mvo: adding a dialog using python-aptsources also provides a simple mechanism to enable components.
<zasf> mvo: but I think g-a-i is much better
<glatzor> zasf: mvo:  python-aptsources also provides a simple mechanism to enable components.
<glatzor> zasf: mvo: it should not be hard to add a corresponding dialog to r-m
<zasf> glatzor: yes but the problem is that in case of bcm43xx-fwcutter r-m doesn't know wich repo it belongs to
<zasf> glatzor: that would happen for nvidia or fglrx as well if user disables restricted repository
<mvo> glatzor: not hard, but we have all this in g-a-i already, so it seems easier to call that (also I'm not sure if we have a way to control it yet)
<glatzor> zasf: you will always have to hardcode this information.
<mvo> glatzor: and all the meta-data is in one place then
<zasf> yes, g-a-i has its own data, r-m calls g-a-i
<zasf> still g-a-i duplicates informations.. like c-n-f does
<glatzor> mvo: zasf: in which way do you want to call g-a-i?
<glatzor> mvo: adding another activation style?
<glatzor> mvo: it seems to be cleaner to just reuse the (Core)ApplicationMenu and aptsources
<mvo> glatzor: right, that is a good way of doing it
<alex-weej> mvo: i've hacked stack.c to pretend that there is an extra n pixels on the bottom and right of each notification
<alex-weej> that gives decent results
<mvo> alex-weej: cool, thanks.
<zasf> glatzor:would you mind providing me a small example as a start point?
<glatzor> zasf: of course. one moment
<zasf> glatzor: thanks
<mvo> glatzor: tests/testAppInstall.py might be something to get a idea (also its quite limited)
<glatzor> zasf: the component activation is done in gnome-app-install-helper
<alex-weej> mvo: https://bugs.launchpad.net/ubuntu/+source/notification-daemon/+bug/137095
<alex-weej> mvo: you can change it to 1px, it's just #define'd at the top
<alex-weej> easy hack for now, right?
<alex-weej> whoops i forgot the diff
<alex-weej> sorted
<mvo> alex-weej: looking
<alex-weej> mvo: when upstream fixes the overlapping bottom panel problem it'll rock even more
<alex-weej> btw i forgot to add, i tested it for different stack orientations too and it's fine
<geser> keescook: Hi, have you time to sponsor bug #136596?
<ubotu> Launchpad bug 136596 in fetchmail "[Merge]  fetchmail 6.3.8-8ubuntu1" [Undecided,New]  https://launchpad.net/bugs/136596
<zasf> glatzor: ok, but I would like g-a-i to call it for me in case he needs to
<zasf> glatzor: so that I don't have to hardcode a package-component dict
<geser> calc: Hi, when you have time can you sponsor the debdiff for bug #130583?
<ubotu> Launchpad bug 130583 in xmlsec1 "libxmlsec1-nss missing pkgconfig file" [Undecided,New]  https://launchpad.net/bugs/130583
<alex-weej> mvo: verdict?
<mvo> alex-weej: looks fine
<alex-weej> mvo: ok, so does that mean the first patch can go in? :D
<LaserJock> mvo: when you hve a minute I've got a couple questions about g-a-i
<mvo> LaserJock: sure, fire
<LaserJock> mvo: ok, first. I've had several people now in #edubuntu that have problems with g-a-i when they don't have a network connection when they install
<LaserJock> mvo: they end up with only the CD as an available repo, but apps still show up in g-a-i so they try to install them and get a cryptic error
<LaserJock> saying that i386 isn't supported
<mvo> LaserJock: oh, ok. I think I know the reasons for this one
<LaserJock> I just wondered if you had seen that before, etc.
<mvo> LaserJock: I milestoned this bug for tribe-6, its not easy to fix unfortunately, but I think I have a way that should work
<LaserJock> LaserJock: thank you
<LaserJock> mvo: second question, how would I go about having g-a-i install a metapackage?
<mvo> LaserJock: what use-case do you have in mind?
<LaserJock> will having it ship a .desktop suffice? or is there a more elegant solution
<mvo> LaserJock: generally add a .desktop file to the app-install-data-ubuntu repository in bzr should be fine (there is menu-data-additional for this)
<mvo> LaserJock: does that sound sufficient?
<LaserJock> for the Edubuntu Addon CD I have a few (~5) metapackages that I'd like to show in the g-a-i  menu that pops up
<ion_> Yay for ldconfig using dpkg triggers.
<mvo> LaserJock: that is going to be interessting, I think we haven't done cdrom repository dependencies yet :)
<LaserJock> mvo: ah, so I could just put  the .desktop in my app-install-data-edubuntu package
<alex-weej> ion_: what does that do?
<mvo> LaserJock: yes, or into the main app-install-data-ubuntu pacakge
<LaserJock> mvo: I already have an -edubuntu one so it's probably less confusing to put it there
<mvo> LaserJock: sure
<LaserJock> hmm, I'm gonna have to patch debian-cd again though
<LaserJock> oh well
<ion_> alex-weej: Instead of running ldconfig in each library packages postinst, it gets run once after all packages have been processed.
<alex-weej> ion_: speedy!
<mvo> LaserJock: its entirely possible that g-a-i will not support that cdrom repo thing out of the box, but fixing it should not be hard, so please nag me about it (or file a bug). its late here in my TZ though :)
<LaserJock> mvo: k, thanks
* mvo leaves for today
<croSmile1> How can I can i find out when was a certain window last active using xprop?
<ion_> iwj: ldconfig doesnt seem to call ldconfig.real at all. libc6 2.6.1-1ubuntu2
<iwj> ion_: What does it do instead ?
<iwj> OMG
<ion_> iwj: Bug #137129
<ubotu> Launchpad bug 137129 in glibc "ldconfig never calls ldconfig.real" [Undecided,New]  https://launchpad.net/bugs/137129
<iwj> Yes, I just spotted.
<cjwatson>  && dpkg --compare-versions "$DPKG_RUNNING_VERSION" ge '1.14.5ubuntu10~~'
<cjwatson> blink, two tildes?
<iwj> Yep.
<ion_> 1.14.5ubuntu10~~ < 1.14.5ubuntu10~
<cjwatson> I know, but ... why?
<Mithrandir> we need a char that always compares as lower, but is not legal in a version number.
<Mithrandir> like \~
<iwj> He knows that.
<Mithrandir> so \~ < ~
<iwj> Oh, I see.
<iwj> :-P
<cjwatson> there was never a 1.14.5ubuntu10~ in Ubuntu AFAICS, let alone 1.14.5ubuntu10~~ - test version on iwj's scratch system? :-)
<ion_> Thats what i assumed. :-)
<iwj> cjwatson: Yep.
<iwj> ion_: Thanks very much for bringing that to my attention.
<iwj> *cough*
<ion_> :-)
<iwj> I did test it but of course as Scott told me (truthfully as it turns out) not running ldconfig doesn't actually break anything ...
<iwj> 1ubuntu3 is on its way through the machinery now.
* Chipzz wonders how long this will go unnoticed :P whois microsoft.com | grep "Server Name"
<pygi> kwwii, you are alive!
<kwwii> moin
<kwwii> actually I am about to go to sleep
<noah__> Chipzz: it's been like that since 2001
<Chipzz> heh
<Chipzz> and no-one bothered to update it? :P
<mdke> Riddell: yeah; as part of community-council I guess
<dobey> Chipzz: that's just wildcard matching in whois
<ion_> noah: Id say *much* longer, but perhaps im wrong.
<alex-weej> any HAL experts wanna help me figure out why volume.ignore = TRUE is being set on all of my external drives?
<noah__> ion_: you're probably right.
<noah__> Chipzz: it's not microsoft's fault.
<noah__> Chipzz: other people are putting up NS records for their domains which contain microsoft.com
<Riddell> mdke: kiko says he's getting that stopped
<Chipzz> even then, there's such a thing as reverse dns, which is authorative...
<Chipzz> why isn't that just?
<Chipzz> err
<Chipzz> *used
<dobey> Chipzz: it is. none of those are a dns record for microsoft.com
<dobey> whois does wildcard matching of hostnames
<smallfoot-> make GRUB or the bootloader setup/install or whatever of Ubuntu more fail-safe
<smallfoot-> ubuntu said "error" when it insatlled grub, so i had to install Windows XP and use that instead of Ubuntu :(
<bryce> geser: it is a holiday for keescook in the U.S.; I believe he is preparing for a barbeque
<Chipzz> bryce: I have a question; there seem to be a lot of x libraries depending on x11-common; yet, I can not see one single reason for them to do so
<Chipzz> could you explain why?
<Chipzz> (you can use these libs perfectly without an X-server installed, like X over ssh and such, in which case you don't need x11-common)
<geser> bryce: ah, thanks for the info
<bryce> Chipzz: I'm not totally sure, as that precedes my time, however I would assume it to be legacy from the monolithic-X days
<bryce> Chipzz: probably not something I'd feel comfortable messing around with this late in the Gutsy cycle, but if it causes any issues, it might be good to look into for Hungry
<Chipzz> x11-common contains a) dexconf stuff, b) some x-session stuff (which btw is also in the xinit package), and rgb.txt
<bryce> possibly it's just some meta-dependency
<Chipzz> a and b are not necessary for remote X use cases only
<Chipzz> yeah
<Chipzz> well anyway, just pointing this out
<Chipzz> Hobbsee was wondering what pulled in x11-common the other day too
<Chipzz> bryce: what's more of annoyance is the double files in /etc/X11/Xsession.d
<bryce> I'd like to gain stronger packaging-fu before I start reorganizing the packaging dependencies, but I definitely agree they need to be thought out a bit more carefully
<Chipzz> uhu
<mekius> hey, making a custom live cd and it is about 1GB, when i try to use ubiquity to install after booting the live cd, it gets to 66% and gives an error that it can't copy a file, i am using gutsy as a base, is this known?
<mekius> or may i have messed something up?
<mekius> i am using an iso in qemu with a virtual disk image
<mekius> so errors in media don't really apply
<mekius> nevermind
<mdke> Riddell: cool; it's not particularly annoying but it seems natural that the uploader should be the one to get build messages
<holycow> hi guys
<holycow> any people here from the upgrade testing team?
<holycow> or do they have their own chan?
<holycow> well even if there aren't any
<holycow> congrats to all the devs
<holycow> the gutsy dist-upgrade so far looks flawless even at this early stage
<holycow> you guys really ratcheted up the quality there
<holycow> its very impressive considering such tight deltas off of debian unstable
#ubuntu-devel 2007-09-04
<Utnubu> hi all
<calc> i need updated hsqldb 1.8.0.8-1 but it doesn't seem to be in ubuntu and isn't in the merge o matic either?
<calc> anyone know how i get it in that case?
<Utnubu> Is it known that i810 video playback with compiz works fine but in contrast to the intel driver changelog video playback with compiz doesn't work at all or at least not on all platforms like i915
<ajmitch> what do you mean by "isn't in ubuntu"?
<mjg59> Yes
<ajmitch> given that the source package seems to be there
<calc> ajmitch: hmm maybe it is
<ajmitch> it's probably a small change, so a manual merge wouldn't take long
<calc> ajmitch: i don't see the source there -> http://archive.ubuntu.com/ubuntu/pool/main/h/hsqldb/
<ajmitch> strange, since I'm fetching it now with apt-get
<calc> ajmitch: 1.8.0.8-1 ?
<calc> maybe its so new it isn't fully mirrored yet (dunno?)
<ajmitch> calc: no, there's no way that 1.8.0.8-1 could get in the archive without a sync or merge
<ajmitch> MoM has its own cache of packages
<calc> ajmitch: hmm grab-merge didn't give me anything
<calc> and the dir seems empty
<calc> + wget -q http://merges.ubuntu.com/h/hsqldb/REPORT
<ajmitch> probably because MoM hasn't updated, or isn't updating
<ajmitch>  dget -x http://ftp.debian.org/debian/pool/main/h/hsqldb/hsqldb_1.8.0.8-1.dsc
<calc> so you were fetching it via apt-get how?
* calc is confused
<ajmitch> deb-src lines for gutsy & sid?
<calc> ajmitch: ah ok
<ajmitch> sole ubuntu change seems to be to debian/{control,rules}
* ajmitch fetched the previous debian version from snapshot.d.n to compare against
<calc> ajmitch: ah i forgot about snapshot.d.n :)
<ajmitch> it comes in useful
<calc> yep it is
<calc> i used it quite a bit with kde
<Utnubu> Is it known that ctrl + alt + L (locking) doesn't work with enabled compiz in Gutsy?
<Utnubu> Btw. is there a reastion why compiz settings isn't installed by default?
<RAOF> Utnubu: Because it's evil, user-unfriendly crack.
<RAOF> Utnubu: Also, ctrl+alt+L works for me.  Are you perhaps referring to bug #122549
<ubotu> Launchpad bug 122549 in compiz "[gutsy]  compiz fusion breaking gnome-screensaver behaviour" [High,Confirmed]  https://launchpad.net/bugs/122549
<Utnubu> RAOF: no, it is a different problem.
<Utnubu> Screensaver works fine here.
<RAOF> Utnubu: You can't alt+tab past the lock? :)
<Utnubu> I think compiz uses the short cut ctrl + alt + L
<RAOF> Maybe.  What does it do when you hit them?
<Utnubu> Nothing I can realize :)
<Utnubu> But it is great that two big compiz bugs have been fixed. (the xv and vnc issue)
<Utnubu> Xv only for i810 driver for my card but at least it works :)
<Utnubu> And it would be great if this bug https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/136380 could be fixed. I have uploaded a patch which fixes the problem.
<ubotu> Launchpad bug 136380 in acpi-support "[Gutsy]  sonybrightness.sh doesn't use the correct value range" [Undecided,New] 
<Tm_T> hi kids
<luisbg> I got accepted as an ubuntero today, who do I have to talk to fo my mail adress?
<nixternal> ubuntero or ubuntu member?
<luisbg> ubuntu member
<luisbg> what's the difference
<ajmitch> ubuntero is just signing the CoC
<nixternal> ubuntero just means you signed the code of conduct, ubuntu member means you were approved as a contributor to ubuntu by the community council
<luisbg> ahhhh I signed the CoC like a year ago
<ajmitch> as nixternal said, when you're an ubuntu member you can be special like him :)
<luisbg> but since today I'm an ubuntu member
<nixternal> cool, welcome then!
<luisbg> thanks
<luisbg> nixternal, you must be too
<ajmitch> congrats
<nixternal> luisbg: the admins will forward your @ubuntu.com email address to the email address you have listed in your launchpad account...that can take up to 2 weeks to complete
<nixternal> it could take less though...it was only a few days for me a couple of years ago
<luisbg> nixternal, which admins?
<nixternal> who ever controls that stuff for Ubuntu
<luisbg> LOL
<luisbg> I see
<nixternal> canonical employees
<nixternal> hehe
* luisbg know understands the definition of administrator
<luisbg> ;)
<dobey> an ubuntu bofh will do it :P
<luisbg> :S
<shaya> anyone seeing issues w/ firefox and Xgl (seems gutsy is now launching it automatically)
<stdin> shaya: I noticed that, so I just removed Xgl (I don't really need it)
<RAOF> shaya: For what it's worth, I don't see any bad firefox/Xgl interaction.
<stdin> I noticed FF redrawing slow, well all apps actually
<RAOF> Hm.  fglrx, without compiz?
<dobey> afaik, xgl is in universe, and not part of the default install...
<RAOF> dobey: But the package *has* been changed so that installing it sets it up to be used by default.
<dobey> ok
<stdin> the strange (I think) thing I noticed too, is that X aswel as Xgl were running
<dobey> yes
<RAOF> On what I thought were the reasonable grounds that someone who installs xserver-xgl wants to actually use Xgl :)
<dobey> Xgl is not a separate individual X server
<RAOF> Well, it is.
<dobey> it requires Xorg to be running as well
<dobey> it's not a mutually exclusive server
<RAOF> But the one we ship needs an underlying Xorg server to set up an OpenGL context for it.
<dobey> right
<fabbione> morning guys
<mdke> morning all
<soren> mdke: 'morning.
<dholbach> good morning
<mdke> hiya dholbach
<dholbach> hey mdke
<LaserJock> hi dholbach
<dholbach> hey LaserJock
<TheMuso> 11/c
<TheMuso> uh
<TheMuso> damn orca
<Mithrandir> asac: why does firefox claim a restart is required when I just booted the machine?
<hunger> ubuntu-desktop is not installable here. diveintopython is not found. Is that a known issue?
<Hobbsee> hunger: if it's listed on http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html
<Hobbsee> hunger: those are the packages in main which are not installable.
<Hobbsee> hunger: however, diveintopython seems to exist there, so...
<cjwatson> diveintopython | 5.4-2ubuntu2 |         gutsy | source, all
<cjwatson> sounds like a local networking or local mirror issue
<Hobbsee> wow, a nice short list for !sparc, close to a tribe...
<hunger> cjwatson: My mirror is archive.ubuntu.com
<hunger> cjwatson: aptitude gives this error: E: I wasn't able to locate file for the diveintopython package. This might mean you need to manually fix this package.
<seb128> hunger: apt-cache policy | grep main?
<Hobbsee> mirror seems fine, so the original archive must be fine
<hunger> seb128: The usual urls on archive.ubuntu.com (gutsy-security, -backports, -updates, gutsy itself), all on piority 500.
<seb128> hunger: apt-cache policy diveintopython ?
<hunger> Did a new update... seems that it works now.
<hunger> Maybe I grabed something partly updated before or something:-(
<cjwatson> iwj: bug 137179 might be your call ...?
<ubotu> Launchpad bug 137179 in glibc "2.6.1-1ubuntu3 makes apps crash with Bus error" [Undecided,New]  https://launchpad.net/bugs/137179
<asac> Mithrandir: i doubt that its firefox claiming that ... i just copy the restart notification during postinst
<Mithrandir> asac: well, the notification shouldn't be there if you reboot.
<asac> Mithrandir: but i never really cared of who is doing what for this notification
<asac> Mithrandir: yes agree ... but is it a firefox bug?
<Mithrandir> asac: I'd say so, yes.
<asac> Mithrandir: it has DontShowAfterReboot: True ... so isn't it a problem of update-notifier?
<asac> Mithrandir: otherwise i don't really see what firefox can do
<asac> Mithrandir: (or maybe we are talking about different things)
<Mithrandir> hm, ok, then it's an update-notifier bug
<asac> mvo_: ^^^
<asac> mvo_: what do you think?
<stgraber> morning
<asac> hey stgraber
<mvo_> Mithrandir: could you please kill it and run it again, if the problem presists, please run it with "update-notifier --debug-hooks" and send me the output (or put it to a pastebin)
<stgraber> asac: tried NM+ipw3945 at school, switching between public networks, reconnecting, ... works just fine
<asac> stgraber: rock
<asac> stgraber: if noone pops up who is willing to test this (which is a bit of a shame), then I will ask the kernel team to review and roll the module update
<Mithrandir> mvo_: given I clicked on it, to see what it wanted from me, I guess it won't show again
<mvo_> Mithrandir: hrm, good point
<Hobbsee> good morning sabdfl, asac, Mithrandir, mvo_, etc
<mvo_> hey Hobbsee
<asac> hey Hobbsee ....
<stgraber> asac: one of my teacher also has a laptop with a ipw3945 card, I may try the fixed driver on his laptop this afternoon
<Hobbsee> stgraber: does it seem to be stable/
<stgraber> Hobbsee: yup
<Hobbsee> stgraber: or does NM drop the connection?
<Hobbsee> stgraber: nice!
<stgraber> Hobbsee: I'm currently connected on a network with a very weak signal, so sometimes it looses the signal but reconnect just fine afterwards (as expected)
<asac> stgraber: that would be nice
<asac> (e.g. test on a second laptop)
<Hobbsee> stgraber: ok, will try
<asac> Hobbsee: great!
<Mithrandir> morning Sarah
<Hobbsee> asac: do you happen to have the link to the newer driver again?  my other client dropped off the network last night, adn i dont have the scrollback
* Hobbsee hugs Mithrandir
<asac> Hobbsee: still  have the instructions?
<Hobbsee> asac: nope :(
<asac> Hobbsee: sure
<asac> Hobbsee: https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac
<asac> Hobbsee: install kernel headers at al then: make IEEE80211_IGNORE_DUPLICATE=y SHELL=/bin/bash
<norsetto> anyone on kubuntu/i386, that can check bug 137222 and report if you have the same problem?
<ubotu> Launchpad bug 137222 in adept "Adept description field is wrong" [Undecided,Confirmed]  https://launchpad.net/bugs/137222
<Hobbsee> norsetto: checking...patience, patience...
<Hobbsee> norsetto: youd' do better in #Kubuntu-devel, FYI
<norsetto> Hobbsee: sorry, thanks, wasn't sure you were alive :-)
<Hobbsee> :)
* Hobbsee plays dead
* norsetto is tempted to tickle her belly .....
<asac> mvo_: how does update-notifier determine if the notification was put there before reboot? does it just rm all hints marked as "not display after reboot" during boot?
<mvo_> asac: it compare uptime and mtime of the notification
<Hobbsee> norsetto: no.
<Hobbsee> norsetto: shows the proper description here
<norsetto> Hobbsee: ok, thanks, I see the same on mine, which is x86_64 too
<norsetto> Hobbsee: I mean, same problem, not same as you
<stgraber> Hobbsee: are you running amd64 or i386 ? (I have amd64 driver and package here)
<Hobbsee> stgraber: i386
<stgraber> ok, so maybe asac has the i386 ones
<asac> i am on amd
<Hobbsee> stgraber: bah.  this machine builds reasonably fast, anyway
<Hobbsee> asac: then just copy the .ko, or do something with the .mod.o too?
<asac> Hobbsee: please ask stgraber for the exact procedure
<asac> stgraber: can you guide Hobbsee ?
* Hobbsee did the make
* Hobbsee doesnt know what a .mod.o is
<asac> i think: its just replace the .ko module ... then reload the module
<Hobbsee> ah cool...  ok, will try
<asac> and confirm that modinfo does show the right version afterwards
<asac> it should be 1.2.1something ... not 1.2.2something
<Hobbsee> gotcha
<asac> just the kernel module should improve your situation ... the final cure you only get with a new network-manager:
<asac> https://code.launchpad.net/~asac/network-manager/ubuntu.0.6.x.dev.opennet
<Hobbsee> hmmm.
<stgraber> Hobbsee: replace the ipw3945.ko in ubuntu/wireless/ipw3945/, then depmod -a, then ipw3945d-2.6.22-10-generic --kill, then modprobe ipw3945
<asac> what happened?
<Hobbsee> stgraber: ahhh.  forgot to depmod -a
<Hobbsee> no wonder it didnt work!
<stgraber> Hobbsee: error message ?
<asac> stgraber: i think she said that it didn't work because of not running depmod -a
<stgraber> a ok
<asac> hmm Hobbsee is offline :) ... that can't be good news ;)
* LongPointyStick waves
<LongPointyStick> asac: no dice, yet
<asac> hi LongPointyStick
<asac> what topic?
<Hobbsee|Remote> asac: is that better?
<asac> yeah
<Hobbsee|Remote> still no dice.
<Hobbsee|Remote> as in, i never seem to get the new version showing up
<asac> so do you see the right module version
<Hobbsee|Remote> nope
<Hobbsee|Remote> i still get 1.2.1*
<asac> thats correct
<asac> the gutsy is 1.2.2
<Hobbsee|Remote> oh, i thought i was suppsoed to get 1.2.2
<Hobbsee|Remote> version:        1.2.1d
<asac> yes that should be ok
<Hobbsee|Remote> ahhh.
<Hobbsee|Remote> well, then.  we have dice.
<asac> :)
<Hobbsee|Remote> so it did work right, all along.
<asac> ok it should basically connect now
<davmor2> bryce: I have updated bug 134284 with my lspci -nnvv is there any other info you need?
<ubotu> Launchpad bug 134284 in xorg "The X intel driver is not functioning correctly" [Undecided,New]  https://launchpad.net/bugs/134284
<asac> Hobbsee|Remote: but switching networks might still break at some point ... would be cool if you could test the new nm as well
<asac> https://code.launchpad.net/~asac/network-manager/ubuntu.0.6.x.dev.opennet
<glatzor> davmor2: bryce lives in the USA
<asac> Hobbsee|Remote: its a full-source bzr branch ... so you don't need an orig.tar.gz to build
<davmor2> damn
<Hobbsee|Remote> asac: did you want to know if it works on an open network here too?
<Hobbsee|Remote> before testing the new NM?
<asac> Hobbsee|Remote: yes please do ...
<Hobbsee|Remote> ok.  good thing dad's not home.
<asac> ;)
<asac> hurry
<Hobbsee|Remote> he's out of the state, he wont be home for a few more hours.  i think
* Hobbsee|Remote tries to remember how to get into her router...
<Hobbsee|Remote> yay, i win.
<Mithrandir> with a big hammer!
<asac> i would suggest a screwdriver
<asac> its far less destructive ;)
<seb128> Riddell: I want to update poppler to 0.6, is that ok with you?
<Riddell> seb128: yes, please do
<seb128> thanks
<kwwii> seb128: did you see that I commited the emblems?
<Hobbsee|Remote> Mithrandir: ah.  right.
<Hobbsee|Remote> asac: NM still likes falling over, at 14%
<Hobbsee|Remote> ooh, hang on.
<seb128> kwwii: yes, will you update the package now? ;)
<asac> Hobbsee|Remote: falling over? where does it fall to?
<asac> btw, 14% network-strength is not really strong
<iwj> cjwatson: It might be.
<StevenK> Mithrandir: Can I beg you to release virtualbox from binary NEW? It's built on both amd64 and i386, which is what it's meant to.
<seb128> StevenK: I can do it
<iwj> Hmm.
<StevenK> seb128: Thanks
<Mithrandir> seb128: care to do ume-config-common too?
<Mithrandir> (I've uploaded it, so I'd rather not NEW it)
<asac> stgraber: can you reproduce the nm crash you mentioned yesterday?
<Hobbsee|Remote> asac: ok, seems like NM likes playing funny buggers.  it's all working now.
<asac> Hobbsee|Remote: ok cool, please upgrade nm and it should just rock
<seb128> Mithrandir: I'll look at this one as well
<asac> Hobbsee|Remote: thanks for testing
<Hobbsee|Remote> asac: it would fall over at 14% (preparing devices, i think), go back to disconnected, then show $AP as wpa-encrypted, again
<Hobbsee|Remote> after using dhclient, etc, to connect, and killing NM a few times, it seems to work, properly, with NM again
<asac> well ... if you have log i can verify if its the bug that nm fixes
<asac> otherwise just try the new nm
* Hobbsee|Remote borrows Mithrandir's hammer to use on nm
<Hobbsee|Remote> asac: dmesg, or what?
<asac> syslog
<seb128> StevenK: virtualbox binary newed
<asac> Hobbsee|Remote: but maybe just upgrade nm ... the bug it fixes sounds similar
<Hobbsee|Remote> asac: what in particular were you looking for in it?
<asac> Hobbsee|Remote: damn i don't know the exact string .. should be something like: cannot connect to wpa supplicant
<Mithrandir> seb128: cheers
<asac> Hobbsee|Remote: couldn't connect to the supplicant
<Hobbsee|Remote> asac: a couple of Sep  4 19:21:05 LongPointyStick NetworkManager: <WARN>  supplicant_cleanup(): couldn't disable network in supplicant_cleanup
<asac> yeah
<asac> upgrade nm and it should never fail again :)
<kwwii> seb128: if dholbach walks me through it, sure :-)
<Hobbsee|Remote> asac: are you planning to get that upgrade into gutsy?
<asac> (wow ... what a stupid claim :))
<seb128> dholbach: ^
<asac> Hobbsee|Remote: definitly
<dholbach> kwwii, seb128: through what?
<asac> Hobbsee|Remote: but i need the new kernel module first
<Hobbsee|Remote> ah right
<dholbach> updating which package?
<Hobbsee|Remote> well, the new module seems to work, which is good
<asac> Hobbsee|Remote: as the new nm drops a workaround that fixes a few wpa problems atm
<Hobbsee|Remote> dholbach: the mangler
<kwwii> dholbach: h-i-t
<seb128> dholbach: human-icon-theme
<Hobbsee|Remote> asac: ahhh.
* Hobbsee|Remote looks for the url of the nm stuff
<Hobbsee|Remote> https://code.launchpad.net/~asac/network-manager/ubuntu.0.6.x.dev.opennet
<asac> yes
<dholbach> seb128: do you think we should update it to run autogen itself and make it native packaging?
<asac> you can just build ... it has full source
* Hobbsee|Remote pulls
<seb128> dholbach: native packaging
<seb128> dholbach: what do you think?
<dholbach> seb128: plus ./autogen.sh before the build
<dholbach> so you don't have to bother roling a release of it
<seb128> dholbach: what is the easier for you
<dholbach> to make it as easy as possible for ken
<seb128> Mithrandir: ume-config-common accepted, shouldn't ume-gui-start be in /usr/share though?
<Mithrandir> seb128: it should, yes.
<Hobbsee|Remote> grrr.  not another nutter assigning things to the ubuntu-dev team, as they're the maintainer.
<dholbach> Hobbsee|Remote: relax... it's not really easy for people to understand all the concepts at once - although I'm not quite sure how we could fix that problem easily
<Hobbsee|Remote> i wonder if it's in the documentation, to assign it to it's maintainer.
<dholbach> no, not really, but that mistake is easy to make
<dholbach> we had it a couple of times before
<broonie> Perhaps it would help to rename the "Nobody" assignee to "Needs triage" or something that read less like the bug was getting ignored?
<Hobbsee|Remote> dholbach: might be a thought to black-hole that address.
<asac> dholbach: i think you cannot do much except fixing the assignment and stating the reason ... then hope that the triager reads the reply
* Hobbsee|Remote just sent him an email saying "please do not do that again, this is why"
<dholbach> asac: that's what we currently do
<Hobbsee|Remote> it seems to be something that's come from the kubuntu team - they do it all the time
<Hobbsee|Remote> fortunately, that address is blackholed.
* Hobbsee|Remote inwardly cries about the amount of bugmail in her email
* Fujitsu hastyil assigns Hobbsee to a few more bugs.
<Hobbsee|Remote> broonie: for a lot of applications, we dont assign bugs anyway
<Hobbsee|Remote> bad Fujitsu!  no cookie!
* Hobbsee|Remote --> dinner, while nm builds
<Hobbsee|Remote> broonie: besides, assignment should only really be used for "i will fix this, i'm assigning this to person x, because they say they will fix it, or i'm assigning this to person y, because i'm their boss, and i say they have to fix this"
<Hobbsee|Remote> the others dnot *have* to fix bugs, and have other ways of subscribing to them
* Hobbsee|Remote --> really dinner.
<dholbach> http://daniel.holba.ch/sponsoring/ works again
<dholbach> seb128: done
<seb128> dholbach: thanks
<dholbach> kwwii: I just change human-icon-theme so that you can simply edit the changelog (using dch), then run debuild -S -sa to create a source package
<dholbach> kwwii: or run debuild to build a package
<kwwii> dholbach: cool, after I create the source package what should I do with it?
<asac> stgraber: another thing i would be curious about would be to test if nm.asac + ipw3945.asac play nice together even if you modprobe the ipw module with auto associate on
<dholbach> kwwii: upload it somewhere and either tell somebody to grab and upload it or file a bug and subscribe ubuntu-main-sponsors to it, so it's in the queue for review and upload
<kwwii> dholbach: cool, thanks :-)
<dholbach> rock and roll :)
<asac> stgraber: (even if you are associated before clicking on that network, nm should retrieve an "associated" event and run dhclient)
<dholbach> kwwii: next time we need changes in tangerine-icon-theme or tango-icon-theme-common I'll transition them to the same pattern
<kwwii> killer, that should save others a bit of work in the long run
<dholbach> yeah :-)
<seb128> Riddell: the dummy knetworkmanager should be arch all, not any
<Riddell> mm, did I forget that?
<Riddell> I remember thinking "that needs to be changed"
<Riddell> seb128: uploading fix.  are you doing New queue?
<seb128> Riddell: there is a binary for each arch in the new queue
<seb128> Riddell: yes
<seb128> I'll accept the previous ones since it doesn't make really sense to reject binaries
<cjwatson> argh
* cjwatson hits debian-policy@ with a spoon
<asac> Hobbsee|Remote: stgraber: i upgraded my ipw3945 branch to 1.2.2 and added .ubuntu1 suffix to version info ... would be great if you could test that it doesn't introduce new regressions.
<asac> Hobbsee|Remote: stgraber: if you give me an ack on this, I'll ask kernel-team to update lum
* Hobbsee|Remote comes back from dinner
<asac> Hobbsee|Remote: welcome back ;)
<Hobbsee|Remote> asac: thankyou :)
<Hobbsee|Remote> new mangler works, at least on wpa
<asac> mangler?
<Hobbsee|Remote> asac: you want the new ipw with the new mangler presumably?
<Hobbsee|Remote> nm
<Hobbsee|Remote> aka, the mangler.
<asac> Hobbsee|Remote: ah :)
<Hobbsee|Remote> havent you heard of network mangler?
<asac> Hobbsee|Remote: yeah ... please try first the 1.2.1 module with new nm
<asac> if that works well just upgrade to new driver version
<Hobbsee|Remote> that's working, at least on wpa
<Hobbsee|Remote> did you want me to test it on open, as well?
<asac> Hobbsee|Remote: try to stress it
<asac> Hobbsee|Remote: yes please
<asac> Hobbsee|Remote: wpa worked for you before?
<davmor2> I'm trying to track down a fault with seahorse in gutsy in preferences keyservers can you actually hilight automatically retrieve keys? everytime I go back to it it's disabled again.
<asac> Hobbsee|Remote: i only know that open didn't work for anyone ... wpa worked for some, but not for others
* ogra wonders how cjwatson copes with all the filedscriptors in d-i without having his head explode
<asac> ogra: you need a well trained head ... nothing if you haven't been to university :-P
<ogra> ah, thats it then :)
<asac> hehe
<Hobbsee|Remote> asac: yes.  open's working, after a little persuading.  seems slightly patchy, perhaps.
<asac> Hobbsee|Remote: what do you mean? i know that nm has problem to recognize if you change the encryption on the same access point
<asac> Hobbsee|Remote: is that what you are seeing?
<Hobbsee|Remote> asac: yeah.  it seems to still see it as encrypted until you restart nm a couple of times
<Hobbsee|Remote> also seeing the bug about it finding no wifi networks until you run iwlist eth3 scan
* ogra cires over /usr/share/debconf/confmodule: line 42: 3: Bad file descriptor 
<cjwatson> ogra: frequent prayer
<ogra> heh
<cjwatson> draw it out on paper if you get stuck
<ogra> good idea !
<asac_> Hobbsee|Remote: daily reconnect
<cjwatson> it helps that I know the usual elements so I don't have to think about all the individual pieces
<asac_> 3:35 < Hobbsee|Remote> also seeing the bug about it finding no wifi networks until you run iwlist eth3 scan
<asac_> 13:36 < asac> Hobbsee|Remote: you areprobably associated
<Hobbsee|Remote> asac_: associated how, sorry?
<cjwatson> but yes, debconf-apt-progress in particular required me to stare at the screen for a few days
<asac_> Hobbsee|Remote: when your interface is associated, scanning is not done frequently anymore
<Hobbsee|Remote> it's showing me as not connected to any network, at that point in time
<asac_> Hobbsee|Remote: yes ... what does iwconfig show?
<Mithrandir> cjwatson: this is why we should do debconf-over-unix-socket, IMO.
<ogra> cjwatson, thats waht i di atm :)
<ogra> *do
<Hobbsee|Remote> asac_: what, now?
<cjwatson> Mithrandir: I won't argue that ...
<asac_> no ... when you see don't see the networks (if you can reproduce)
<Hobbsee|Remote> asac_: iwlist shows all the networks, which then makes them show up (eventually) in nm
<Hobbsee|Remote> yes, there's a bug open about it
<asac_> Hobbsee|Remote: iwlist as user or as root/sudo ?
<Hobbsee|Remote> asac_: root
<Hobbsee|Remote> well, sudo
<asac_> Hobbsee|Remote: ok thats normal then ... the point is as soon as iwconfig shows the interface as associated to some ap, the driver won't scan on its own that frequently anymore
<asac_> Hobbsee|Remote: which is why i asked you to verify if iwconfig shows your interfaces associated when you don't see networks in nm
<Hobbsee> asac_: ah right
<Hobbsee|Remote> hmmm.  the LED flashes from time to time, but it still seems to be connected.
<asac_> Hobbsee|Remote: what does LED flashing mean? associating/roaming?
<asac_> Hobbsee|Remote: ok ... are you using 1.2.2 module already?
<Hobbsee> asac_: oh, hmmm, apparently it's just the speed it's doing.  it usually stays solid on.
<Hobbsee> no, not yet
<Hobbsee> asac_: bzr up reports that we're at revision 2, and that's the latest
<asac_> Hobbsee: strange ... bzr pull ?
<asac_> https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac
<asac_> its rev 4
<Hobbsee> ah, there we go
<asac> Hobbsee: one more question about wpa: did wpa with NM work for you before? or is there improvement for you as well?
<Hobbsee> asac: wpa has always worked here
<asac> ok
<asac> Hobbsee: with NM ?
<Hobbsee> yes
<asac> ok ... then you are one of the lucky-girls :)
<Treenaks> WPA works, WPA2 doesn't
<Treenaks> (for me.. ipw2200)
<broonie> Hobbsee: My point was that I can see how someone just looking at the UI could believe that they needed to pick an assignee; it'd be nice if the UI provided more indication that unassigned bugs aren't being ignored.
<asac> Treenaks: what setup? NM ... or also when using ifup/down ?
<Treenaks> asac: nm, I haven't tried with ifup/down because nm tends to get in the way
<Treenaks> asac: ifdown <n-m brings it up again>
<Treenaks> stuff like that
<asac> ok .. i think i would need a driver debug log
<Hobbsee|Remote> asac: oh, wpa2 btw
<Treenaks> asac: I can get the daemon.log n-m generates (tonight)
* ogra sighs ...
<asac> Treenaks: thats not enough ... i need driver debug messages as well
<Hobbsee|Remote> broonie: suggestion:  file a bug on launchpad (malone) about that.
<Treenaks> asac: I'll try to get as much as possible when I get home, is there already a bug, or should i open a new one?
<asac> Hobbsee|Remote: what do you mean?
<Hobbsee|Remote> asac: right, 1.2.2ubuntu1, new mangler is working (eventually)
<asac> Hobbsee|Remote: ok cool
<asac> Hobbsee|Remote: what about wpa2?
<Hobbsee|Remote> asac: that my wpa has always worked.  (where wpa == wpa2)
<asac> ah ok
<ogra> cjwatson, when you told me to look at in-target for my prob with ltsp-build-client you meant using passthrough and setting DEBCONF_READFD, DEBCONF_WRITEFD ?
* Hobbsee|Remote switches to wpa, to see what happens
<cjwatson> ogra: yeah
<Hobbsee|Remote> asac: +1.  good job.  works on wpa-psk (new ipw3945, new nm)
<ogra> cjwatson, it says it cant initialize passthrough ...
<ogra> and indeed falls back to noninteractive which exits with the same error
<cjwatson> ogra: it will do if you're running it without a debconf frontend
<asac> Hobbsee|Remote: thanks a lot for testing ... i wait for stgraber to confirm that new driver is good then lets roll this fix
<ogra> well, the udeb sits in a debconf frontend already ...
<Hobbsee|Remote> asac: excellent :)
<cjwatson> it might be worth taking a bit of time to step back and read and understand how the various frontends work
<cjwatson> ok, in that case you did something wrong :-)
<ogra> yeah, thats where i'm trying to wrap my head around atm
<davmor2> asac: think stgraber is back at school now so he might be a while
<asac> Hobbsee|Remote: there is only one bug i would like someone to test ... there are claioms that if you boot with wireless off, that turning on wireless later will not load the driver, bring up the interface
<asac> Hobbsee|Remote: have you ever seen this?
<Hobbsee> hmmm...i've seen something similar, i think.  will test the next time i boot
<cjwatson> ogra: if readfd or writefd is getting lost somewhere then that would happen
<ogra> right
<asac> davmor2: thanks. But since nm with ipw3945 was broken such a long time I can wait for a few more hours :)
<asac> Hobbsee|Remote: great.
* Hobbsee is Hobbsee|Here nwo :P
<ogra> debconf: kann Frontend nicht initialisieren: Passthrough
<ogra>  debconf: (Failed to open fd 3: Bad file descriptor at (eval 20) line 3)
<ogra> fails with the same error as noninteractive
<cjwatson> ogra: you also need to unset the things in-target unsets
<cjwatson> ogra: or rather that chroot-setup.sh unsets
<ogra> ah, ok
* ogra looks
<ogra> lol, ok, thats a lot stuff i'm missing :)
* ogra hugs cjwatson 
<ogra> yay
<ogra> still broken (need to redirect stdout somehow to the fifo) but it moves on :)
<jdong> schplee! "Inconsistency detected by ld.so...."
* jdong wonders if he can search launchpad with links :)
<doko> cjwatson: can we close bug 61861, or would an edgy task more appropriate?
<ubotu> Launchpad bug 61861 in ruby1.8 "ruby1.8: fails to build on ppc under 2.6.15 kernel" [Medium,Confirmed]  https://launchpad.net/bugs/61861
<cjwatson> doko: I'd suggest closing the ruby1.8 task (since it built fine on edgy in the end) and leaving the linux-source-2.6.15 task open in case it becomes important later
<cjwatson> doko: FYI: diff -u <(wget -q -O- http://people.ubuntu.com/~ubuntu-archive/component-mismatches{-mobile,}.txt)
<cjwatson> doko: it's not perfect (and, for reasons involving part of the code being in Launchpad and difficult to modify, it's hard to do better) but it clears away a lot of the mobile-specific stuff from the main component-mismatches list
<cjwatson> so it should help matters for the time being
<doko> type-handling into main???
<cjwatson> clearly an error
<cjwatson> germinate gets confused sometimes because type-handling Provides: linux
<cjwatson> we routinely ignore that :-)
<cjwatson> I've fixed it in the past - not sure why it's showing up here
<doko> ok, this list helps
<cjwatson> oh, I see, it should be linux-image on gobuntu not linux
<cjwatson> I'll fix the seeds
<stgraber> asac: Sorry was afk, so 1) No, 2) I'll try tonight, 3) I'll build both now
<stgraber> s/both//
<stgraber> asac: looks like I have enough wifi network around so I can try everything now, will be back in a minute
<stgraber> asac: with associate=0 : Wired -> Public1 -> Wired -> Public1 -> Public2 -> Public1 -> Wired = OK
<stgraber> asac: with associate=1 : Wired -> Public1 -> Wired = Failed
<stgraber> asac: it failed when switching back to wired
<stgraber> Sep  4 15:43:50 laptop NetworkManager: <WARN>  nm_utils_supplicant_request_with_check(): nm_device_802_11_wireless_scan: supplicant error for 'SCAN'.  Response: '^F'
<stgraber> Sep  4 15:43:50 laptop NetworkManager: <WARN>  nm_device_802_11_wireless_scan(): could not trigger wireless scan on device eth1: Transport endpoint is not connected
<stgraber> also had : Sep  4 15:43:30 laptop NetworkManager: <WARN>  nm_device_802_11_wireless_scan(): could not trigger wireless scan on device eth1: Connection refused
<asac> oh another bogus response path
<asac> in wpa_ctrl
<stgraber> anyway, associate is default to 0, people using it with 1 aren't NM users imo
<asac> let me see
<asac> sure
<stgraber> I don't have WPA around, but if Public1 -> Public2 -> Public1 works and the WPA code wasn't changed it should works just fine
<asac> stgraber: can you see what wpa command is send before you get that Response: ... ?
<asac> ah SCAN :)
<asac> sorry
<asac> stgraber: you sure you have new nm?
<stgraber> new NM = .dev.opennet ?
<asac> yes
<cjwatson> seb128: re mail, want me to take https://bugs.launchpad.net/ubuntu/+source/libgtk2-perl/+bug/127985?
<stgraber> it's rev57 here and no revision to pull
<ubotu> Launchpad bug 127985 in libgtk2-perl "gutsy/amd64: ftbfs / autopkgtest failure" [High,Confirmed] 
<cjwatson> seb128: or are you already on it?
<asac> stgraber: can you get a full driver log for associate:1 ?
<bddebian> Heya
<stgraber> asac: sure
<stgraber> asac: the warnings only appear when I try to switch to wired the second time
<stgraber> asac: I'm uploading the full log
<asac> thanks
<stgraber> asac: http://www.stgraber.org/download/nm-debug-associate
<asac> stgraber: i can't find that warning
<stgraber> asac: so 2 last NM warnings are caused by me clicking wired a second time
<stgraber> asac: cat debug-nm-associate | grep -v ipw3945:
<asac> stgraber: i only see a warn: " supplicant_cleanup(): supplicant_cleanup - couldn't set AP_SCAN 0 "
<asac> stgraber: (and the line above that)
<stgraber> when I select wired for the first time I have "Sep  4 16:02:21 laptop NetworkManager: <info>  nm_device_set_active_link start
<stgraber> " being written every 2s
<stgraber> but not switching back to wired
* ogra hits debconf over the head with something heavy
<stgraber> :)
<asac> stgraber: yes i see that ... but i don't see the warn you pasted above
<asac> stgraber: any idea about when you hit wired for the second time?
<stgraber> 16:02:23
<asac> stgraber: and first time works?
<stgraber> first being 16:01:52
<stgraber> no, first time trigger the nm_device_set_active_link_start every 2s
<asac> ah
<stgraber> second trigger the WARN
<asac> stgraber: well but thats not the WARN i was particular interested in :)
<asac> stgraber: nm_device_802_11_wireless_scan: supplicant error for 'SCAN'.  Response: '^F'
<asac> thats the one i need ;)
<stgraber> asac: do you have 16:02:28 in the log ?
<asac> no
<asac> 16:02:24 is the last i see
<stgraber> ok
<asac> stgraber: i see that you try to active your eth0 on 16:01:52
<stgraber> asac: http://www.stgraber.org/download/nm-debug-associate1
<asac> stgraber: what happens after 16:02:35 ?
<asac> stgraber: for me it looks a bit like it wants to boot up eth0 at that point? does that succeed?
<stgraber> asac: no
<asac> what happens?
<stgraber> asac: http://www.stgraber.org/download/nm-debug-end
<stgraber> asac: I just can't remember when I killed NM
<asac> stgraber: ok at 16:02:41 it succeeds
<asac> stgraber: did you restart nm?
<stgraber> asac: I think so yes
<seb128> cjwatson: I'm not on it, feel free to do it
<dobey> hey seb128
<seb128> hi dobey
<bddebian> Hi seb128 :-)
<seb128> hey bddebian
<dobey> how's it going?
<kblin> hi folks
<kblin> who'd be the person to talk to to stop ubuntu from mapping `hostname` to 127.0.1.1 ?
<seb128> dobey: good, thanks ;) What about you?
<seb128> Hi kblin
<dobey> doing ok
<dobey> hoping to get a job soon ;)
<seb128> :)
<seb128> kblin: try mentioning it on this chan (what you are doing) and if you get no reply maybe mail ubuntu-devel@lists.ubuntu.com with some details on what is your issue and what you suggest doing this change
<kblin> ok, fair enough
<dobey> red tape takes a while to get around though :P
<kblin> doing this kind of stunt will break applications that depend on the hostname resolving to the real IP address of the host
<kblin> it seems to be a pretty popular thing to do in distributions recently, and I'd like to explain why it's a bad idea :)
<Mithrandir> kblin: "the real IP of the host" doesn't really make any sense.
<Mithrandir> hosts don't have ip addresses, interfaces does.
<kblin> I'm a Wine developer working on Wine networking, and we've seen lots of bug reports recently that are due to windows applications assume that gethostbyname( gethostname() ) will give them the network interface IP address so they can bind to that
<dobey> kblin: what happens when no network interface outside of lo is up?
<kblin> Mithrandir: ok, sorry. but how about using the IP address of an active network interface that's not loopback if possible
<Mithrandir> kblin: that can change at any time, so it's not suitable for /etc/hosts
<kblin> this also tends to break kerberos once in a while..
<dobey> kblin: not having it there, tends to break things that expect $hostname to resolve to something
<Mithrandir> works fine on my kerberos-enabled workstation.
<kblin> Mithrandir: I haven't touched kerberos in a while.. current mit kerberos might be able to cope
<Mithrandir> I'm using heimdal, though
<kblin> oh, ok
<kblin> heimdal design is more robust for all that I'm aware :)
<Mithrandir> or rather, a mixture of them, since some apps like one, some the other libraries.
<kblin> but as I said, I'm more concerned about  this breaking for a lot of windows apps where I can't just fix the bloody app
<dobey> obviously. being a wine developer, your primary concern is wine. :)
<kblin> this is probably the most popular networking bug we currently get in our bugzilla
<Mithrandir> if you have a better way of having /etc/hosts set up that works in all cases, please tell us
<doko> ./.ext/include/i686-linux-lp
<doko> ./.ext/i686-linux-lp
<doko> \o/
* rgl waves
<kblin> well, assuming the host has a fixed IP address for a non-loopback interface, that should be useable
<kblin> that would fix it for some of the users, right?
<doko> AC_CANONICAL_TARGET
<doko> target_os=`echo $target_os | sed 's/linux-gnu$/linux/;s/linux-gnu/linux-/'`
<Mithrandir> kblin: that assumption holds for very few users.
<ogra> yeah, static interfaces got rare nowadays
<kblin> hmm
<Mithrandir> why would you do static?  I have more DHCP servers than I know what to do with.
<Mithrandir> (I have three within 1m of me here..)
<kblin> maybe I'm old fashioned
<bddebian> kblin: I'm with ya, I love static interfaces :-)
<bddebian> Of course I'm old
<ScottK> And grumpy.
<realist> Even our static/fixed IPs are actually on DHCP leases
<realist> If that makes any sense
<bddebian> ScottK: Always :)
<Mithrandir> realist: fixed DHCP is quite common.
<bddebian> realist: Yeah but that's a PITA for a home network
<kblin> I'm just trying to come up with some  way to fix that for joe user in some sane way
<realist> bddebian: depends how many hosts on your home network
<bddebian> 12
<ogra> kblin, as long as you dont break it for jane user, thats fine :)
<thom> static interfaces are such a pain
<realist> That's enough for me to want dhcp + ddns
<bddebian> ogra: :)
<bddebian> Not me, dhcp is a hassle
<kblin> My first attempt to fix this was to work around this in Wine
<realist> A blessing :-)
<kblin> but that approach wasn't accepted
<Mithrandir> I think you might be able to write an NSS module providing the necessary workaround
<kblin> hmm, true
<ogra> but the wine fix would probably be the right way
<realist> Static is a hassle, so is MAC based switch port security
<realist> Management overhead++
<realist> Goodnight all
<Mithrandir> ogra: no, the right way to fix it would be to apply a suitable tool to the author of said applications. :-P
<ogra> Mithrandir, indeed, but if many/all distros use the 127.0.1.1 notation, the fix should be in wine, not in the distros ;)
<kblin> ogra: I've tried
<kblin> but this is kind of clumsy to fix, unless you iterate over all interfaces, check if they're active and then kind of switch addresses before it actually ends up with the caller
<ogra> cant you just ignore the 127.0.1.* space ?
<kblin> some distros map the hostname to 127.0.0.2
<kblin> which tells me this should not be fixed in wine
<kblin> at least not until there's an agreement across distros to what IP address the hostname will map to
<Mithrandir> you'd want to look at the scope for the address on the interface, somehow.
<kblin> hm, thinking about this some more, I think that returning the IP address of the interface that has the default route would make sense for most people who'd do a gethostbyname( gethostname() )
<kblin> but yeah, maybe a nss module would be the best place to actually fix this
<Mithrandir> you could easily have that in an NSS module.
<kblin> what would my chances of actually getting something like that into distros?
* ogra thinks debconf is playing tricks on him ...
<ogra> kblin, you could make it part of the wine package i guess
<dobey> exactly
<kblin> but it's not wine-specific
<kblin> I won't ever get something like that into the wine tree
<dobey> then you make a new package, and make wine depend on it
<ogra> kblin, a package isnt only upstream source :)
<ogra> well, ideally it would be ... but thats rarely the case
<cjwatson> kblin: it doesn't seem clear from scrollback, but normally we resolve the hostname to 127.0.1.1, not 127.0.0.1, precisely to avoid this kind of problem
<cjwatson> kblin: there doesn't need to be agreement across distros - it just needs to not be 127.0.0.1, that's all
<kblin> cjwatson: as I said, there's a distro that maps to 127.0.0.2
<cjwatson> kblin: the reports you've been getting might be from users who installed Ubuntu a long time ago, before we made this change
<Mithrandir> cjwatson: the problem is some apps thinks that the address returned by gethostbyname(gethostname()) is a sane choice for binding to for doing public communication.
<cjwatson> kblin: sure, and that's ok
<kblin> yeah
<kblin> what Mithrandir said :)
<cjwatson> I don't understand how that wouldn't break on Windows from time to time as well
<cjwatson> dynamic networking is kind of a fact of life there too
<cjwatson> ok, sorry for the slight misunderstanding, I was reading an hour of scrollback at once and the hostname=>127.0.0.1 thing used to be a common complaint for other reasons ...
<kblin> oh, actually this tends to break on windows if you have more than one active NIC
<dobey> what if you have no active NICs?
<cjwatson> kblin: the correct range to skip would be simply 127.0.0.0/8
<cjwatson> any address there is local, per whatever RFC it is
<bddebian> 1918 I think
<ogra> or ignore the lo interface and everything related
<kblin> dobey: that's not that much of a concern, but matter of fact windows returns 127.0.0.1 in that case
<cjwatson> so you don't need to worry about 127.0.0.1 vs. 127.0.0.2 vs. 127.0.1.1
<seb128> cjwatson: there is bug #94048 which is quite long on the using 127.0.1.1 creating issue for users
<ubotu> Launchpad bug 94048 in hostname "[feisty]  Slow gnome application startup due to /etc/hosts misconfiguration" [Undecided,Incomplete]  https://launchpad.net/bugs/94048
<bddebian> Or 192.168.x.x or 169.x.x :)
<seb128> I didn't really investigate
<cjwatson> bddebian: no, RFC1918 is private use ranges which is different
<seb128> but according to the number of comment it seems to create issues
<bddebian> Oh, sorry
* bddebian shuts up
<cjwatson> seb128: the old way created issues too, so just going back wouldn't achieve much
<cjwatson> seb128: it is exceedingly unclear from that bug what the problem actually is, and the number of comments could actually be a conflation of several different problems
<kblin> well, I don't have a ready fix for this, creating a nss module might be worth investigating
<dholbach> cjwatson: do you think bug 83690 makes sense? shall I assign it to you?
<ubotu> Launchpad bug 83690 in grub "update-grub hardcodes to 'Ubuntu'" [Undecided,Confirmed]  https://launchpad.net/bugs/83690
<cjwatson> dholbach: yes, it's clearly a bug and I agreed with the gnewsense folks some time ago that we'd fix it
<cjwatson> dholbach: sure, can be assigned to me
<dholbach> cjwatson: rock on, cheers
<seb128> cjwatson: right
<kblin> I'll probably need to give this some more thought.
<kblin> but I need to catch my bus to catch my plane, so I'll get back to you folks later
<kblin> thanks for your input in any case
<cjwatson> seb128: starting gnome-terminal in strace doesn't seem to mention 127.0.1.1 at all here
<cjwatson> though I'm on a network where my hostname resolves locally ...
<dholbach> kylem: if you have the time can you upload the patch of bug 57755?
<ubotu> Launchpad bug 57755 in gnupg "Udev Rules for SmartCard Support" [Undecided,New]  https://launchpad.net/bugs/57755
<cjwatson> but it doesn't talk to my nameserver either
<dholbach> lamont: I think you asked me to prod you wrt bug 33586 :-)
<ubotu> Launchpad bug 33586 in nmap ".desktop file cleanup for nmapfe" [Wishlist,Incomplete]  https://launchpad.net/bugs/33586
<Mithrandir> dholbach: for 57755; those rules are shipped by libccid already
<dholbach> could you follow up on the bug report? I have no clue about libccid and friends at all
<Mithrandir> sure
<dholbach> gracias
<dholbach> Riddell: could you check out bug 136425? it's a small fix for qt4
<ubotu> Launchpad bug 136425 in qt4-x11 "qtconfig-qt4 in Accessories?" [Undecided,Confirmed]  https://launchpad.net/bugs/136425
<Riddell> dholbach: isn't that the one you've been poking me at for a while?
<Riddell> mm, no, different
<dholbach> Riddell: not sure
<Riddell> well, I'll add it to my todo
<dholbach> rock on - thanks
* dholbach hugs Riddell, Mithrandir, cjwatson and all the other hard-working patch reviewers
* Hobbsee continues to slack off in the corner
<seb128> cjwatson: right, same for me
<dholbach> calc: what do you think about bug 134112 and bug 133793?
<seb128> cjwatson: there seems to be an issue for some people, but the mix of comments doesn't make it easy to figure something clear
<ubotu> Launchpad bug 134112 in openoffice.org "added Xb-Npp-xxx tags accordingly to "firefox distro add-on suport" spec" [Undecided,New]  https://launchpad.net/bugs/134112
<ubotu> Launchpad bug 133793 in openoffice.org-voikko "Please sync openoffice.org-voikko from Debian" [Medium,Confirmed]  https://launchpad.net/bugs/133793
<cjwatson> seb128: the "host name lookup failure on localhost" message seems to be from gnome-session
<cjwatson> seb128: (look, an application of Google Code Search!)
<cypherbios> mvo_: are you around?
<cjwatson> seb128: though from the code it looks to me that it will always emit that message at least once, no matter what?
<lamont`> dholbach: yeah, I did.
<cjwatson> oh, no, I'm misreading its intent
<lamont`> dholbach: I made progress towards my goals, but did not finish getting things together
<dholbach> lamont`: that sounds good :)
<lamont`> yeah - it's on the list for this evening to spend more time on such things
<dholbach> thanks a lot
<ogra> wow, now that was bad
* ogra is cured from using xgl now
<dholbach> doko: do you think that the patch on bug 103929 makes sense?
<ubotu> Launchpad bug 103929 in bash "Bash prompt string looks for xterm-color, gnome terminal identifies as xterm" [Wishlist,In progress]  https://launchpad.net/bugs/103929
<bryce> morning
<dholbach> hey bryce
<bryce> heya dholbach
<dholbach> bryce: you think we can upload the patch on bug 117939?
<ubotu> Launchpad bug 117939 in inkscape "tutorial-basic.svg has wrong text" [Undecided,Fix committed]  https://launchpad.net/bugs/117939
<dholbach> or do you want to wait for the new upstream version?
<bryce> upload the patch; there won't be a new upstream release for at least a couple months
<doko> dholbach: maybe, it's wishlist, I have to work on bash anyway, but not now ...
<dholbach> doko: ok
<dholbach> bryce: ok, will upload it
<bryce> dholbach: I'd proposed doing a release in time for gutsy, but everyone pretty much felt that a release should wait until after the GSoC code additions had been finished and had time to stabilize
<dholbach> ah ok, that makes sense
<bryce> (as an aside, I wonder if the GSoC timeline may be affecting other OS projects similarly?)
<ogra_> grmblfjx
<bddebian> grmblfjx?
<ogra> yes
<ogra> with three !!!
<ogra> somehow my system just freaked out ...
<bddebian> Hrm
<ogra> after the hardlock i rebooted ...
<ogra> after reboot i couldnt sudo anymore
<bddebian> Doh :-(
<ogra> well, i could, but every command took about 10mins to return a line in the terminal
<Revel> I've asked in the general channel like 5 times and no one seems to be able to help.  This cannot be that hard...
<Revel> Having problems mounting a transcend ide flash disk.  DMESG shows errors but I am unable to find anything good on google related to this besides some PCMCIA problems with external drives.  Help please ;( 2nd week on this one.
<Revel> dmesg: http://paste.ubuntu-nl.org/36340/
<bddebian> Hmm, still on GLwDraw in Gutsy either eh?
<bddebian> s/on/no/
<lucky_lucas> Hi
<stgraber> asac: I've just finished a full test of switching between WPA, Public and Wired networks (I'm back at home), didn't see any real problem
<stgraber> just sometime the "AP_SCAN 0" taking ~4-5 seconds to timeout which causes NM to stay connected on the network before connecting to the new one (or wired)
<Revel> w/in3
<stgraber> asac: oh, something else I just noticed, any reason to have a wpa_supplicant process running when connected to wired ?
<stgraber> asac: I have a wpa_supplicant -g /var/run/wpa_supplicant-global2 running
<stgraber> asac: and NM didn't deassociate from my public WLAN when switching to wired (may be caused by the remaining wpa_supplicant)
* Chipzz kicks his wireless
<Chipzz> asac: since you've been talking about it the last couple of days...
<Chipzz> is there a way to prevent the ipw2200 chipset from associating with a random accesspoint?
<Chipzz> (I have an essid specified in /e/n/i, but sometimes it just ignores that)
<Riddell> azeem: were you looking at packaging the new opensync?
<azeem> so far, lifeless did the library and I did the modules
<Riddell> azeem: so what's left?
* lamont` wonders what caused libsvg1 to land back in main
<azeem> Riddell: so far, the libraries haven't been updated
<azeem> and really, it's quite unclear to which version
<Riddell> lamont`: calc was wanting it I think
<cjwatson> lamont`: yes, Riddell is correct
<Riddell> azeem: but you said lifeless was doing the library
<cjwatson> lamont`: "back"? it seems to be entirely new in gutsy
<azeem> Riddell: well, for the previous uploads I meant
<mathiaz> keescook: if we do a merge from debian that includes a security fix, should you be involved in that ?
<Riddell> right
<azeem> Riddell: there's also the problem with the user data being incompatible between the current gutsy/feisty version and upstream
<azeem> so at least I have waited for a stable upstream version
<geser> calc: Hi, when you have time can you sponsor the debdiff for bug #130583?
<ubotu> Launchpad bug 130583 in xmlsec1 "libxmlsec1-nss missing pkgconfig file" [Undecided,New]  https://launchpad.net/bugs/130583
<Riddell> azeem: is the current version considered stable?
<azeem> no
<Riddell> right
<azeem> or do you mean the current version in gutsy?
<Riddell> no, the newest upstream release I ment
<azeem> yeah, that's the problem
<azeem> there's been a 0.22 release which was moderately stable I think, but it's incompatible to both current gutsy and next upstream stable
<keescook> mathiaz: if it needs back-porting to earlier releases, yeah, I'll need to publish them through the security queue
<keescook> has anyone started using the new python launchpad API?  I can't get it to set status...  :(
<soren> keescook: Bughelper uses it, I believe.
<keescook> soren: right, but it's a read-only tool.  Also, the Wiki examples don't work (there is no "apply", though "commit" fails too)
<mathiaz> keescook: should I file a new bug or flag the current bug as a security issue ?
<keescook> mathiaz: no reason for duplication; just flag it as security.  which bug is there?
<keescook> er, *is this?
<mathiaz> keescook: well... there is a cve assigned to it.
<mathiaz> keescook: bug 136596
<ubotu> Launchpad bug 136596 in fetchmail "[Merge]  fetchmail 6.3.8-8ubuntu1" [Undecided,New]  https://launchpad.net/bugs/136596
<mathiaz> keescook: fetchmail-SA-2007-02: Crash when a local warning message is rejected
<keescook> ah yeah, very minor issue.  It's a bit down on my todo list, but if people have already generated and tested patches, I can publish them.
<mathiaz> keescook: well. It came from the debian unstable.
<mathiaz> keescook: that's why I asked.
<keescook> right, what I mean is, if this applies to feisty, edgy, dapper, we'll need patches for those releases too.  (This is already on my todo list, but lower down due to the very low priority of this CVE)
<mathiaz> keescook: ok.
<thekorn> keescook: python-launchpad-bugs is not working for you?
<thekorn> maybe this might help: https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/Bug
<keescook> thekorn: ah-ha!  just the person I need to ask lots of questions.  :)
<keescook> thekorn: http://paste.ubuntu-nl.org/36351/    that doesn't work.  only the comment is recorded.
<keescook> thekorn: also, "Bug" seems to require an "int", it doesn't like getting a string, which is odd, given the code.  :P
<thekorn> keescook: does your code not work for all bugs, do you have a test case
<keescook> thekorn: well, I only tried it on a single bug, but it always failed (137018)
<thekorn> keescook: looking...
<thekorn> keescook: it just fails becaus 'ubuntu-security' is not subscribed to this bug
<keescook> thekorn: ah, is there some way to make the error more meaningful?  :)
<keescook> I should add a check for 'ubuntu-security' in .subscribers?
<thekorn> yes, that might be the easiest way
<keescook> cool!  thanks.  :)
<thekorn> or try:...except:...
<keescook> but that's just around the "commit".  I'd have to commit each change separately, which seems ugly.  :)
<thekorn> no, you can commit all changes to a bug at once
<thekorn> or you can commit all changes to all changed bugs at once
<janimo> asac: hi
<thekorn> keescook: but it won't reduce the traffic
<keescook> thekorn: right, but I meant, to find the problems with input (without better error reporting) I'd need to make one change, try:commit, repeat.
<thekorn> keescook: no, I would put try:..except:... around bug.subscribtions.remove("ubuntu-security") for example
<keescook> thekorn: but that's not where my script failed.  :)  (at the time, ubuntu-security was subscribed).  It exploded at .commit
<thekorn> aha
<thekorn> keescook: my problem at this point is: I'm unable to reproduce any kind of errors on this
<amitk> bryce: --> #ubuntu-mobile
<keescook> thekorn: let me create a test bug, one sec
<thekorn> thanks
<keescook> thekorn: okay, 137325 dumps on me with the previously pasted script.  Here are my errors: http://paste.ubuntu-nl.org/36353/
<keescook> (I've subscribed you to it)
<thekorn> keescook: will have a look at it
<thekorn> this message is useless, have to fix this
<\sh> thekorn, how do I authenticate with the bughelper class? :)
<thekorn> \sh: Bug.authenticate=<file> where file is a valid mozilla/firefox cookie-file
<\sh> thekorn, ah ok :)
<asac> stgraber: is that with associate:1 ?
<lucky_lucas> hi bryce
<asac> stgraber: the wpa supplicant process is normal as nm scans using wpa
<thekorn> keescook: thanks for pointing me to this error,
<bryce> hi lucky_lucas
<keescook> thekorn: sure! glad I could help.  :)
<asac> Chipzz: ok i could take a look ... can you ping me tomorrow?
<stgraber> asac: no, that was normal use (associate=0)
<lucky_lucas> I m trying to figure out where the crashes of X/linux come from and I may need guidance
<asac> stgraber: hmm do you see that the device is deactivated?
<asac> stgraber: e.g. when you switch to wired?
<asac> stgraber: or is it just after initial startup?
<stgraber> asac: ok, so it seems that NM doesn't send a deassociate when switching back to wired
<lucky_lucas> bryce: I'm talking about  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/134578
<ubotu> Launchpad bug 134578 in xserver-xorg-video-ati "Open source ati driver freeze with compiz" [Undecided,Incomplete] 
<stgraber> asac: usually I have off/any as essid with iwconfig
<thekorn> keescook: will have a closer look at it tomorrow
<stgraber> asac: but here I have the last wifi network I have been connected to (public wifi)
<keescook> thekorn: okay, thanks
<asac> stgraber: is that reproducible? does it happen always when you switch back to wired?
<asac> stgraber: and you don't see: deactivating device (eth1) in log when to wired?
<stgraber> asac: I just did one more test
<davmor2> bryce: ping
<stgraber> asac: result is that I have that deassociation problem only when moving back to Wired from Public
<stgraber> asac: and when I have the AP_SCAN 0 timeout thing
<Chipzz> asac: I can
<bryce> lucky_lucas: as I said in the bug report, there isn't an error message or anything we can troubleshoot from, so all I can offer is vague guesses - test the proposed -ati 6.7.192 patch.  My latest xorg-server upload is just now out, which has a handful of random fixes, so try that too.  If it still is a problem, follow the directions on DebuggingXorg
<Chipzz> asac: problem is, it is not really reproducable
<bryce> davmor2: yup
<lucky_lucas> bryce: That's what I m doing
<davmor2> bryce: I've updated bug 134284 is there another info you need or is that enough?
<ubotu> Launchpad bug 134284 in xorg "The X intel driver is not functioning correctly" [Undecided,New]  https://launchpad.net/bugs/134284
<lucky_lucas> I attached the Xorg process in gdm and it blocks the system I can let it run by doing cont but I don't know if I m doing right
<Chipzz> asac: and, I'm not using wpa_supplicant/networkmanager, so dunnow how far you're reallly interested :P
<bryce> davmor2: sorry, I was looking at that but got interrupted.
<davmor2> np
<davmor2> your a busy man
<bryce> so to doublecheck - when you load the livecd, X comes up with the -intel driver?
<davmor2> correct.  ed/ubuntu both usable but k/xubuntu are unusable because of it.
<bryce> sort of the inverse problem we normally have
<bryce> ok there are two entries by this pciid in discover data
<davmor2> probably
<bryce> one is 'NC2400', the other 'Thinkpad R60e model 0657' - either of those sound familiar?
<davmor2> no mine is compaq c300 I think just get it and double check
<davmor2> yep compaq presario c300
<bryce> hrm
<bryce> odd, your card's not in the database - http://pci-ids.ucw.cz/iii/?i=808627a2
<davmor2> interesting
<davmor2> is there any other info I can give you in order to track it down a bit more?
<EvanCarroll> I wanted to throw idea out, a multithreaded dpkg-installer, with the ability to predetermine collisions with other isntalling processes...
<Amaranth> no
<Amaranth> wouldn't help, main bottleneck should be the disk
<bryce> davmor2: the only missing piece of info is the 'subsystem_name'.  In your lspci output it displays Subsystem: Creative Labs Unknown device [1102:1003] 
<EvanCarroll> well in a perlbal, you have a MANIFEST which stores the modified files, dpkg could just as well read from a manifest and determine if other installing processes are wanting to minipulate the same files.
<bryce> it'd be nice to know what it should be instead of 'Unknown device'
<bryce> er whoops
<bryce> Subsystem: Hewlett-Packard Company Unknown device [103c:30a5] 
<davmor2> 2 secs
<zasf> enrico: ping
<stgraber> bryce: hehe, funny, 3 hours ago I noticed that Gutsy wasn't working with our computers at school due to frequency problem with our Acer monitors, I come back home, check my mails and see the fix being uploaded :) thanks
<asac> Chipzz: if the driver deliberately associates its also a problem for nm and supplicant :) ...
<asac> Chipzz: isn't nm running at all?
<bryce> stgraber: awesome, did the fix fix it?
<stgraber> bryce: no idea, I will check tomorrow but I think so as it's exactly the issue I saw
<bryce> cool
<bryce> well let me know either way; I'm curious how many issues these backports are going to fix in practice
<stgraber> bryce: should be in tommorow daily right ? (they are generated early in the morning (europe) IIRC)
<zasf> glatzor: I'm looking in g-a-i for a way to call it
<bryce> stgraber: yup
<glatzor> zasf: do you have got a closer idea what you want to do?
<zasf> glatzor: it turns not to be an easy job as you were saying yestarday
<zasf> glatzor: g-a-i_install_this_and_enable_component_if_necessary(package)
<zasf> :)
<glatzor> zasf: I have voted against such an approach.
<Kopfgeldjaeger> hi
<zasf> glatzor: I paste something if you have time to look at ti
<davmor2> bryce: what is likely to be?
<zasf> glatzor: http://www.pastebin.ca/681311
<glatzor> zasf: I would suggest to use some low level classes of g-a-i
<zasf> glatzor: I'm all ears :)
<glatzor> zasf: introducing a new activation style was what I wanted to avoid
<glatzor> zasf: I don't think that you will include any third party repositories in restricted manager
<bryce> davmor2: no clue, it'll be some sort of subsystem name like C1234 or Acme FooMeister 3000
<glatzor> zasf: I started working on an application view for update-manager, perhaps I will find the code again
<Amaranth> hrm
<bryce> actually we know it's HP, so it'd be a HP FooMeister 3000
<Amaranth> does a random crash in malloc mean something bad? :)
<glatzor> zasf: perhaps we should move the caching to the CoreApplicationMenu
<glatzor> zasf: but that is another issue.
<zasf> glatzor: I thought that I needed and instance of AppInstall, so that I use tryinstall or something
<glatzor> zasf: you could use the CoreApplicationMenu class to locate the component of a package
<glatzor> zasf: this will blow up your code a lot.
<glatzor> zasf: what you really need ist packagekit.org :)
<zasf> glatzor: I'm just experimenting for fun :)
<glatzor> zasf: you want to do this in the gutsy time frame?
<zasf> glatzor: I do it in my spare time, no hurries
<davmor2> bryce: online docs it is
<zasf> glatzor: if I can help, I'll be happy
<glatzor> zasf: I think copy and paste of the tryinstall method would be easier
<bryce> davmor2, anyway, so once you have that info, let me know and I can add the quirk for it to use -i810 in discover-data.  You probably ought to also submit the info here:  http://pciids.sourceforge.net/
<bryce> davmor2: you might find it worthwhile to submit that data for the other 'unknown device' entries in your lspci -vvnn, as it may help your device support in the future
<glatzor> zasf: but do you really have got any data that could not be available?
<zasf> glatzor: if g-a-i turns out not to be helpful, I don't see any other alternatives
<davmor2> bryce: Where?
<zasf> glatzor: I checked command-not-found but its data is based on the fact that a specific package contains commands (ie c-n-f has no data for packages with no commands in it)
<bryce> see the 'How to submit new data' at http://pciids.sourceforge.net/
<davmor2> ta
<glatzor> zasf: take a look at _confirm_source_activation in AppInstall
<glatzor> zasf: but I am currently also a little bit clueless.
<glatzor> perhaps it is already too late :)
<zasf> glatzor: you're right :) thanks for your support
<zasf> glatzor: going to dinner
<glatzor> zasf: the best solution would be to provide a high level install package method that also can enable components. but since this is not available yet, I think that there is no ideal solution.
<zasf> glatzor: ok, that is bad news for me but still an important piece of information
<glatzor> zasf: showing the main window of gnome-app-install would result in a quite strange workflow
<cjwatson> Amaranth: typically means that at some earlier point the process corrupted the malloc arena by freeing something that was already freed, or trying to allocate or free memory in a signal handler, or trying to free/realloc something not returned by malloc, or various other such things. valgrind is usually the best way to find what actually went wrong
<Amaranth> cjwatson: but random?
<Amaranth> i mean, that's what the bug reporter said, i've never seen the problem
<zasf> glatzor: yes, what I tought is: don't show it, trough modifyUserInterface, call something in background to get the work done and most importantly show accept dialogs
<Amaranth> it died somewhere far inside libxml2 and he said it usually doesn't happen and was actually using compiz when filing the bug
<glatzor> zasf: you could also modify it even more by replacing all appplication widgets with a text label "Do you want to install the drivers for 'your new hardware here'?"
<glatzor> zasf: oh wait. but when to show the enabling dialogs
<zasf> glatzor: I just don't need the main window, all the rest is very good
<glatzor> zasf: right. the apply changes method should be called after enabling the components afaik
<glatzor> zasf: you could use on_install_toggle(None, item)
<cjwatson> Amaranth: could be anything within the calling process, at any other point
<Amaranth> fun
<zasf> glatzor: yes, I haven't found the right method to call yet. That applyChanges in my test is just the first guess
<glatzor> zasf: perhaps you are on a good way
<cjwatson> Amaranth: you could try having him set MALLOC_CHECK_=3 in compiz's environment if using valgrind is too hard; it might help
<zasf> glatzor: hehe nice to hear from you
<zasf> glatzor: now I really have to go, thanks for your support
<zasf> bye all
<glatzor> bye
<davmor2> bryce: I've done a bunch of browsing and everyone lists it as a Intel Graphics Media Accelerator 950 so could that be the issue?
<davmor2> bryce: http://h10025.www1.hp.com/ewfrf/wc/document?docname=c00797501&lc=en&cc=uk&dlc=en&product=3318980&rule=38923&lang=en#N331
<holymoly> hi
<holymoly> i would like to have hplip packaged for dapper
<holymoly> latest is 2.7.7 and is in gutsy but backport don't show it available
<holymoly> any tips on the easiest way to create an ubuntu package for hplip?
<dobey> get the source
<dobey> install the build dependencies
<dobey> and dpkg-buildpkg -rfakeroot
<holymoly> thats it?
<dobey> source being the "source" from gutsy
<holymoly> nice thanks
<holymoly> aha!
<holymoly> righto, IMPORTANT piece of info
<dobey> add the deb-src line for gutsy to /etc/apt/sources.list
<dobey> then apt-get update
<dobey> and apt-get build-dep hplip
<dobey> then apt-get source hplip
<dobey> cd into the hplip source dir
<dobey> and dpkg-buildpkg -rfakeroot
<holymoly> wow thats  great
<dobey> you probably need to install fakeroot for that to towkr also
<dobey> to work
<holymoly> right
* holymoly takes notes
<holymoly> didn't know it was that easy, more or less
<cjwatson> note that dpkg-buildpackage is misspelled above
<holymoly> right
<dobey> oh yeah
<dobey> dpkg-build<tab>
<dobey> :)
<holymoly> once i build it i would be happy to donate it to backports
<holymoly> how is that done?
<dobey> cjwatson: i always get tripped up with that, because dpkg has it as pkg, and buildpackage has it as package :-/
<dobey> that i don't know
<holymoly> no problem i'll find out
<cjwatson> holymoly: it isn't - backports is done semi-automatically and the packages are always built on the archive master system
<seb128> use debuild ;)
<holymoly> thank you very muchly
<cjwatson> holymoly: but you can certainly contribute the fact that the backport works for you
<holymoly> aha
<holymoly> okay thanks
<dobey> personally, i would just wait 4 weeks or whatever, and install gutsy
<cjwatson> they use bugs on {dapper,edgy,feisty}-backports to track that sort of thing, and there's probably something on the wiki about the process
<dobey> seb128: debuild? isn't that the opposite of building something? :)
<seb128> dobey: not, that's debianbuild ;)
<holymoly> dobey: i haveto make a decision about buying a printer today unfortunately
<holymoly> and hp has these new multifunctions that are actually cheaper to run than laser printers for black and white printers
<dobey> uh, ok
<holymoly> so it would be nice to have hplip actually packaged so we can deploy to 30 or so boxes, it will be much harder for us to upgrade gutsy instead
<dobey> sure
<sistpoty> desrt: any idea about bug #137354 ?
<ubotu> Launchpad bug 137354 in missingpy "sparc build fails with "[test-ghc6]  Bus error"" [Undecided,New]  https://launchpad.net/bugs/137354
<holymoly> cjwatson: what are the rules for deciding what is backported ... is there a request system of some sort?
<cypherbios> mvo_: the package is ready at the same url
<cypherbios> I gotta go
<jamiemcc> seb128: when is the cut off point for tribe 6?
<davmor2> bryce: Would intel release a chipset with a beta driver?  If so then maybe there is a bios update which changes the driver for the chip?  long stretch guess I know but just a thought.
<sladen> holymoly: I thought hplip was already installed by default?
<bryce> davmor2: it's possible
<sladen> holymoly: ps aux | grep hplip ...
<davmor2> right on the hunt for a bios update then :)
<bryce> davmor2: however more likely is that compaq added something that conflicted, or else did something to result in the incompatibility
<bryce> davmor2: is this just a personal machine, or is it a hardware series we're going to be providing support for?
<davmor2> personal machine as far as I know
<bryce> ok, well that rules out going through business channels ;-)
<holymoly> sladen: 0.9.7 is in dapper
<holymoly> hplip is already up to 2.7.7
<holymoly> the old vesion is not exactly spectacular
<bryce> davmor2: if it is just a personal machine, what is the motivation for getting it to boot the right driver from the installer?  Are you just working to get the hardware support improved for your machine?
<sladen> holymoly: right, so file  a bug saying that, detailing the changelog and the differences
<davmor2> No I would just like it to work correctly.  If it is as compaq say a 950 graphics card then it has better 3d stuff than the 945.  So it would be good if it worked correctly.
<holymoly> sladen: that would be considered a bug?   sure i'll do that
<sladen> holymoly: if something doesn't work automatically out-of-the-box as you expect, then that's a bug
<holymoly> this is more of a backport tho
<holymoly> hplip works it just isn't the latest version
<holymoly> tomato tomato :)
<holymoly> filing
<ionstorm> is ubuntu's goal for everything to run out of the box
<ionstorm> https://bugs.launchpad.net/ubuntu/+bug/34902 should be criticle since belkin is used by thousands, if not millions of people
<ubotu> Launchpad bug 34902 in ubuntu "Ralink Wireless legacy drivers (rt2500 rt61 rt73 rt2570) USB/PCMCIA/PCI hangs PC" [High,Confirmed] 
<ionstorm> critical*
<ionstorm> define "high" priority, will it be fixed?
<cjwatson> holymoly: yeah, there's a request system - basically has to build cleanly without modifications, has to be new features (i.e. outside the normal stable updates procedure), has to not make core developers scream in horror (yes, this is subjective)
<holymoly> right
<holymoly> danke
<holymoly> i have a terribly noob questioneven though i'm not
<holymoly> lol
<holymoly> i'm trying to find the hplip gutsy src package and i can't see it
<holymoly> i just have one src line in my sources.list file for gutsy and i don't see an hplip-src file
<holymoly> *hmm*
<cjwatson> holymoly: 'apt-get source hplip'
<cjwatson> source packages are not named like "foo-src" as a general rle
<cjwatson> rule
<holymoly> ohhhhh
<holymoly> okay thank you very muchly
<cjwatson> the files are all in http://archive.ubuntu.com/ubuntu/pool/main/h/hplip/ if you need to get them by hand, but you shouldn't have to
<holymoly> coolness, adding to my notes
<holymoly> would this indicate the dependencies in dapper are not in line with what source code expects in gutsy: E: Build-Depends dependency for hplip cannot be satisfied because no available versions of package debhelper can satisfy the version requirements
<gnomefreak> was it just me or yesterdays updates (give or take a day) mounted filesystem((bin var ect..) as an externel drive?
<desrt> sistpoty; sorry.  no.  haven't hacked ghc for a while
<desrt> and never on sparc :)
<Hurga> Hi there... not sure if I'm right here, but folks on #ubuntu directed me here. I have trouble on 6.06 with mkisofs and genisoimage on 7.04, file size of more than 2 GB seems not to be supported. Is that correct, a bug or a feature?
<Hurga> ok. mkisofs and genisoimage, who to ask?
<Trewas> Hurga: feature afaik, iso9660 does not support large files and udf support in linux cd-burning programs is (or was when I researched a few months back) a bit sketchy... actually I ended up buying nero linux for burning >4GB files :/
<Hurga> Trewas: http://en.wikipedia.org/wiki/ISO_9660#The_2_GiB_.28or_4.2GB_depending_on_implementation.29_file_size_limit
<Hurga> "The free software mkisofs is able to create filesystems that use multi-extent files to support file sizes up to 8 TB."
<Hurga> Trewas: I definetely have been able to create UDF discs of 4.5 GB a few years ago. These days UDF craps out at 1 GB when I copy a larger file on it.
* Hurga really wonders if no ubuntu user has files larger than 2 GB. This can't be.
<Trewas> Hurga: according to that article nothing except windows xp can read those fragmented large iso9660 files, not very useful...
* Hurga sighs.
#ubuntu-devel 2007-09-05
<holymoly> *hmmm*
<holymoly> a dd is mentioned as the maintener of hplip on ubuntu
<holymoly> does that sound right?
<holymoly> do ubuntu maintainers take over from dd maintainers?
<StevenK> holymoly: According to my Gutsy chroot, the Maintainer is Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com>
<StevenK> holymoly: But, it isn't uncommon to have a Debian Developer as a Maintainer of a source package in Ubuntu, we are after all, derived from Debian.
<holymoly> right, if i have a question about a particular package and building a particular package on ubuntu (say dapper), should i post to the ubuntu devel mailing list?
<holymoly> i'd hate to spam the dd with ubuntu questions if he isn't directly involved in ubuntu
<azeem> you should post to the user list I guess
<holymoly> okay thank you
<azeem> building packages for the sake of it isn't distribution development
<holymoly> true, i know how touch dd's are about the ubuntu project, would really hate to add to the fire
<StevenK> holymoly: Most of them are reasonable. It's the verbal minority that give that impression.
<holymoly> well thats probably true
<holymoly> okay so let me ask this question
<holymoly> i've built hplip 2.7.7 from source and installed it via the hplip installer on dapper as well (which also builds it from source)
<holymoly> using the gutsy src package for hplip is not working it seems as debhelper cannot resolve the dependencies
<holymoly> i'm assuming the maintainer is modifying some of the dependencies and assuming gutsy versions
<holymoly> how else can i build an hplip package? i presume similar steps can be used with the .tar.gz from sourceforge?
<bddebian> Heya
<Hobbsee> hi bddebian
<bddebian> Heya Hobbsee
<holymoly> what would be a nice simple application to try and backport
<holymoly> something that doesn't require too many dependencies?
<RAOF> holymoly: Miro!
<holymoly> in the repos
<holymoly> i'm testing something called prevu
<holymoly> it supposedly simplifies the backporting process
<RAOF> holymoly: What do you mean.  Miro's in the repos, right?
* RAOF checks, since he was *pretty* sure it had got it's UVFe, and was uploaded...
<holymoly> nope
<holymoly> not that i can see
<dobey> holymoly: gtk2-engines-cleanice would be a simple backport
<holymoly> danke!
<dobey> no problem ;)
<holymoly> oh yeah that totally makes sense, right
<StevenK> RAOF: rmadison -u ubuntu knows nothing about miro
* RAOF checks the new queue
<ajmitch> sure, it's stuck in NEW
<RAOF> Oh, yeah.  There it is.
<StevenK> Source NEW, I'm guessing.
<StevenK> Hrm, ENOSEB
<RAOF> Indeed
* StevenK is getting together a list of poppler rebuilds.
<StevenK> 16. Not too bad.
<StevenK> Except that one of the packages is texlive-bin ... twitch.
<wolfe> ENOSEB?
<StevenK> As in, seb128 isn't here.
<wolfe> ohhh, heh
<bryce> i just got one of those errs too
<StevenK> Heh, it's catching.
* Hobbsee waves to bryce
<bryce> hi
<holymoly> okay so backporting an app from gutsy obviously is a dependency challenge
<bddebian> Yep :-)
<holymoly> if i have the source files and instructions how to compile and make install on dapper from the original vendor, how easily can that be built into a deb?
<bddebian> Depends on the package and your definition of easy
<holymoly> well right now i'm a noob trying to jet get a deb of hplip 2.7.7 for dapepr built, later i'm interested in learning more about packaging, compiling and coding
<holymoly> so i'm heavily leaning on easy :) just for now
<bddebian> Is there a specific reason you need it for Dapper?
<holymoly> because we have about 30 dapper boxes and need hplip support roughly within the next day or two.  waiting for gutsy to show up isn't really an option, never mind that a company wide dist-upgrade is unlikely to happen without serious testing anyway
<holymoly> it's not an emergency, i just haveto buy some printers and would love to have proper hplip support
<bddebian> Ah
<bddebian> You need the gutsy version?
<holymoly> i've compiled and installed hplip 2.7.7 from scratch using the hp provided sources, what i need is a deb i can deploy because compiling on 30 machines each time is not really a sensible thing to do
<bddebian> One thing you could try is grab the Dapper hplib source package copy the debian dir from that to an extracted tarball of your 2.7.7 and try to tweak it to build with that
<holymoly> oh thats interesting
<holymoly> *hmm*
<lamont> cjwatson: we'd done a good job of nuking libsvga1, iirc... it's not present on all platforms, so it tends to be one of the things that gets a reaction out of me...
<det> If a package was uploaded to Debian sid on Aug 3rd, does that mean it will not be included in Gutsy?
<det> Sorry, I mean Sep 3rd (yesterday)
<bddebian> det: If it is a new version most likely not unless a UVFe is filed.  If it is just a new release, possibly.
<det> It is a new release and has support for more architectures (It is a compiler which, with this release, can now target 64-bit platforms)
<det> New version, I mean.
<Chipzz> det: extremely low probability of being included I'ld say
<Chipzz> new version, new features, features which are likely to break other stuff
<Chipzz> (last thing depending on how pervasive the changes are)
<Amaranth> det: what is it?
<det> MLton
<Amaranth> never heard of it :)
<det> Yeah, there isnt much chance of it breaking anything.
<Amaranth> is has zero rdepends
<det> exactly
<det> does rdepends include build-depends ?
<Hobbsee> Amaranth: it's a *compiler*.  of course it wouldnt.
<Chipzz> det: also depends if it's main or universe
<det> universe
<Amaranth> but it's also universe so that's an #ubuntu-motu thing
<Amaranth> hobbsee: oh, right, didn't see that :)
* Hobbsee hands Amaranth the dunce cap
<det> It is significant in that it now builds on amd64
<Chipzz> det: current version in gutsy appears to be quite old
<Chipzz> so the delta is likely to be quite big
<Chipzz> Version: 20061107-1
<Chipzz> but otoh, only mlton build-depends on it
<Chipzz> heh :P
<cjwatson> lamont: well, svg != svga
* StevenK ponders filing a UVFe for gimp. Debian has rc2, which probably has less bugs than 2.3.18
<ion_> It would be nice to have.
<lamont> cjwatson: DOH
<StevenK> cjwatson: As a member of -release, do you think I should bother filing it?
<StevenK> cjwatson: And when are you going to get your launchpad account changed to not be ~kamion. :-P
<cjwatson> StevenK: hmm, not sure, sounds worth considering, but I'm supposed to be getting on a train
<cjwatson> StevenK: we'll be lambasted if we ship an RC and it turns out to suck though
<StevenK> cjwatson: Agreed.
<cjwatson> though, is 2.3.18 part of the same development cycle?
<StevenK> Yup, an earlier snapshot of
<cjwatson> ah, ok, definitely sounds worth considering then
<StevenK> cjwatson: Just before you go, I will build Debian's version for Gutsy and round up a few testers. If they don't want my blood, I'll file a UVFe.
<cjwatson> I tried to change my Launchpad account name a while back but the problem is that it changes the URLs for all my Bazaar branches
<cjwatson> so I need to figure out something for that
<cjwatson> StevenK: sounds good
<StevenK> cjwatson: Ahh. Launchpad won't/can't do redirects?
<thekorn> keescook: can you please try my patch attached to bug 137437
<ubotu> Launchpad bug 137437 in python-launchpad-bugs "committing a status-change does not work" [Medium,New]  https://launchpad.net/bugs/137437
<dholbach> good morning
<kagou> Good morning
<soren> Has MoM been switched off?
<pwnguin> a question about readahead: is the list sorted in any particular order?
<dholbach> pwnguin: if you see anything we could do make it better - that'd be awesome
<pwnguin> im just browsing the source right now, but i was thinking to myself, if they just read one file at a time in no particular order, that's painful
<dholbach> pwnguin: Keybuk (once he's here) might answer that question for you if your inspection of the code doesn't
<ion_> The files are sorted optimally.
<pwnguin> that sounds impressive
<pwnguin> it looks like it essentially calls the syscall readahead() on every file. i was thinking it might make sense to queue up a couple or more at a time
<pwnguin> and let the disk scheduler sort out what's optimal
<thom> pwnguin: no; it makes more sense to order the files based on disk position, so you can pick them up in the correct order
<pwnguin> thom: i think thats what im saying
<pwnguin> though i dont know much about how the scheduler currently works
<thom> that's what it does, now
<soren> pwnguin: The disk scheulder doesn't know where the files are.
<soren> pwnguin: It deals with blocks and sectors, not filenames. You can't give it a list of filenames you want and make it fetch them in the most optimal order.
<dholbach> hey seb128
<seb128> hi dholbach
<dholbach> seb128: if you get back to doing archive stuff, do you think you could reject sqlite-ruby (in the NEW queue)?
<StevenK> seb128: I'm looking at uploading 15 rebuilds for the poppler SOVER bump, do you have an issue with that?
<pwnguin> soren: well, i almost never see very good throughput on readahead. i dont know if it's a matter of file system overhead, fragmentation, or simply lots of small files rather than big ones.
<seb128> dholbach: ok, why?
<seb128> StevenK: no
<seb128> dholbach: btw why "get back", I usual do archive work on wednesday I didn't stop it ;)
<StevenK> seb128: Just test-building the lot of them. At this point I will probably skip gimp, since I'm looking at updating it.
<dholbach> seb128: I did not follow the NewPackagesFreeze process
<seb128> StevenK: ah, good to know, I was going to do merge the 2.4 rc from Debian, I don't need to do it if you are already working on it ;)
<StevenK> seb128: It needs a UVFe, I was going to do it, and get a few people to test.
<seb128> ok
<seb128> yeah, I know it needs an UVF exception, I expect it'll be easy to get though
* StevenK nods.
<StevenK> seb128: Can you push poppler through binary NEW? It has built everywhere.
<Company> siretart: ping
<seb128> StevenK: I was just doing it
<StevenK> seb128: Cool, sorry to bug you.
<seb128> that's ok ;)
<StevenK> seb128: Hrm, will the binaries make the publisher run that starts in about 2 minutes?
<seb128> likely
<StevenK> Way cool.
<StevenK> Even though I'm limited by when the builds finish on my machine.
<seb128> StevenK: you don't need to wait for the upload anyway, the buildd will depwait automatically
<StevenK> If I update the build dependancy for the new version ...
<StevenK> My machine just starting building koffice. texlive is one of the next, I bet the buildds have picked up poppler2 by the time I'm done. :-)
<seb128> StevenK: no need to upload tracker, I'm going to ask an UVF for the new version now
<StevenK> seb128: Aye. Should I put my list up so you can eyeball it?
<seb128> Riddell, Hobbsee: what do you think about updating tracker to the new version available? It fixes several bugs and the deskbar plugin has been updated to work with the deskbar-applet API
<Hobbsee> seb128: does that include the performance bug?
<Hobbsee> seb128: as in, there's still *lots* of talk about the current version eating up all available power, when caching
<seb128> Hobbsee: "* Dramatically reduced disk access and disk contention "
<seb128> "* Highly optimised email indexing (up to 5x faster)"
<Hobbsee> seb128: way cool.  Do It.
<seb128> "* Makes use of idle class disk IO scheduling if available"
<Hobbsee> nice
<seb128> Hobbsee: thanks ;)
<Hobbsee> seb128: no problem :)
* mvo wants that
<Hobbsee> mvo: you cant have it!
* RAOF would also like it to not segfault while indexing his emails.
<StevenK> RAOF: That's a feature, not a bug.
<Hobbsee> haha
<Hobbsee> that says you have too much email.
<seb128> StevenK: the list should be something like claws-mail-extra-plugins epdfview gimp pdfcube referencer kdegraphics koffice
<RAOF> Only 100,000 or so.  It should easily be able to handle that :P
<StevenK> seb128: + abiword texlive-bin kbib kde4graphics popplerkit.framework okular evince
<seb128> StevenK: kbib kde4graphics also
* StevenK grins
<seb128> StevenK: evince is dep-waiting on the binaries
<StevenK> Aye, dumping evince.
* StevenK idly wonders if one can remove packages from PPAs now
<soren> seb128: Oh, if you're doing source NEW today, I'd just like to point out that system-config-samba has been approved by motu-uvf for a NPFe.
<seb128> NPF?
<seb128> ah, k
<seb128> gotcha ;)
<soren> :)
* StevenK pushes the koffice build uphill
<dholbach> ajmitch, bhale: can we get mono to build with gda3 instead of gda2?
<dholbach> ^ or some other mono expert
<dholbach> it'd help us get rid of gda2 in main
<Riddell> seb128: got a changelog for tracker?
<seb128> Riddell: Hobbsee already approved it
<dholbach> http://daniel.holba.ch/bugs is back up again
<ajmitch> dholbach: hard to say, the system.data.oledb component apparantly hasn't been getting much love
<ajmitch> I guess it'd be a case of try & see
<dholbach> ajmitch: it'd be very nice :)
<cjwatson> StevenK: can't do redirects at present, AFAIK
<cjwatson> I should probably prod LP folks about that at some point
<seb128> Hobbsee|Remote: why did you subscribe ubuntu-archive to bug #134501?
<ubotu> Launchpad bug 134501 in gmountiso "[UVFe]  gmountiso 0.4" [Undecided,Triaged]  https://launchpad.net/bugs/134501
<ogra> cjwatson, i got to a point where my udeb script finishes fine now with all the in-target stuff .... the bad thing is indeed, if i unset all the debconf vars my real frontend of the script gets unresponsive :(
<cjwatson> I'm sorry, but I'm unlikely to have time to help today
<ogra> ok
<seb128> doko: why did you subscribe ubuntu-archive to bug #124778?
<ubotu> Launchpad bug 124778 in expat "linux grashed" [Undecided,New]  https://launchpad.net/bugs/124778
<doko> seb128: I did wonder myself, why I did get this message, can't remember, typo?
<seb128> doko: dunno, I've unscribed it now
<Le-Chuck_ITA> hi all, I am planning on improve the state of home backup in ubuntu
<mvo> go for it!
<Le-Chuck_ITA> well
<Le-Chuck_ITA> I remember that in edgy we had a problem
<Le-Chuck_ITA> :
<Le-Chuck_ITA> backup was not made "on the fly"
<Le-Chuck_ITA> resulting in impossibility to back up data when disk was almost full
<Le-Chuck_ITA> is this still the case?
<Le-Chuck_ITA> this I mean in the "hubackup" package
<seb128> Mithrandir: is claws-mail in main for mobile?
<Mithrandir> seb128: I wasn't aware it was in main, but it should be there eventually.
<seb128> Mithrandir: well, it's on component-mismatch
<seb128> "   [Reverse-Depends: Rescued from claws-mail, Ubuntu.Gutsy mobile seed, libsylpheed-claws-gtk2-dev] "
<mvo> Le-Chuck_ITA: I don't know, but I think not much has changed since edgy, the package got not a lot of attention
<Mithrandir> seb128: it doesn't have a MIR, does it?
<seb128> Mithrandir: and it's trying to trigger gnome-libs (gnome 1), gtk1.2n glib1.2 to main
<seb128> Mithrandir: doesn't look like no
<Mithrandir> seb128: argh, it wants gtk 1.2? :-/
<seb128> hum
<Le-Chuck_ITA> ok thank you
<seb128> Build-Depends on libgdk-pixbuf-dev
<seb128> that looks wrong
<seb128> Mithrandir: I'm having a look, I think it Build-Depends on that wrongly
<Kopfgeldjaeger> hi
<gnomefreak> is there a reason why updates want to access external disk (thats not external) this is bothering me
<soren> updates? external disks that are not external? what?
<gnomefreak> its root partition its trying to access as external
<soren> I have no clue what that means.
<soren> Whose root partition? What does it mean to access something "as external"?
<gnomefreak> soren: during updates it prompts for root password to access root partition
<gnomefreak> but yes after give password it shows up as disk on desktop (like external drive would
<gnomefreak> its hal thats doing it
<soren> soren: Ok, so when you're running update-manager, you're asked for your password... What makes you think it's "to access root partition"?
<gnomefreak> soren: because when you give the password it shows up on desktop if i open it it has bin, var, ect.... dirs
<mvo> gnomefreak: so when you run update-manager and install updates with it it does mount some of your dirs? is that the questions/concern?
<gnomefreak> you dont seem to need to do it as i didnt do it this time but i did yesterday and its still shouldnt ask you to do that. i do believe (will hav eto wait for next hal update) its says external drive
<gnomefreak> mvo: dist-upgrade
<gnomefreak> i dont use update-manager too often as i always have a load on the pc from building/uploading/ect
<mvo> gnomefreak: in dist-upgrade mode it accesses some dirs to compute the size that the upgrade will take
<gnomefreak> Setting up libhal-storage-dev (0.5.9.1-1ubuntu6) ...
<gnomefreak> Setting up hal (0.5.9.1-1ubuntu6) ... * Reloading system message bus config...                                [ OK ]   * Starting Hardware abstraction layer hald
<gnomefreak> that is when i get the dialog
<mvo> oh, I see. that sounds like a issue with the hal package then
<mvo> update-manager/apt-get/etc are just the messanger than :)
<gnomefreak> yep
<gnomefreak> i dont know who is the hal guy or i would have went to him/her directly
<gnomefreak> but being sick i cant be here as often either
<mvo> pitti would be a good candidate, but he is currently on vacation
<gnomefreak> ok ill ping him next week than maybe ill be feeling better than
<gnomefreak> ty mvo
<mvo> gnomefreak: get well!
<soren> gnomefreak: Could you throw the output of lshal on pastebin?
<soren> gnomefreak: Or even better:
<soren> gnomefreak: File a bug and attach it?
<seb128> soren: what is the issue?
<gnomefreak> soren: yes but it is gonna have to wait
<gnomefreak> seb128: hal update asks to access root partition and prompts for password and disk shows up in desktop
<soren> seb128: I'm not entirely sure :) Something about hal making stuff show up on gnomefreak's desktop.
<soren> gnomefreak: "asks to access root partition"? What's the exact question it asks?
<seb128> I think it's something like hal or dbus restarted
<gnomefreak> hal update prompts for root password to access disk (IMHO not good)
<seb128> that looks like gnome-mount asking permission to mount a driver which is not listed if fstab for the user
<seb128> s/driver/drive
<jamiemcc> seb128: is tribe 6 frozen or is there time to squeeze in latest tracker 0.6.2?
<seb128> jamiemcc: the 0.6.2 exception has been accepted, I'm looking at the update
<jamiemcc> ok great
<seb128> soren: "sudo invoke-rc.d hal restart" to simulate the bug
<gnomefreak> seb128: running that will do the same as the update did?
<seb128> soren: when hal restart it looks like GNOME get events like if the drives where just connected
<Amaranth> jamiemcc: what is new in 0.6.2?
<Amaranth> jamiemcc: and are the io issues sorted out?
<jamiemcc> amaranth: hopefully
<soren> seb128: Not on my system it doesn't..
<seb128> gnomefreak: no, the upgrade should not restart hal, I'm not sure why it did
<gnomefreak> yep it does
<jamiemcc> my testing shows its much more reliable with io
<gnomefreak> seb128: not sure either
<seb128> soren: do you have other partitions not in fstab?
<Amaranth> i _always_ notice when tracker is doing something now but luckily it finishes so fast it's almost never annoying
<jamiemcc> amaranth: we have smoothed over io issues quite a bit and it now pauses when it detects external disk access outside
<Amaranth> neat
<gnomefreak> ok i really need to get more painkillers in me and laydown, ty for looking at that seb128
<jamiemcc> amaranth: full changes here: http://mail.gnome.org/archives/tracker-list/2007-September/msg00012.html
<seb128> gnomefreak: you're welcome
<Amaranth> jamiemcc: yay, even more "i'm compiling, go away" stuff :)
<jamiemcc> amaranth: yeah although there may be corner cases where it does not work well - we need trivbe 6 exposure to find out
<Amaranth> "This version will cause your hard drive to be re-indexed due to the new sqlite indexer backend"
* Amaranth weeps
<soren> seb128: Er... Mounted ones?
<seb128> soren: no, not mounted ones
<Amaranth> that's 60GB of code, video, audio, etc
<jamiemcc> amaranth: so long as code or text files < 10gb you should be ok
<Amaranth> they are
<seb128> soren: the computer place lists all the available partitions, and you can mount them by double clicking, gnome-mount does the job and will ask the sudo password if required
<Amaranth> and i suppose it should have a problem racing through flac files
<seb128> soren: likely if you have a windows partition not in fstab you should be able to mount it this way
<Amaranth> err, shouldn't
<jamiemcc> amaranth: providing gstreamer can extract metadata from them no
<Amaranth> if it couldn't rhythmbox would look weird :)
<soren> seb128: I don't. I have a dm-crypt'ed partition, but hal won't know about that.
<seb128> soren: ok, that's why restarting hal does nothing for you ;)
<soren> seb128: But gnomefreak's problem was that his root partition showed up like this as well, right?
<ogra> soren, the dm-crypt code in hal isnt used ? i know upstream added stuff for that
<soren> ogra: By design, it won't be able to recognize it.
<soren> ogra: dm-crypt'ed block devices don't have an identifying superblock.
<ogra> soren, there is a hal handler for encrypted partitions afaik
<ogra> that should automatically ask for a pw and the like
<soren> ogra: Possibly, but it can't recognize a them by looking at them.
<soren> ogra: You may be thinking of LUKS partitions?
<ogra> but might be that pitti disabled it
<ogra> oh, right, i mixed that up
<seb128> soren: I'm not sure the description is accurate, anyway the bug there is that hal should not been restarted on upgrade
<ogra> indeed, it was LUKS
<soren> ogra: Ah, ok.
<soren> ogra: That makes more sense. That's (AFAIK) basically dm-crypt+superblock.
<Mithrandir> soren: uh, yes and no.  LUKS typically uses dm-crypt.
<soren> Mithrandir: Did I say differently?
<Mithrandir> soren: you were just slightly confusing when you said dm-crypted block devices don't have a superblock, while they can have, but they don't need to have.
* Starting logfile irclogs/ubuntu-devel.log
<ScottK> seb128: If you have a moment, would you please relook at Bug #131776 as it appears there was some confusion about what package was being asked for (I hope the comment I just added clarifies it).
<ubotu> Launchpad bug 131776 in feisty-backports "please backport xserver-xorg-video-openchrome" [Wishlist,In progress]  https://launchpad.net/bugs/131776
<ogra> heh
<seb128> ScottK: looking
<ScottK> Thanks.
<seb128> ScottK: ah, right, I read the bug description and it mentions the wrong package
<seb128> ScottK: will fix it now
<ScottK> Thanks.
<ogra> ScottK, the thing is that many via boards run with all three (via, uni- and openchrome)
<ogra> but only one of them will support certain features of the device
<ogra> the via drier situation is a big bad mess
<ogra> *driver
<seb128> ScottK: fixed, could you try to include the versions in backport requests though?
* ScottK works hard to not have to worry about it by using Intel motherboards.
<seb128> ScottK: you did in the new comment but not before
<ScottK> seb128: Yes.  I usually make sure that's there.  I slipped up on that one.
<soren>  /win 21
<soren> ...
<AlinuxOS> Hello asac, is there some news with this bug: https://bugs.launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/+bug/88677
<ubotu> Launchpad bug 88677 in mozilla-firefox-locale-all "Georgian Language support." [Undecided,Confirmed] 
<kwwii> seb128: here is the source package for human icon theme
<kwwii> http://sinecera.de/human-icon-theme_0.21ubuntu1.tar.gz
<kwwii> http://sinecera.de/human-icon-theme_0.21ubuntu1.dsc
<kwwii> http://sinecera.de/human-icon-theme_0.21ubuntu1_source.build
<kwwii> http://sinecera.de/human-icon-theme_0.21ubuntu1_source.changes
<StevenK> Neeeeeeeeeat.
<StevenK> liquified kernel: [1567134.553120]  journal commit I/O error
<dholbach> kwwii: if you could rename it to 22, I'd upload it
<StevenK> seb128: Just about to upload the seven packages that built, plus koffice for the poppler rebuilds.
<seb128> StevenK: cool, thanks
<StevenK> seb128: koffice failed here after 2 and a half hours due to an I/O error, during the final dh_install, so I'm reasonably certain it will deal.
<StevenK> Riddell: You about?
<Riddell> hi StevenK
<StevenK> Riddell: Hey, I'm looking to upload kdegraphics and koffice, but both of them didn't have the DebianMaintainerSpec stuff set, and I wasn't sure if you'd prefer the KDE packages not set to core-dev.
<dholbach> kwwii: reviewing it
<Riddell> go ahead and fix that StevenK
* kwwii hugs dholbach 
<StevenK> Riddell: Will do, thanks
<dholbach> kwwii: did you also push your changes to the branch?
<kwwii> dholbach: no, should I do that now? wanted to wait to hear your opinion
<dholbach> kwwii: feisty -> gutsy
<dholbach> kwwii: hum, I see no changes to 0.21 apart from the changelog
<kwwii> dholbach: nope, there should not be any...I just took the stuff you updated and built the package :-)
<kwwii> I assumed that nobody had done that yet
<kwwii> dholbach: sorry if I was wasting your time :-(
<dholbach> kwwii: ok, I'll upload it
<dholbach> kwwii: for some reason it did not hit the buildds
<dholbach> maybe I just forgot to upload it (???)
<dholbach> anyway, uploading now
<dholbach> kwwii: can you push it to bzr?
<kwwii> dholbach: yes, but I should change feisty to gutsy in the changelog, right?
<dholbach> (with the change from feisty to gutsy please)
<dholbach> yeah
<dholbach> thanks kwwii
<kwwii> dholbach: commited, thanks to you for the help :-)
<dholbach> thank YOU :)
<Skiessi> committed what?
<Skiessi> :o
<dholbach> Skiessi: changes to human-icon-theme bzr
<Skiessi> ok :)
<soren> seb128: Do you think you will have time to look at system-config-samba today?
<seb128> soren: what is this thing?
<soren> seb128: It's in the NEW queue.
<seb128> soren: looking right now
* soren hugs seb128 
* seb128 hugs soren back
<xhaker> Hi. Anyone here willing to help remove a bashism in a package?
<xhaker> http://pastebin.com/m2e824844
<seb128> soren: looks good, one small question, why do you include the cdbs dpatch rule and also dpatch.make?
<soren> seb128: Probably because I'm an idiot.
<soren> seb128: :)
<seb128> ;)
<dholbach> seb128 sees everything
<cjwatson> xhaker: cp "$$(printf %s "$$f" | sed 's/$(SOVERSION)//')" "$$f"
<soren> seb128: I can't remember. I packaged it months ago and only this friday got upstream to include the GPL in the tarball so it's just been lying around waiting to get uploaded.
<cjwatson> xhaker: or, if $(SOVERSION) is guaranteed to be at the end of $f:
<cjwatson> xhaker: cp "$${f%$(SOVERSION)}" "$$f"
<soren> seb128: I've got anoter patch for it I want to upload real soon anyway. I'll take care of it then.
<seb128> soren: accepted
* soren hugs seb128 frantically
<seb128> ;)
<xhaker> thanks cjwatson, will try. many thanks, really.
<seb128> jamiemcc: tracker is still not really nice, it creates a load around 3 on my gutsy
<jamiemcc> seb128: laod?
<seb128> which makes applications laggy, etc
<seb128> the number you have in top
<jamiemcc> iowait state
<seb128> "load average"
<jamiemcc> it should be niced though
<jamiemcc> io wait states can make apps that access the disk laggy
<jamiemcc> run vmstat 1
<seb128> jamiemcc: the io bi is pretty low (between 0 and 300) and bo goes between 1000 and 9000
<jamiemcc> the wa figure at end is most important
<seb128> 99
<seb128> 99
<seb128> 96
<jamiemcc> ouch
<seb128> etc
<jamiemcc> yes we aim for less than 90
<jamiemcc> what else is accessing the disk?
<seb128> nothing I think
<seb128> or nothing with heavy access
<seb128> I've web browsers, xchat, evolution open
<seb128> but there are not doing anything special
<jamiemcc> se128: is that wa figure continuing?
<jamiemcc> to be above 90?
<f0rqu3> http://-kol.deviantart.com/ I cant open this website on ubuntu
<seb128> jamiemcc: no, but it goes often between 96 and 100 and that's when the system is laggy
<seb128> jamiemcc: like it's ok for 10 seconds and then lag for some seconds, then it's ok, again, etc
<seb128> and when it's laggy even typing on IRC is frozen
<jamiemcc> seb128: how big is your home/.cache/tracker
<seb128> 401M at the moment
<seb128> it's the first indexing
<jamiemcc> yeah mine is about that too and I dont have any issues
<seb128> I removed tracker from this box previous because I can't work with this lag
<jamiemcc> im on feisty 2.6.15 kernel though
<seb128> just giving a try to the new version
<StevenK> Feisty ought to 2.6.20 ...
<jamiemcc> seb128: I can make it write to disk more often in smaller chunks to reduce latency
<jamiemcc> assuming its not a kernel issue
<seb128> jamiemcc: well, not sure what is creating the issue, could be the kernel
<f0rqu3> ???
<seb128> but that's not really nice from an user point of view
<jamiemcc> seb128: I will play with it on gutsy and see what  can do
<seb128> thanks
<seb128> jamiemcc: other thing, the search tool was supposed to indicate that indexing was still running, no?
<seb128> that doesn't seem to be the case
<jamiemcc> seb128: yeah we plan on having an applet/notification icon to do that
<jamiemcc> we have one submitted but its not stable yet
<jamiemcc> will be ready for gutsy beta
<seb128> ok, cool
<pedro_> jamiemcc: is there any news related to not indexing while running on battery?
<jamiemcc> pedro_: thats coming with the applet
<seb128> I though the tracker-search-tools had a "still indexing" indication
<seb128> beagle does that I think
<jamiemcc> seb128: yeah we can add that - not hard
<pedro_> seb128: yes it does
<Mithrandir> also, turning off indexing should kill trackerd.
<jamiemcc> seb128: it shopuld be possible for us to read the iowait figures on linux and throttle back if necessary
<bddebian> Heya
<bddebian> seb128: Thanks for the syncs!
<seb128> bddebian: you're welcome
<superm1> seb128, i subscribed ubuntu archive to bug 134726 because you told to last week.  I'm just waiting on an archive admin to release the uploads into -proposed per the SRU process.
<ubotu> Launchpad bug 134726 in mythtv "MythTV 0.20.2 SRU " [High,In progress]  https://launchpad.net/bugs/134726
<seb128> superm1: did I?
<superm1> Yes
<seb128> superm1: k, maybe I didn't connect what you asked and the bug
<seb128> I've to admit that the one page describe doesn't make me want to read it to understand what is to do
<superm1> :)
<superm1> Aug 29 08:42:03 <seb128>        superm1_: I looked at ubuntu-archive bugs this morning and there was nothing about that
<superm1> Aug 29 08:42:41 <superm1_>      seb128, previously Riddell had just acked it without looking for a bug about it, so it wasn't apparent that i needed to file a bug to make it happen.
<superm1> Aug 29 08:43:21 <seb128>        superm1_: well, pings on IRC don't scale
<superm1> Aug 29 08:43:30 <seb128>        superm1_: that's not a replacement for a bug ;)
<seb128> k
<seb128> shouldn't the SRU be approved by ubuntu-sru?
<superm1> its a universe SRU
<Hobbsee> dont think the team exist anymore
<seb128> Hobbsee: https://launchpad.net/~ubuntu-sru
<superm1> the current MOTU sru process just requires that "After the upload, archive administrators should then verify that the version number of the upload is sane and accept the package into -proposed. They set the bug status to Fix committed." per  https://wiki.ubuntu.com/MOTU/SRU
<ScottK> It doesn't.  It's 2 it works inputs on the bug and 7 days aging and any MOTU can mark it motu-verification-done.
<Hobbsee> seb128: for MOTU
<seb128> Hobbsee: https://wiki.ubuntu.com/MOTU/SRU doesn't make clear what team should approve it
<Hobbsee> seb128: dont look at me, i avoid them :)
<superm1> this is exactly why I wanted to bring this up for discussion at the upcoming MOTU meeting this weekend :)
<StevenK> ScottK, seb128, Hobbsee: Currently test building gimp 2.4.0~rc2
<seb128> StevenK: rock on ;)
<seb128> superm1: that would be a good idea, because I'm not comfortable to let anybody upload SRUs without requiring any approval
<superm1> seb128, my understanding is that any MOTU can do the SRU, and the role for the archive admin is to just check the version number is good and let it into proposed, and then we have our other verifications steps
<seb128> and we usually don't accept new version to stable and use backports for that
<seb128> well, I'm not sure I'm willing to accept a new version as SRU
<superm1> well Riddell already accepted the first proposed variant to -proposed.  this is just to make up for an issue that was discovered upstream with the new version and affects a few people
<seb128> " 226 files changed, 14006 insertions(+), 6391 deletions(-)"
<seb128> that's scary for a SRU
<StevenK> Uh, agreed.
<iwj> This damn drive has been blanking this disc at `speed 4' for about 25 minutes.
<superm1> those debdiffs on the bug are against the version currently in universe.  the changes between these two proposed versions aren't more than 3 dpatches that get applied during build
<seb128> superm1: well, I'm discussing whether accepting the first upload was right
<superm1> well i did consult with the technical board
<seb128> that is not mentioned in the bug
<superm1> and mdz's end response was "This update has my ack in principle (the problem is severe enough to justify
<superm1> the risk of an update); a decision on the actual package updates themselves
<superm1> (the implementation of the fix) remains with the SRU team." (This was before the packages were fully prepared)
<StevenK> Awww. Gimp doesn't do the fun "checking for intelligent life ... none found" in its configure any more
<azeem> does Martin Owens IRC?
<seb128> azeem: no idea, dholbach ^ ?
<bddebian> StevenK: Maybe it just never found any so it gave up? :-)
<superm1> seb128, I can bounce the mail thread to ubuntu-archive ML if you'd like, since mdz didn't actually comment on the bug after he responded to me
<azeem> he sure seemed grumpy on debian-devel-discuss
<StevenK> bddebian: :-)
<seb128> superm1: no that's ok
<azeem> seb128: is ubuntu-desktop taking care of conduit?
<dholbach> azeem, dholbach: no idea - sorry
<azeem> ok
<seb128> superm1: uploads approved to proposed for edgy and feisty now
<azeem> that conduit dude was talking in #opensync a while ago, I'll catch him next time I'll see him
<superm1> thanks seb128 :)
<seb128> azeem: no, any voluntar is welcome, I can sponsor uploads ;)
<azeem> seems a conduit package is in gutsy
<dholbach> azeem: is it http://launchpad.net/~doctormo you're talking about?
<seb128> it's from debian
<azeem> ah, right
<azeem> dholbach: yeah, I guess
<dholbach> azeem: so it should be doctormo on freenode
<azeem> yeah, but he's not in here
<azeem> ok, thanks
<azeem> should've actually figured that out myself, sorry
<dholbach> no problem :)
<dholbach> azeem: he's on  #Perl #ubuntu-massachusetts @#dohickey #inkscape #ubuntu-us #ubuntu
<seb128> superm1: mythbuntu-control-centre also accepted
<superm1_> seb128, thx, was waiting on that one, but didn't want to badger :)
<StevenK> Hum. Where is $XDG_APPS_DIR supposed to be set?
<seb128> superm1_: mythbuntu-meta also accepted
<seb128> StevenK: nowhere?
<StevenK> seb128: % head -n 24 okular/shell/CMakeLists.txt | tail -n 1
<StevenK> install( FILES okular.desktop  DESTINATION  ${XDG_APPS_DIR} )
<seb128> StevenK: http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
<seb128> StevenK: those are the spec-ed variables
<seb128> StevenK: XDG_APPS_DIR seems to be a KDE thing
<seb128> maybe Riddell knows about it
<StevenK> This thing has cmake and Hobbsee all over it, so agreed.
<Hobbsee> wha?
* Hobbsee is not all over anything
<seb128> Hobbsee: oh yes, you are
<Hobbsee> seb128: like what?
<seb128> Hobbsee: all over kubuntu ;)
<Hobbsee> seb128: oh.  right.  only if it's going well.  if it's not, then it's all Riddell's fault.
<seb128> :)
<StevenK> Hrm. Yay for poppler API changes.
<seb128> StevenK: they didn't change the soname for nothing ;)
<StevenK> Heh
<StevenK> seb128: I wonder if poppler have a lovely API web page like the libquicktime guys do.
<seb128> ogra: should edubuntu-addon-meta be in main or universe?
<ogra> main
<ogra> need to seed that on server-addon
<seb128> ogra: can you seed it? ;)
<seb128> thanks
<seb128> ogra: BTW new gnome-power-manager to package
<seb128> StevenK: you can use devhelp to search the API
<ogra> yup, will do both today
<seb128> dholbach, kwwii: human-cursors-theme wants to go to universe, is that normal?
<StevenK> seb128: Grmh? Can I have a little more of a hint?
<dholbach> seb128: yes, we use dmz-cursor-theme now
<seb128> StevenK: about what? you know devhelp?
<StevenK> seb128: Nope, which is why I want a little more of a hint. :-)
<seb128> StevenK: apt-get install devhelp
<seb128> StevenK: it's a documentation, API browser
<seb128> you have the index on the left and can search for function names
<StevenK> Ah
<seb128> all the GNOME API are indexed there
<seb128> anything using gtk-doc
<seb128> dholbach: thanks
<tkamppeter> doko, ping
<seb128> BenC: is kexec-tools needed to main? If that's the case could you seed it or make something in main (Build-)Depends on it? Because it wants to go to universe at the moment
<doko> tkamppeter: pong
<Riddell> StevenK: is that kde4graphics?
<StevenK> Riddell: Nope, okular
<geser> Can an archive admin move ion3-mod-xinerama from universe to multiverse (where ion3 is already). Thanks.
<StevenK> ScottK, seb128: gimp uploading to my PPA
<soren> cjwatson: I'm looking at the seeds and noticed some "Task-Key: " stuff.. I can't find it documented anywhere and looking at the germinate source didn't help me much. Am I looking in the wrong places, or is it just not documented?
<Riddell> StevenK: right, well that variable should be set by the cmake include files, what's the actual problem?
<seb128> StevenK: why not to Ubuntu? ;)
<StevenK> seb128: Because I want more people than me to test it. :-)
<ScottK> StevenK: I have to retract my testing offer.  The latest libhal (I'm pretty sure) did away with the cooling fan on my Gutsy install so it won't run for more than a few minutes other than at complete idle.
<StevenK> Riddell: It looks to not be set, since the build bombs:
<StevenK> /build/steven/okular-0.5.82/okular/shell/CMakeLists.txt:24:
<StevenK> INSTALL FILES given no DESTINATION!
<StevenK> ScottK: So noted.
<seb128> Riddell: do you know why adept and debtags stopped Build-Depending on libtagcoll?
<bddebian> cmake.. w00t love it!
<dholbach> mvo: if I use python-apt for finding out if a package is in main or universe: is sources.Index.ArchiveURI or sources.Files my best bet?
<Riddell> StevenK: it's probably in an old syntax for cmake, that's quite an old snapshot, I'll ask them when they plan to release a new one, in the mean time just ignore okular (and kde4graphics if you want, that has a new snapshot coming this week)
<BenC> seb128: yeah, it should move to main
<Riddell> seb128: not off hand, that tangle of dependencies always confuses me, what's the problem?
<enrico> seb128: they now depend on libtagcoll2
<enrico> seb128: and on libept
<seb128> BenC: it is to main and wants to go to universe, could you sed or make something use it? ;)
<StevenK> Riddell: I shall ignore okular, kde4graphics built fine and was uploaded.
<seb128> s/sed/seed
<seb128> Riddell: it's to main and wants to go to universe, you wrote the MIR so I'm asking if it's still needed or can be demoted
<seb128> enrico: there is no libtagcoll2 in gutsy
<BenC> seb128: I can make the linux-image-debug depend on it
<seb128> BenC: thanks ;) There is no hurry, whenever you do the next upload is fine (I'm just trying to clean component-mismatches.txt)
<enrico> seb128: then you can't build libept, debtags adn adept
<Riddell> seb128: that should be fine to demote, they use libtagcoll2-dev now
<soren> cjwatson: Ah... I think I've got it.
<seb128> Riddell: thanks
<Riddell> which is in gutsy
<seb128> Binary: tagcoll, libtagcoll2-dev
<seb128> right
<soren> cjwatson: Yes, got it. Never mind.
<cjwatson> soren: you should be looking in tasksel for that. documentation, uh, RTFS? ;-)
<xhaker> Hey, it seems the next ATi proprietary driver will have support for AIGLX
<seb128> calc: are you going to make openoffice use libsvg libvigraimpex libwpg?
<xhaker> article at: http://www.phoronix.com/scan.php?page=article&item=821&num=1
<seb128> calc: they are to main but want to go to universe since nothing use it at the moment
<thom> in other news, silicon valley's airspace has just been entered by a squadron of pink porcine creatures doing mach 2
<jwendell> doesn't Ubuntu have libiconv??
<\sh> going home...end of business todayx
<jwendell> ah libc6 :)
<soren> cjwatson: Yeah, it was the "look in tasksel" bit that I was missing. :) Never having looked at a tasksel description before, I didn't recognize anything.
<soren> cjwatson: I have a problem with it, though.
<soren> cjwatson: I want to add several Key packages.
<soren> cjwatson: If I add several "Task-Key: foo" lines, the ubuntu-seeds.pl script lists the last one three times.
<mthaddon> anyone able to help me with a gutsy upgrade - bug 137539
<ubotu> Launchpad bug 137539 in update-manager "update-manage incorrectly reports free disk space" [Undecided,New]  https://launchpad.net/bugs/137539
<cjwatson> soren: meeting, will get back to yo
<soren> cjwatson: like so: http://pastebin.ca/682409
<soren> cjwatson: Ah, sorry.
<Hobbsee> bug #134501
<ubotu> Launchpad bug 134501 in gmountiso "[UVFe]  gmountiso 0.4" [Undecided,Triaged]  https://launchpad.net/bugs/134501
<Hobbsee> seb128: er, pebkac error.
<seb128> Hobbsee: what I figured ;)
<Hobbsee> seb128: looks like i thought it was already in debian
<Hobbsee> not that they've actually mentioned where the file in question is at all
<seb128> Hobbsee: I've unsubscribed ubuntu-archive
<calc> seb128: yes already using them in my current build, the current build has another set of problems so hasn't been uploaded yet
<Hobbsee> seb128: thanks
<calc> seb128: they just got put into main in the past couple days
<soren> cjwatson: Never mind. :)
<cjwatson> soren: I think you can comma-separate
<tkamppeter> doko, still there?
<doko> tkamppeter: did pong 1min after your ping ;)
<tkamppeter> doko, it is about bug 130842
<ubotu> Launchpad bug 130842 in ghostscript "[ia64]  ps2pdf crashes on ia64, causing several build failures" [High,Incomplete]  https://launchpad.net/bugs/130842
<soren> cjwatson: Yes, exactly.
<tkamppeter> doko, I can only report it upstream if I have a file with which I can reproduce it. See my last comment on the bug report.
<doko> tkamppeter: I requeued it, lets see if it builds
<tkamppeter> doko, OK. Were there very many packages not building due to this?
<soren> seb128: If you have time to look at the system-config-samba binary package today, that would be much appreciated, too.
<stgraber> asac: saw what I said yesterday at 20:25 ?
<asac> stgraber: what kind of question :)
<asac> stgraber: what did you say (sorry had to restart irssi so my scrollback is gone)
<stgraber> 20:25 < stgraber> asac: result is that I have that deassociation problem only when moving back to Wired from Public
<stgraber> 20:25 < stgraber> asac: and when I have the AP_SCAN 0 timeout thing
<seb128> soren: binary accepted
<asac> stgraber: yes ... do you know the place in code where i do that?
<asac> stgraber: can you remove everything but the TERMINATE ? (e.g. DISABLE_NETWORK, AP_SCAN 0) ?
<asac> and try if it helps?
<stgraber> yep
<asac> grep for TERMINATE in the patches to find the exact place
<soren> seb128: woo!
* soren hugs seb128 
* seb128 hugs soren back
<stgraber> asac: I'm pretty sure I'll break 41u if I edit 41q ...
<asac> stgraber: just outcomment ... should be easier in terms of no conflicts
<asac> (outcomment source in patch with // i mean)
<stgraber> k
<stgraber> DISABLE_NETWORK is in NM code itself (not one of our patch), I'm trying to disable the AP_SCAN 0 part and test with that
<doko> tkamppeter: did you my msg?
<asac> stgraber: he?
<asac> stgraber: i added DISABLE_NETWORK
<stgraber> oh, really ? :)
<asac> stgraber: maybe its in another patch
<stgraber> so it isn't in the patch I'm currently reading
<mvo> mthaddon: let me look at the update-manager issue
<mthaddon> mvo, thx
<tkamppeter> doko, which msg? The last one here on IRC was that you are requeuing the build of the package.
<stgraber> (a good idea once those issues will be fixed would be to do a wpa_supplicant_hack.patch and ipw3945_hack.patch to replace all those small patches :))
<mvo> mthaddon: could you please attach the content of /proc/mounts and the file /var/log/dist-upgrade/main.log to the bugreport?
<mthaddon> mvo, sure will do
<doko> tkamppeter: now?
<Hobbsee> mvo: have you seen https://launchpad.net/bugs/137546, incidently?
<ubotu> Launchpad bug 137546 in app-install-data-commercial "[Gutsy]  traceback while updating to 8.2" [Undecided,New] 
<Chipzz> asac: ping
<cjwatson> doko: hmm, upgrading libgtk2-perl to the current upstream version doesn't seem to help much. will need to dig some more
* ogra dances 
<mvo> Hobbsee: oh, no. thanks
<mthaddon> mvo, ok, that's done
<doko> cjwatson: hmm, that was just what I did read from their page :-/
<cjwatson> in fact, 1.146 fails (er, unexpectedly succeeds) one *more* test than 1.140
<cjwatson> yeah, I saw that in the release notes too
<cjwatson> it looks like we do need the current version due to GSlice changes in pango
* cjwatson dusts off his four-year-old XS experience
* Hobbsee watches cjwatson drown in all the dust
<bddebian> heh
<cjwatson> hey, I made XS work with an entirely custom C++ standard library replacement, it was pretty hot :)
<cjwatson> albeit evil beyond belief
<Hobbsee> hah
<thom> reimplimenting mod_perl in zeus was *never* hot ;)
<cjwatson> http://support.zeus.com/zws/examples/2005/12/16/perl_extensions_introduction
<cjwatson> thom: so was
<cjwatson> ok, the proprietary kind of hot, BUT STILL
<thom> when you're standing at the pearly gates, whatshisface will be weighing up good and evil. and then he'll come to that, and cast you straight down.
<thom> :)
<bddebian> hah
<Hobbsee> cjwatson: dont even *try* to validate your temporaral smoking of the crack pipe :P
<Hobbsee> it wont work.
<calc> lol
<mvo> mthaddon: hm, looking at the figure it does not look entirely implausible. it requires to download 1,6G of deb packages (that is quite a lot but not impossible much) and an additional 900mb of hardspace on / will be used. the free space on "/" may just be a little bit too small
<mthaddon> mvo, oh, so when it says it needs 900 free, it, actually needs 900 + 1.6 GB?
<mthaddon> mvo, if so, I can try freeing up some extra space
<mvo> mthaddon: aha, I see. I think the message is just misleading :/
<mthaddon> mvo, yeah, seems a little misleading, but will free up the space and I'm sure it'll be fine - thx
<mvo> mthaddon: what is the exact message? could you paste it please (word for word)? it maybe that the size is displayed incorrectly in the message
<mthaddon> mvo, will run it again and take a screenshot and attach it to the bug
<mvo> mthaddon: i.e. that it does not sum up the space required for the deb package and the additonal space on the HD in the message so that people get confused
<mvo> mthaddon: that is great, thanks a lot!
<mathiaz> mvo: I've tried to use update-manager-core to upgrade a feisty server to gutsy.
<asac> Chipzz: ?
<tkamppeter> doko, are you still there?
<asac> Chipzz: ipw2200 right?
<mathiaz> mvo: I was using the do-release-upgrade command. Is this the correct one ?
<mathiaz> mvo: because it failed with an error message saying no dist found in the meta file (or something like that).
<mvo> mathiaz: yes, please run it with "-d" to get the current development release. if it fails, please file a bug and include /var/log/dist-upgrade/main.log
<mvo> mathiaz: and notify me on irc :) today seems to be the release-upgrade day for some reason :)
<mathiaz> mvo: ok. I'll try again.
<mvo> mathiaz: thanks!
<asac> siretart: ping?
<Chipzz> asac: yes
<Chipzz> asac: so anyway, no networkmanager either... not a big fan of it
<asac> Chipzz: well ... lets start then
<asac> Chipzz: it associates automatically for you?
<asac> Chipzz: how do you trigger this? when do you see it?
<Chipzz> asac: sorry if I respond tardily, crappy wireless
<Chipzz> asac: not really reproducible, but it occurs sometimes, not every time, when the network it is supposed to be asociating with is not "in reach"
<Chipzz> ie, too bad (to nil) reception
<Chipzz> and
<asac> Chipzz: sorry please rephrase ;)
<stgraber> asac: http://paste.stgraber.org/3400
<stgraber> asac: will be back in 15min or so
<asac> stgraber: so you managed to go back to eth0 ?
<Chipzz> I think when I rmmod and modprobe the module
<Chipzz> asac: currently, the network I'm trying to associate with sometimes has bad reception here
<Chipzz> when the reception drops below a certain point, ie when iwlist would not show it (I *think*)
<asac> stgraber: can you confirm that the TERMINATE works well when you try to reconnect to wireless device (e.g. two times in a row)
<Chipzz> *iwlist scan
<cjwatson> doko: ahh, I think I may have been using the wrong branch
<cjwatson> (libgtk2-perl)
<ogra> cjwatson, got it all working now, i was simply looking at a way to low level, blindly not noticing that deboootstrap already had a frontend problem (it could be a bit noisier though) i tried to fix it in the chrooted apt-get calls ... using debconf vars at the very top level helps a lot :)
<cjwatson> ogra: ah, right, good stuff
<asac> Chipzz: 1. you modprobe your module ... is it (auto-)associating right after that?
<ogra> debootstrap cheats me every time though ... last time it took me as well two days to find that it failed there ... it should really throw a lod error :)
<ogra> *loud
<sbalneav> dendrobates: Hey, any idea where I can follow the status of what the auth-server team is developing?
<Chipzz> asac: more like 1) reception drops below certain point, so to fix it I 2) rmmod the module, and 3) I modprobe it. And it auto-associates right after that (but only sometimes)
<asac> oh
<Chipzz> asac: btw, this is plain and simple WEP, no WPA or anything
<asac> how do you manage your connections?
<Chipzz> I have a set of configurations in /e/n/i which I comment in/out according to needs
<mvo> mthaddon: ok, I think I know what causes this incorrect message, thanks for reporting!
<Chipzz> if that's why you mean
<mthaddon> mvo, cool
<Chipzz> and ifup/ifdown
<Chipzz> asac: AFK for a bit
<stgraber> asac: it works yes
<stgraber> asac: it's causing two problems when switching from Public to Wired, first it doesn't deassociate (which is a problem with the ipw3945 driver), second it takes some seconds to actually start connecting to wired (and then some users may think that they didn't correctly clicked on wired and click a second time ...)
<stgraber> asac: switching between wireless (public and WPA) work fine, switching between WPA and Wired too
<asac> stgraber: are we sure that the driver gets told to deassociate?
<asac> do you see thate deassoc debug output in driver log?
<asac> stgraber:                         IPW_DEBUG_ASSOC
<asac>                             ("Deassociating because OFF/ANY set with auto association"
<asac>                                 " disabled.\n");
<Chipzz> asac: back
<asac> Chipzz: is a bit strange .... the driver probably doesn't remember any previous association attempt
<asac> you sure it doesn't happen after loading the module for the first time?
<stgraber> asac: http://www.stgraber.org/download/nm-debug-wpa
<asac> Chipzz: try echo 65535 > /proc/net/ipw/debug_level ... and see if you get debug messages from driver
<Chipzz> asac: not sure
<stgraber> asac: I just had the same issue while switching from WPA to Public
<Chipzz> asac: I just had it happen a couple of moments ago
<stgraber> asac: and then no issue when switching from Public to Wired
<stgraber> asac: so it seems to appear randomly (I hate that)
<stgraber> asac: look at 18:38:48
<Chipzz> # echo 65535 > /proc/net/ipw/debug_level
<Chipzz> -su: /proc/net/ipw/debug_level: No such file or directory
<stgraber> Chipzz: /sys/bus/pci/drivers/ipw3945/debug_level
<asac> stgraber: you see any pattern in kernel log? .e.g. what happens when it blocks ... what doesn't happen when it does?
<asac> stgraber: he has ipw2200
<stgraber> oh
<asac> stgraber: i took this out of code ... might be wrong place though
<asac> Chipzz: try to find it ... should be somewhere
<Chipzz> # find /proc -name "*ipw*"
<Chipzz> /proc/irq/7/ipw2200
<Chipzz> # find /sys -name "*ipw*"
<Chipzz> /sys/module/ipw2200
<Chipzz> /sys/module/ipw2200/drivers/pci:ipw2200
<Chipzz> /sys/module/ieee80211/holders/ipw2200
<Chipzz> /sys/bus/pci/drivers/ipw2200
<Chipzz> any of the sys ones?
<asac> /sys/bus/pci/drivers/ipw2200/debug_level ?
<Chipzz> yeah google just told me that ;)
<stgraber> asac: looking at the log, it seems that the driver simply doesn't receive the TERMINATE, it doesn't even try to deassociate
<asac> yeah ... what wpasupplicant are you using?
<asac> stgraber: i am sure its something blocking wpasupplicant
<asac> stgraber: i think that its blocked in some other operation and thus can't exit the eloop in time (12 seconds)
<Chipzz> asac: aha, I just reproduced it
<Chipzz> and dumped dmesg to a log
<asac> stgraber: can you try to boost that time to ridiculous 30 or 40 sec?
<Chipzz> asac: this looks suspicious:
<Chipzz> [261181.832000]  ipw2200: Firmware error detected.  Restarting.
<Chipzz> [261181.832000]  ipw2200: Failed to up device
<asac> Chipzz: syslog please
<asac> oh yes indeed
<Chipzz> one of the last things in the log after rmmod/modprobe
<Chipzz> *after doing
<Chipzz> :q
<Chipzz> whoops
<stgraber> asac: I'm using gutsy's
<asac> stgraber: can you try 0.5.8 from http://siretart.tauware.de/upload-queue/ ?
<stgraber> asac: I'll, I've got to go for some hours but will try once back (I've the amd64 one somewhere on my system I'll just have to install it and test
<stgraber> )
<asac> stgraber: ok
<Chipzz> asac: can't reproduce it atm
<Chipzz> but I'm not getting associated after modprobing
<Chipzz> also with the firmware error
<Chipzz> hrrrrm
<Chipzz> apparently I'm not always getting the firmware error
<Chipzz> asac: btw, I'm not 100% sure if this is still the case, but I had problems in the past configuring my wireless network manually with iwconfig
<Chipzz> changing essid would not work when the module was loaded, what would work was putting the config in /e/n/i and rmmod'ing + modprobing ipw2200
<geser> Mithrandir: can you please move ion3-mod-xinerama from universe to multiverse (where ion3 is already). Thanks.
<ogra> ino3 in multiverse ? wow
<ogra> how did that happen
<geser> ogra: it did move there as upstream was unhappy with Debian and changed the licence
<ogra> wow, thats mean
<Chipzz> asac: aha, just managed to reproduce
<geser> ogra: iirc it has something to do that Debian stable had some old devel version and Debian didn't want to update it in stable
<ogra> which is policy ... well ... shrug ...
<ogra> i dont use it .... but i know *many* users
<Chipzz> asac: http://chipzz.safehex.be/random_associate
<Chipzz> asac: AFK now, ping me if you want more info ;)
<asac> Chipzz: you didn't enable the debug_level
<mvo> mthaddon: I'm preparing a new version that should fix the error message, would you mind waiting a bit with our upgrade so that you can test the new version and if it correctly reports the size requirements now?
<mthaddon> mvo, too late - already started it :) but I can probably figure out a way to replicate the issue on another machine and test it there
<mvo> mthaddon: ok, no problem. I can do that here too, it would have been nice to have a real-world test-case in additon to my canned test :)
<mvo> mthaddon: its entirely possible that you will be bitten by another bug that I just fixed in the process :/
<asac> stgraber: i see something like:
<asac> WEXT auth param 4 value 0x0 - eloop: could not process SIGINT or SIGTERM in two seconds. Looks like there
<asac> is a bug that ends up in a busy loop that prevents clean shutdown.
<mthaddon> mvo: what's that?
<mvo> mthaddon: a bug in the gtk upgrade view when the upgrade actually starts, if you use kde or the textview it will work, otherwise its probably best to cancel now and just wait a bit, it should be available failry soon (the update)
<asac> stgraber: i see that output when running nm from terminal with --no-daemon option
<mthaddon> mvo: is it worth going through just so it downloads the packages for the next time I run it?
<mthaddon> mvo, and how do I use the textview if I want to go ahead with that?
<mvo> mthaddon: you can cacncel it at ~90% or so, if you cancel it it will restore your system state (i.e. rewrite your sources.list back to the original one)
<mvo> mthaddon: "do-release-upgrade -d", but I would just wait, the upload will happen in max. 1h
<mthaddon> mvo: oh, ok, cool - will I get it if I cancel as my sources.list will be pointing to the gutsy stuff?
<mvo> mthaddon: if you cancel it will restore the original sources.list
<mthaddon> mvo, cool, thx
<\sh> ladies and gentlemen, does anyone has time to discuss an important issue? regarding wine 32bit packages on amd64... I'm just reviewing a new package of our upstream and need some advise regarding lib installation structure and packaging structure
<Chipzz> asac: I did; could it be that it's reset when rmmod'ing/modprobing the module?
<Chipzz> asac: log with debug information online on same location
<tkamppeter> doko, still there?
<keescook> hm, any reason pam isn't listed on merges.ubuntu.com ?
<soren> keescook: Merges seems to not be running.
<soren> keescook: MoM, I mean.
<Luke> asac: you around?
<keescook> soren: that would explain it.  ;)
<soren> keescook: The {main,restricted,universe,multiverse}.html date back to August 24th.
<keescook> heh, oops
<asac> Chipzz: yes
<asac> Chipzz: you can load the module with debug_level parameter i think
<asac> Luke: yes ... haven't received any mail
<asac> even looked in spam folder
<Chipzz> asac: I did that\
<Chipzz> crap, can't type on this keyboard...
<Chipzz> oh, wait, it's mine...
<davmor2> Riddell: ping
<Riddell> hi davmor2
<davmor2> Riddell: I started a 24hr testing of kubuntu today did the updates and now the network icon has gone and the live cd has a bluetooth crash on it that continues to the installed system.
<Riddell> davmor2: both known thanks, network-manager-kde has a new upload that should be available soon to fix the firs
<Riddell> bluetooth is waiting on a fix from mhb and doko
<doko> Riddell: ?
<davmor2> okay np I'll carry on and see if I find anything else then
<bryce> Riddell, fyi, we're going to be switching on bulletproof-x hopefully by tomorrow.  All major issues holding it back have been resolved.
<bryce> Riddell, also fyi, the xserver backports are coming along well; status page is at https://wiki.ubuntu.com/X/Fixes_to_Backport.  The first set of backported fixes from xorg 1.3.99 was uploaded yesterday, and I've got a second set taken mostly from fedora which I'm hoping to have ready before Friday.
<bryce> There are also some misc. bits and pieces leftover that might be worth pulling in post-beta.  We'll see.
<allee> doko: Riddell refers to 'import dbus.mainloop.qt' fail to load qt module.   I think mhb has pinged you already about this
<doko> allee: no?
<allee> doko: this link is needed to get import work properly: /var/lib/python-support/python2.5/dbus/mainloop/qt.so -> /usr/lib/python2.5/dbus/mainloop/qt.so
<allee> doko: ^^ hack of course
<allee> doko: qt.so is the only thing in /usr.  Al other releated stuff in in /var
<doko> ahh, the great fun of python-support, yeah!
<bddebian> heh
<doko> I'll look at that tomorrow
<allee> doko: as kblueplugd need to import dbus.mainloop.qt.  Every Kubuntu user get's on login a apport msg :(
<allee> doko: thx great!!
<siretart> asac: pong
<allee> siretart: hi!! Long time no see :)   Curious: you have any plans about fai 3.2+ ?
<siretart> allee: well, in principle I have a fai branch which I need to test
<siretart> allee: I was having heavy problems with our squid proxy, which needed to be fixed first, and then got disctracted with lots of other stuff
<siretart> allee: but In principle, it 'just' needs testing. I plan to test it in a PPA
<allee> siretart: okay.  I'll let you know  IIIIFFFF I find time to work on it too
<siretart> allee: thanks!
<Lure> doko: allee was talking about bug 135893
<ubotu> Launchpad bug 135893 in kdebluetooth "kblueplugd crashed with ImportError in <module>()" [Medium,Confirmed]  https://launchpad.net/bugs/135893
<nny> how do you check which version of a package the repository has with apt?
<ajmitch> short way: apt-cache madison
<siretart> nny: `rmadison -u ubuntu $package`
<mdke> is gutsy in a decent ish state? I'd like to upgrade
* lamont wonders how scary people find new fix-levels of klibc this late in the game
<asac> siretart: ... are you aware of a supplicant bug that makes TERMINATE fail?
* lamont decides that he finds the delta scary, backports the fix to gutsy's klibc version
<nny> thanks
<mathiaz> keescook: I'm going throught the sysklogd bugs on LP.
<keescook> mathiaz: excellent
<mathiaz> keescook: It seems that debian has an updated version of the package
<mathiaz> keescook: actually upstream has released a new version
<mathiaz> keescook: do you think it's worth trying to merge it ?
<keescook> mathiaz: if it fixes some of the open bugs, it would be worth getting a UVFe for it, sure.
<asac> siretart: after blocking for some time there is an error that eloop is not terminating et al
<mthaddon> just done an upgrade to gutsy and udevd seems to be hogging CPU - anything I can do about that?
<ionstorm> i had the same problem
<ionstorm> gutsy dont support rt73 drivers either
<ionstorm> locks up the box
#ubuntu-devel 2007-09-06
<geser> keescook: Hi, have you time to sponsor bug #137644?
<ubotu> Launchpad bug 137644 in tar "[Fake sync]  tar 1.18-2build1 from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/137644
<geser> it's the last tar upload to Debian unstable fixing CVE-2007-4131
<keescook> geser: cool, thanks.  I will get to it.
<keescook> geser: odd; I wonder why the orig is different?
<geser> keescook: I don't know. The last upload was also a fake-sync.
<keescook> geser: odd.  ubuntu's orig's base path is tar-1.18.orig whereas debian is tar-1.18.  No other file differences.  freaky
<keescook> perhaps we had a 0ubuntu during early gutsy.
<geser> yes, there war 1.18-0ubuntu1
<keescook> aah, okay.
<geser> keescook: interesting is that the tar from gnu.org has also a different md5sum (neither matching Debian nor Ubuntu) as is also bigger
<keescook> hah.  odd
<geser> looks like the texinfo files got removed (GFDL 1.1 licensed)
<crimsun> 3/win 21
<crimsun> (sorry)
<geser> Hi crimsun
<keescook> geser: uploaded :)
<geser> keescook: thanks
<keescook> thank you!  one less thing on my CVE merge list.  :)
<ajmitch> speaking of CVEs, I should sync or patch phpgroupware
<ion_> iwj: ldconfig doesnt seem to ever use triggers, since DPKG_RUNNING_VERSION is 1.14.5, not 1.14.5ubuntu11.
<mekius> I have a PC with a via video card. When the xorg.conf gets created, it contains the vesa driver and not the via driver.  I have created a custom cd with the openchrome driver and need to know how to autodetect via chips and load these drivers.  What controls the creation of the xorg.conf?
<Hobbsee> bad pygi!  no cookie!
<ion_> But what if Im hungry?
<Hobbsee> ion_: you're not pygi, you're OK
<Hobbsee> oh, fudge.  the new openoffice has messed with my data.
<Hobbsee> or maybe it was gnumeric
<ajmitch> hello Hobbsee
<StevenK> Bad calc? No cookie for him, either?
<Hobbsee> hi ajmitch
<Hobbsee> StevenK: exactly
* desrt looks around
<ion_> hobbsee: I just had to continue the quotation of The Office. :-)
<ion_> (US)
<Hobbsee> ion_: ahhh.  havent seen that.
* Hobbsee sees the US' "The Office", and raises them an Australian "The Castle"
<ion_> Its one of the best comedy series ive seen.
<StevenK> The Office is a series, and The Castle is a movie ...
<Hobbsee> still...
<StevenK> The Office is also a US series, and a UK series.
<StevenK> And it isn't clear which one ion_ is talking about.
<ion_> to042254 < ion_> (US)
<StevenK> Ah
<sbalneav> Hobbsee: You about?
* mneptok puts on his full-head latex Hobbsee mask
<mneptok> HIIIIIIIIIIIIIIIIIIIIIIII!
<sbalneav> heh
<mneptok> drat. no one falls for that.
<ajmitch> scary...
<mneptok> must be my lack of body odor.
* mneptok takes off a-runnin'
<sbalneav> There a regression in Pidgin? I can't seem to add a Jabber account.
<mneptok> sbalneav: i *think* the generic "Jabber" protocol type has been supersceded by a "Google Talk" type
<mneptok> try adding your Jabber account as a Google Talk account. wha'ppens?
<sbalneav> So, google talk is now jabber?
<mneptok> always has been.
<sbalneav> ok, I'll find out
<mneptok> Jabber on Google infrastructure.
* Hobbsee tickles mneptok
<ion_> I guess its too late to get a new version of LLVM to gutsy. :-\ Gutsy has 1.8, 2.0 has been released and 2.1 will be released in three weeks.
<Hobbsee> sbalneav: hiya!
<sbalneav> Hobbsee: Just trying to figure out pidgin...
<ion_> sbalneav: XMPP is the name of the protocol.
<ajmitch> ion_: given that it's been a debian sync in the past, someone would need to package, test & get approval for the new version
<mneptok> ion_: suave catch. thanks guy.
<sbalneav> ah
<mneptok> (XMPP)
<ion_> It wouldnt hurt to say XMPP (Jabber) or something like that in the dialog.
<Hobbsee> sbalneav: right...
<mneptok> ion_: if we make it obscure we keep the n00bs off the protocol. unless you *want* North Korean feline horror-porn ads in Jabber.
<bddebian> I don't suppose there are any archive admins awake at this hour?
<ion_> Does anyone else notice tracker 0.6.2 searches not working?
<fabbione> morning
<bddebian> Hello fabbione
<ion_> ning.
<tepsipakki> crap, UDS overlaps with the Rush concert on 29.10. in Helsinki :/
<desrt> and what do you feel is more important? :)
<tepsipakki> desrt: well, I booked the tickets in April ;)
<tepsipakki> Rush hasn't been to Finland before
<tepsipakki> three years ago I had tickets to Stockholm, but it was too close to the birth of our first-born
<Luke> asac: can you read the email I sent you a few days ago when you have a chance?
<tepsipakki> keescook: thanks for doing the pam-0.99 merge, I'll test it right away
<tepsipakki> keescook: seems to work just fine, with krb5 & ldap
<dholbach> good morning
<asac> Luke: i told you that i didn't receive any mail
<asac> 21:36 < asac> Luke: yes ... haven't received any mail
<asac> 21:37 < asac> even looked in spam folder
<dholbach> mdke: I changed the version number of the ubuntu-docs upload to 7.09.1
<seb128> siretart: why did you upload cdrtools, we already have cdrkit no?
<StevenK> seb128: Do you have a moment for some archive admin type stuff/questions?
<seb128> StevenK: yes
<StevenK> seb128: Okay, it appears we can't distribute the virtualbox packaged called virtualbox due to trademark issues. Debian has sorted this, and has a virtualbox-ose package. The Debian Maintainer was nice to e-mail me to tell me about this.
<TheMuso> If a build/archive admin is around, could they please give back synfigstudio on i386 and powerpc? Thanks.
<StevenK> seb128: Shall I forward his e-mail into Launchpad, and you can tack the "Fine, everything removed" message on it?
<StevenK> seb128: I've prepared a merge for virtualbox-ose, I'm in the middle of test building it.
<seb128> TheMuso: needs to be a build admin, maybe ask Mithrandir or doko_
<seb128> StevenK: yes, please open a bug
<StevenK> seb128: Shall do.
<StevenK> seb128: I'll bounce the original mail into Launchpad, and then fiddle the package and so on.
<seb128> ok, thanks
<pygi> seb128, wrt cdrtools : afaik, because users need a choice, and because it's better then  cdrkit
<seb128> pygi: why do they "need a choice"?
<seb128> pygi: isn't cdrkit already shipping cdrecord?
<seb128> pygi: that's Debian modified version against stock upstream code?
<pygi> seb128, it's shipping wodim, a counterpart. And it's not maintained, and it's buggy as hell
<cjwatson> fix it?
<pygi> cjwatson, fix unmaintained software? Interesting
<cjwatson> err ... yes?
<cjwatson> happens all the time
<pygi> cjwatson, you'd be fixing it forever then
<cjwatson> we call this "maintaining"
<cjwatson> did whoever uploaded cdrecord remember to include the fix for bug 130376?
<ubotu> Launchpad bug 130376 in cdrkit "crash while checking MD5sums on jigdo include list" [High,Fix committed]  https://launchpad.net/bugs/130376
<ion_> pygi is a libburnia author. libburnia > cdrtools in the long run.
<cjwatson> s/cdrecord/cdrtools/
<cjwatson> ion_: speaking as cdimage admin, software that works now > libburnia right now
<cjwatson> (the bug above existed in cdrtools too)
<pygi> cjwatson, it existed in what revision of cdrtools? Newest?
<pygi> ion_, let them use whatever they want, be shhh =)
<cjwatson> pygi: since edgy
<pygi> cjwatson, ergh, well, that's not newest
<cjwatson> up to when I fixed it
<pygi> perhaps it was fixed back then
<cjwatson> it was hardly likely to be fixed by upstream now was it?
<pygi> but I have a feeling I should rather withdraw from cd-recording -related discussion
<cjwatson> given that jigdo is a Debian patch
<pygi> true that
<cjwatson> and it was not fixed in cdrkit until I sent the patch
<cjwatson> so no, it was not fixed in the current version
<pygi> plus, probably the only thing you're missing from libisofs now (tho there is still no  command line interface) is HFS/HFS+ for Mac spins
<seb128> geser: cvxopt src/C/SuiteSparse has files under the LGPL but that's not mentioned in the debian/copyright, could you sort that with Debian?
<dholbach> mdke: for gnome-user-docs, please pull from http://bazaar.launchpad.net/~dholbach/gnome-user-docs/fixes
<seb128> cjwatson: there is a cvxopt upload in NEW (package coming from Debian with one change) which has some files under the LGPL but the debian/copyright only mentions GPL
<seb128> cjwatson: the LGPL license text is shipped in the tarball though
<seb128> cjwatson: would you accept the upload and bug Debian to fix it or reject it until that's fixed?
<geser> seb128: will do
<seb128> geser: thanks
<soren> Do any of you have experience with this otpw solution? http://www.cl.cam.ac.uk/~mgk25/otpw.html
<soren> It seems to work fairly well (it's been in Debian for about a month), but if you have bad experiences with it or something like that, I don't want to bother filing a NPFe for it.
<StevenK> seb128: bug 137719
<ubotu> Launchpad bug 137719 in virtualbox "Virtualbox under Gutsy" [Undecided,Confirmed]  https://launchpad.net/bugs/137719
<StevenK> seb128: virtualbox-ose builds fine, I'll upload it in about 45 minutes.
<seb128> StevenK: ok, so I just have to remove virtualbox for now?
<iwj> stgraber: I've just got a bunch of bugmail due to you doing something not entirely comprehensible to a whole pile of bug reports.  Would you care to explain ?
<dholbach> What does the state 'Failed to upload' mean? that happened to gnome-user-docs
<Riddell> dholbach: it means soyuz broke
<Riddell> or that the package failed one of soyuz' tests
<dholbach> ok good, so it has nothing to do with me
<dholbach> mdke: ^
<Riddell> ask infinity to investigate
<Riddell> infinity: so, can we get the sun-java debconf licence agreement pre-seeded in the buildds?
<soren> dholbach: It may have something to do with you. Soyuz has implemented some new checks what we need to deal with.
<soren> dholbach: It requires the existence of debian/copyright, for instance.
<dholbach> hrm
<dholbach> well, it exists :)
<soren> dholbach: The REJECT mail didn't say what the problem was?
<soren> dholbach: debian/copyright was just an example. I don't know if they added other checks, too.
<dholbach> ok got it
<dholbach> sorry
<dholbach> mdke added the pre-depends on dpkg in debian/control, not in debian/control.in
<pygi> cjwatson, would you be so kind to gimme the lines that ubuntu uses to do re-spins?
<cjwatson> pygi: I'm sorry, could you clarify exactly what you're talking about? respins of what?
<pygi> cjwatson, of iso images. mkisofs/genisoimage lines
<cjwatson> pygi: we don't do respins; we build every image from scratch
<pygi> cjwatson, that's what I meant :P
<cjwatson> pygi: the code is all in http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ (check out the things listed in configs/devel as well)
<pygi> cjwatson, will do, thank you
<cjwatson> why does vmware drive my PC speaker mad?
<pygi> cjwatson, no mkisofs lines in cdimage mainline, but I'll checkout the things in config/devel
<cjwatson> pygi: it's in debian-cd
<pygi> yup, hunting it now
<cjwatson> easier to follow if you have all the bits though
<StevenK> seb128: virtualbox-ose in the process of uploading. Please accept at your leisure.
<pygi> cjwatson, I think amd64 and i386 images could easily be built by some simple libisofs frontend
<pygi> I gotta create one for fedora some time in the future, so you might want to try it when it's done
<iwj> ion_: You are correct.  The test system I was using evidently has some difference.
<cjwatson> pygi: does libisofs do jigdo?
<pygi> cjwatson, no, not really
<cjwatson> that's necessary for us
<pygi> sadly, I have 0 clues about jigdo :-/
<pygi> cjwatson, are you aware of any specification for jigdo?
<pygi> I guess jigdo isn't really the task for libisofs directly, but rather some fronted?
<\sh> doko, when you listen, what could be wrong when gcc -m32 -o bla foo.c doesn't work
<siretart> well, regarding cdrtools. I've been in contact with Joerg S. (upstream) and pygi about it.
<siretart> we are both not really interested in maintaining it properly, like in doing more maintenance than packaging, mainly because we both think the support upstream gives is best suited for this package for several reasons (which do not really matter here)
<siretart> its right that we have cdrkit, which is a fork from a quite old version of cdrecord
<siretart> upstream of cdrecord has done quite a lot of work in cdrtools, like adding blue ray support and improving a lot of things in mkisofs
<cjwatson> pygi: talk to Steve McIntyre
<siretart> therefore I do think that it is worthwile to have it in multiverse
<siretart> from the licencing, I do think the lincense should be good enough for multiverse
<siretart> if the ftpmasters disagree, I'm curious to read the reject message
<siretart> and will discuss it with upstream
<pygi> cjwatson, oki, I'll try to hunt for him
<\sh> siretart, you want to discuss it with joerg schilling?
<siretart> \sh: I had a several hour phone conversation with him. yes
<\sh> siretart, I wonder if Joerg is going away of his decission to change the licence...
<pygi> cjwatson, would you mind telling me his nick if you know?
<cjwatson> pygi: Sledge
<\sh> anyways...I wonder what's wrong with gcc and friends not wanting to run with -m32
<pygi> cjwatson, ah, right  ... he's always busy  :-/
<cjwatson> pygi: have you tried e-mail, or only IRC?
<pygi> cjwatson, irc, but I'll talk, no worries
<cjwatson> or you could mail the debian-cd list
<pygi> got it
<cjwatson> Riddell: DESKTOP_SESSION is always set inside kdm, isn't it?
<siretart> \sh: ideally, joerg wants to have cdrtools to be licenced as CDDL completely. this isn't possible atm because of 2 parts: smaller hfs related parts of mkisofs, the hfs support library and the schily autoconf system (which are all derived from GPL software)
<siretart> \sh: he has no interest going back to GPL for reasons that are rather difficult to understand
<geser> seb128: re cvxopt copyright file: I've looked at the copyright file again and it mentions the LGPL at the end of the file (see http://packages.debian.org/changelogs/pool/main/c/cvxopt/current/copyright)
<\sh> siretart, yeah, I read some mails about those issues...
<siretart> seb128: did that answer your question regarding cdrtools?
<geser> seb128: the mentions projects have their files below src/C/SuiteSparse
* ogra wonders why edubuntu-addon-meta still shows up on "anastacia", it was added to the ship-addon seed yesterday
<Riddell> cjwatson: set to "kde" yes
<Riddell> well, I suppose its different for other desktops
<cjwatson> Riddell: excellent, thanks
<cjwatson> gdm has it set to "default"
<cjwatson> ogra: your seed change didn't work because you used a source package name
<cjwatson> ogra: if you want to include all binaries from that source, the syntax is "* %edubuntu-addon-meta"
<ogra> oh, crap, indeed
<\sh> doko, I have the strange feeling that compiling 32bit on amd64 is somewhat broken...using -m32
<\sh> argl
<\sh> doko, unping..gcc-multilib was missing for building -m32 binaries on amd64
<\sh> eventually you think about adding it as dep to lib32gcc1 package
<stgraber> iwj: uhmm, Brian told me the same yesterday, I guess it has something to do with the QA Tracker being able to set tag (but had to use some forcing parameters to python-launchpad-bugs Brian gave me), now the tracker should be using the ubuntuqa account and shouldn't cause any kind of problem anymore (I'm looking at my bugmail though)
<stgraber> iwj: It happened yesterday at ~20:00 UTC, did you see that again today ?
<cjwatson> seb128: what bit of GNOME is responsible for starting gnome-settings-daemon?
<Mithrandir> asac: did you see the mail from Jon Villalovos about invoke-rc.d and NM?  What do you think about his suggestion?
<iwj> stgraber: I saw changes at 22ish UTC yesterday, yes, but nothing since then.
<iwj> stgraber: The thing that's odd about it is that it seems to have involved changes to descriptions.
* Hobbsee tickles Mithrandir in greeting
<geser> Hi Hobbsee
<asac> Mithrandir: I chatted with him yesterday ... I have to test it and will do a cherry-picked upload for that.
<Mithrandir> asac: ok, it would be good if you could prioritise that, as it's causing them some pain.
<iwj> Eg in bug 131284 a pair of leading spaces were mangled into a pair of =C2=A0 (in Q-P UTF-8).
<ubotu> Launchpad bug 131284 in yelp "about ubuntu menu item results in page not found" [Medium,Fix released]  https://launchpad.net/bugs/131284
<asac> Mithrandir: yes thats why i plan to do a quick upload for that
<Hobbsee> hi geser
<stgraber> iwj: yes and looking at the change I find no diff ...
<Mithrandir> asac: excellent, thanks.
<iwj> ** Description changed:
<iwj> ...
<iwj> -   Page not found
<iwj> + =C2=A0=C2=A0Page not found
<stgraber> ouch
<iwj> (When I ask my MUA to show me the Q-P.)
<stgraber> and that's the result of a .tags.append("iso-testing") and a .commit()
<StevenK> Mithrandir, seb128: Could one of you accept virtualbox-ose in source NEW, please?
<geser> StevenK: is that the version with non-free source in the orig.tar.gz? there was a discussion about virtualbox on the debian-devel ML
<StevenK> It has dfsg in the version. So no.
<geser> the problem is that it contains non-free source in the dfsg tarball
<StevenK> It does?
<geser> http://lists.debian.org/debian-devel/2007/09/msg00115.html
<StevenK> geser: No spoiling my night.
<geser> http://lists.debian.org/debian-devel/2007/09/msg00125.html
* StevenK sighs.
<StevenK> Well, no fixed virtualbox-ose yet.
<StevenK> seb128, Mithrandir: Please REJECT it, due to what geser pointed out.
<Mithrandir> StevenK: rejected.
<Hobbsee> yay, bloodbath
* ion_ managed to make a script that synchronizes apts, aptitudes and debfosters opinions about automatically/manually installed packages.
<StevenK> Mithrandir: Thank you
<\sh> did someone do something with ion3-xinerama-mod package?
<\sh> I just received very strange mails about it
<pygi> it was moved to multiverse afaik?
<geser> yes
<\sh> hmm...
<\sh> see #launchpad pls :)
<Luke> asac: ah sorry - I never got that. I'll resend it.
<doko> Riddell: looking into the broken sip4-qt3 after your last upload ... do you really want to have sipconfig.py in python-sip4 ?
<Riddell> doko: it was a quick fix because mountconfig needed it, I didn't look into why it was needed I'm afraid
<doko> Riddell: your quick fix did remove sipconfig.py from all packages ...
<doko> and missing replaces.
<\sh> doko, is it possible to add gcc-multilib as dep or recommends to at least lib32gcc1? without this package nobody can compile 32bit apps/libs on amd64 (running x86_64 arch)
<doko> \sh: absolutely no
<asac> Luke: where did you send it? maybe open a bug ... thats far better to track for me
<\sh> doko, and whatabout a hint in the description of lib32gcc1? ;) I wonder if it's obvious that you need gcc-multilib when you want to use e.g. -m32
<doko> \sh: we usually don't add suggests in libraries for development packages
<\sh> doko, I know...so, where do we document this for developers (!= package maintainers) who don't know about the existence of gcc-multilib
<doko> \sh: why, or for what do you need to build something with -m32?
<doko> we don't support a complete biarch development environment
<doko> Riddell: fixed your "quick fix" ;p
<\sh> doko, it hasn't to do anything with packaging, but when you need (as a software developer) some software, which doesn't run natively on x86_64, but as 32bit compilation (with the provided biarch libs we have) .. so you start with gcc -m32...and this doesn't work without installin this multilib package...
<doko> \sh: as a developer you should install the compiler, and have a look what the compiler package suggests ...
<Riddell> doko: great, thanks
<Riddell> doko: did you look at the python qt dbus issue too?
<doko> Riddell: would you mind building kde4 using g++-4.2 -fhidden-visibility?
<doko> Riddell: I did, but the package did fail to build due to the python-sip4 mess
<Riddell> doko: post feature freeze that would make me very scared
<Riddell> what does kde 4 have to do with python sip?
<doko> Riddell: I don't know
<StevenK> doko: We played that game earlier - it made the modules not load at all.
<doko> StevenK: with g++-4.2?
<StevenK> Nope, not with g++-4.2
<doko> StevenK: according to Riddell upstream builds their packages with 4.2 by default
<bddebian> Heya
<bddebian> Could some kindly archive admin please give back player?
<bddebian> Should build with newer python-central
<Riddell> StevenK: that was KDE 3, I've no idea how kde 4 reacts to hidden-visibility or even how to enable it
<bddebian> do be do be dooo
<StevenK> Ahh
<seb128> cjwatson: gnome-session starts gnome-settings-daemon but it can also be spawned when required (that happens when running some applications like the appearance capplet out of GNOME)
<Mithrandir> bddebian: archive admins can't do give-backs, buildd-admins can.  I've done a give-back now
<seb128> siretart: yes, I'm not sure we should have it duplicated though
<bddebian> Mithrandir: Oh, sorry, I did not know there was a difference
<bddebian> And Thank You :-)
<\sh> keescook, ping question about drupal in feisty (5.1 is exploitable...)
<seb128> geser: alright, cvxopt accepted
<ogra> sladen, bug 126987 sounds like the return of the broken icon cache (i think dholbach fixed that once in former releases)
<ubotu> Launchpad bug 126987 in network-manager "The NetworkManager applet could not find some required resources.  It cannot continue." [Undecided,New]  https://launchpad.net/bugs/126987
<dholbach> sladen: running it under  strace -e open,stat  could help to find out what's wrong
<dholbach> but yeah, it could be the icon cache
<ogra> in bug 137760 it reports some detail at least, i wonder why it doesnt do that with other stuff
<ubotu> Launchpad bug 137760 in gnome-power-manager "Network Manager applet cannot show Connection Information window" [Undecided,New]  https://launchpad.net/bugs/137760
<dholbach> although it should use dh_icons now - debian/rules looks fine
<StevenK> seb128: Can you give the gimp 2.4.0~rc2 in my PPA a once over?
<seb128> StevenK: will do
<\sh> keescook, please have a look at bug 137762, I'm trying to secfix the dapper version as well, and will have a look at edgy..(dapper will be horrible)
<ubotu> Bug 137762 on http://launchpad.net/bugs/137762 is private
<Hobbsee> stgraber: ping/
<siretart> seb128: we need to have it duplicated because of licencing reasons. cdrtools (IMO) not suitable for universe nor main, but that's something I cannot really answer. An archive admin would need to assess that
<bddebian> Are we supposed to update the Maintainer field for -Xbuild1 revisions?
<geser> bddebian: no
<bddebian> geser: Thx
<cjwatson> seb128: oh, right, it's hardcoded in /usr/bin/gnome-session; I was looking for configuration files. thanks
<mathiaz> keescook, jdstrand: I've been looking at bug 120085
<ubotu> Launchpad bug 120085 in sysklogd "Various problems running syslogd with "-u syslog" option" [Medium,Triaged]  https://launchpad.net/bugs/120085
<mathiaz> it seems that syslogd is not running under the syslog user since edgy
<keescook> mathiaz: so this may be an upgrade issue?
<cjwatson> ogra did the first merge of sysklogd in feisty
<mathiaz> keescook: well it seems that there are two issues in the bug
<keescook> tepsipakki: great! I didn't get a lot of authentication users tested, so if you got ldap, that's good.  :)
<mathiaz> one for dapper and one for gutsy
<cjwatson> but he did not follow the merge policy so we cannot tell what he intended
<cjwatson> (i.e. he didn't list the changes being kept)
<cjwatson> oh, but that list went into 1.4.1-20ubuntu2 I think
<cjwatson> it does not list pitti's privilege dropping patch, so it looks like that's when it was dropped
<mathiaz> well.. the privilege dropping patch is still there
<jdstrand> mathiaz: sure enough, I checked a dapper box and syslog is running as non-root
<jdstrand> mathiaz: long-time dapper box too
<cjwatson> mathiaz: clearly not working :)
<ogra> oh, sorry
<mathiaz> jdstrand: yes. in dapper in runs under syslog user
<mathiaz> the user privilege patch is still there
<jdstrand> mathiaz: well, that will make it easier to track down
<mathiaz> well the problem is tracked down.
<mathiaz> the reload action in the script has changed
<cjwatson> the diff is a mess, it has a changelog.orig and random changelog edits
<mathiaz> it sends a HUP signal instead of stop/start
<cjwatson> control.orig
<mathiaz> cjwatson: yes. I've seen that.
<mathiaz> cjwatson: there is also a new version in debian (that is actually a new version from upstream)
<mathiaz> cjwatson: after three or four years..
<jdstrand> mathiaz: have you tried the old stop/start behavior on a newer than dapper box?
<mathiaz> jdstrand: that would work then.
<cjwatson> mathiaz: it's broken because it does SYSLOGD="-u syslog" and then sources /etc/default/syslogd, which sets SYSLOGD=""
<mathiaz> jdstrand: but that means that logging stops for some time
<cjwatson> it should source the configuration files and then do something like SYSLOGD="$SYSLOGD -u syslog"
<mathiaz> cjwatson: correct. But running under the syslog user requires some changes in the cron script that rotates logs
<mathiaz> cjwatson: and we should also take care of changing the ownership when upgrading the package
<mathiaz> cjwatson: the ownership of log files I meant
<cjwatson> yes
<mathiaz> cjwatson: would this be accepted in gutsy ?
<mathiaz> the other solution would be to remove the -u syslog option from the init script and run syslogd asroot
<mathiaz> which is the case for edgy and feisty
* ogra wonders if he did anything wrong ... 
<cjwatson> mathiaz: yes
<cjwatson> mathiaz: it's clearly a regression
<cjwatson> privileges were intended to be dropped, and now they are not
<cjwatson> ogra: ok, it was just hard to tell from the changelog whether it was your change or not :) changelog entries in edgy indicated that the privilege dropping patch had been preserved
<cjwatson> and yours was the first one that wasn't clear
<ogra> ah, right
<ogra> intresting that it shows up in the edgy changelog but isnt used there either apparently
<mathiaz> cjwatson: another solution would be to use an apparmor profile to protect syslogd
<ogra> mathiaz, will that affect remote loggon in any way ?
<ogra> *logging
<ogra> (i need that in ltsp=)
<mathiaz> ogra: I'm not sure if it would.
<mathiaz> ogra: in ltsp you need to be able to enable remote logging on the server
<ogra> right
<mathiaz> ogra: and also on the clients
<ogra> we have the override file in /etc/ltsp for that atm
<ogra> (for the server)
<ogra> well, the clients just use logger which points to the server
<mathiaz> ogra: the client don't have a syslogd running ?
<ogra> we dont add any extra confoig there
<ogra> right
<mathiaz> ogra: ok. So you just run syslogd with the -r option on the server.
<ogra> oh, wait
<ogra> we enabled it in feisty
<ogra> so we have syslog running on the clients
<ogra> and yes, we enable syslog with -r
<ogra> the initscript respects /etc/ltsp/syslog if it exists
<mathiaz> ogra: yes. correct.
<ogra> err ... *syslogd
<mathiaz> ogra: on the clients, syslogd is setup to do remote logging on the server ?
<ogra> yes
<mathiaz> ogra: I don't see any problem with an apparmor profile in that case.
<ogra> /etc/syslog.conf gets: *.* @<serverip> during a client boot
<cjwatson> mathiaz: I don't think apparmor is a substitute for dropping syslogd's privileges
<geser> doko: can you please look at the build log http://people.debian.org/~lucas/logs/2007/08/28/libtritonus-java_20070428-3_gutsy32.buildlog
<geser> doko: [javac]  /usr/bin/ecj-bootstrap: line 26: /usr/bin/gij-4.2: No such file or directory
<mathiaz> cjwatson: why ?
<geser> doko: who is missing the depends on gij-4.2? it is ecj-bootstrap or should libtritonus-java build-depend on gij-4.2?
<jdstrand> cjwatson: I agree
<jdstrand> mathiaz: I have been thinking about this and feel that apparmor would be good additional protection for remote logging
<jdstrand> mathiaz: however, running it as an unprivileged user gives additional local protections (as keescook mentioned yesterday)
<jdstrand> mathiaz: when it runs as root, a bug in syslog that could be triggered locally (eg via its conf file, etc) would allow full access
<jdstrand> mathiaz: running as an unprivileged user protects against that
<jdstrand> mathiaz: doing *both* is ideal
<doko> geser: ecj-bootstrap is gone, this should be ecj
<mathiaz> jdstrand: full access ? I don't see why - if access is not granted in the profile, the process won't have access to the ressource.
<bddebian> geser: Well since you are the java expert now, fix freemind ;-P
<stgraber> Hobbsee: pong
<jdstrand> mathiaz: this gets at the hard links issue keescook mentioned
<Hobbsee> stgraber: what did iyou actually change with https://bugs.launchpad.net/bugs/122500 ?
<ubotu> Launchpad bug 122500 in ubiquity "Kubuntu - Mount dialog always gets shown when the disk is mounted, in the middle of the install" [Undecided,Fix released] 
<keescook> just lots of security layers.  :)
<stgraber> Hobbsee: tag using python-launchpad-bugs
<stgraber> Hobbsee: it's the new script we are using for the QA tracker
<mathiaz> keescook: ok. I see your point.
<jdstrand> keescook: exactly
<stgraber> Hobbsee: http://codebrowse.launchpad.net/~ubuntu-qa-tracker-devel/ubuntu-qa-tracker/trunk/annotate/stgraber%40ubuntu.com-20070904221630-ycv4fev6s04nqvbr?file_id=lpintegration.py-20070901183400-o9v3rkpvbowj3yam-3
<stgraber> Hobbsee: it's the tagBug function
<mathiaz> jdstrand, keescook: could you re-explain the hardlink issue ?
<stgraber> Hobbsee: uhm, in fact that code isn't really up to date, let me upload the new one somewhere
<keescook> mathiaz: sure.  in the case that you have unconfined processes that are "attacker controlled" (i.e. a local malicious user)
<stgraber> Hobbsee: http://paste.stgraber.org/3407 here is the one that's currently running
<keescook> you can (possibly) set up an environment that AppArmor wasn't expecting
<Hobbsee> stgraber: ahhh....
<keescook> hardlinks to areas like /tmp will "avoid" the apparmor profiles.
<keescook> for example, let's say you hardlink to /root/.ssh/authorized_keys into /tmp, and then exploit something that causes the root-run process to write to /tmp
<stgraber> Hobbsee: bdmurray suggested to put the force_changes=True,ignore_lp_errors=False as tag changes weren't saved previously
<Hobbsee> stgraber: it's just doing annoying things via email
<keescook> AA won't stop that, since the hardlink action was unconfined (and allowed)
* StevenK ponders fixing gambas2's packaging so that it doesn't suck.
<bddebian> Heh
<cjwatson> mathiaz: because we allow people to remove apparmor; it is not mandatory
<cjwatson> mathiaz: we should be shipping a secure standard Unix system as well as supplementing its safeguards with tools such as apparmor
<cjwatson> mathiaz: multiple safeguards are always better than just one, as jdstrand points out
<StevenK> seb128: Any news about gimp?
<seb128> StevenK: what do you need exactly about it?
<StevenK> seb128: I've tested it myself, I'd just prefer someone else to also do so.
<mathiaz> keescook: Thanks for the explanation.
<mathiaz> cjwatson: Ok. I see your point and agree.
<geser> doko: kaffe-pthreads still depends on ecj-bootstap which pulls ecj, but nothing pulls in gij-4.2
<mathiaz> keescook: would this be fixed in AppArmor itself ?
<StevenK> geser: I think kaffe currently fails to build.
<keescook> mathiaz: no, since it's outside of confinement, there is nothing that can be done.
<unggnu> hi all
<keescook> however, I have some patches from GRsecurity that I'm trying to get into the mainline kernel that would address the specifics of hardlink and symlink abuse.
<keescook> not happening for gutsy (if ever)
<doko> geser: I see, as a workaround, let kaffe-pthreads depend on ecj-gcj
<unggnu> mvo: Hi, I have red that you are the assignee of "System cleanup". Doesn't it makes sense to run "apt-get autoclean" after upgrade or is already run?
<doko> will fix it
<StevenK> mvo: Around?
<geser> doko: how does this help with finding /usr/bin/gij-4.2 (not gcj-4.2)?
<unggnu> mvo: I think that most people upgrade from Internet and not CD so I guess that there will be around 500 MB of unneeded package installation files or at least all updates installed since first installation.
<mvo> unggnu: yes, but its not that important IMHO as the apt cleanup cronjob will take care of this after 1 days normally anyway
<mvo> StevenK: yes
<unggnu> mvo: There is a cronjob which cleans it?
<doko> geser: /usr/bin/ecj
<dr1> hey guys, I need to make changes to an ISO file, is there a way to mount it such that I can write to it in linux
<unggnu> mvo: Btw. thanks for your reply :)
<StevenK> mvo: sexy-python is now called python-sexy. Do you have changes to gnome-app-install, or should I just change that bit and upload it?
<mvo> unggnu: yes, there is a apt.cron that regularly cleans out /var/cache/apt/archives
<Hobbsee> dr1: #ubuntu for support
<dr1> ok
<dr1> thanks
<Hobbsee> dr1: and man mount
<unggnu> mvo: Ok, thanks.
<mvo> StevenK: thanks! let me change it please, I have some other pending changes in my bzr tree
* Hobbsee wonders what's so hard about reading the topic.
<StevenK> mvo: Sure. Glad to help.
<mvo> unggnu: but thanks for raising it, I will look at this again
<seb128> StevenK: the gimp upload looks fine and work correctly
<seb128> StevenK: I've tried on i386
<StevenK> seb128: And it worked for me on amd64, excellent.
<StevenK> cjwatson, Hobbsee: So, shall I upload gimp 2.4.0~rc2? :-)
<seb128> StevenK: they should stop versionning the binary though
* Hobbsee is very much asleep.
<seb128> the update broken my panel launcher
<seb128> s/broken/broke
<StevenK> seb128: I can fix that, if you like.
<geser> doko: I see now
<seb128> StevenK: would be nice to have a the desktop using "gimp" rather than "gimp-version"
<StevenK> seb128: Quick fix would be to add a symlink
<seb128> there is a symlink gimp -> gimp-2.4
<StevenK> Hrm. What is actually broken? I'm sure something is...
<StevenK> Damn it, Thunderbird, check *all* of my folders for new mail!
<seb128> StevenK:
<seb128> $ grep Exec /usr/share/applications/gimp.desktop
<seb128> Exec=gimp-2.4
<seb128> StevenK: it should use "gimp" there
<StevenK> Ah ha. I shall fix that.
<seb128> otherwise if you dnd it to a panel it'll get the version coded to the launcher
<seb128> and we update to 2.5 it'll be broken
<seb128> and we can't change the user config on upgrade
<StevenK> Exec=@GIMP_COMMAND@ %U
<StevenK> Ugh. I'll dig when I get up.
<Mithrandir> StevenK: you can tell it not to, at least on IMAP
<seb128> don't bother with that now, we can fix later
<Hobbsee> StevenK: it's a public holiday.  you can stay up late.
<seb128> you can upload the new version if you want ;)
<Hobbsee> well...fsvo public holiday, anyway.
<StevenK> Mithrandir: Ah, it was only checking Inbox. My IMAP server sorts mail itself using sieve.
<StevenK> Mithrandir: I found the magical switch
<StevenK> Hobbsee: By rights, I should have gone to bed about 2 and a half hours ago.
<StevenK> seb128: Right, Exec=gimp-2.4 can be fixed by just not replacing it in the .desktop, or by hacking configure.in. Personally, I prefer the first.
<stgraber> Hobbsee: When was the last bugmail you receive from me (stgraber@ubuntu.com) or the tracker (qatracker@ubuntu.com) ?
<seb128> StevenK: works for me
<stgraber> Hobbsee: the automatic tag thing as been turned on yesterday at 22:00 (20:00 UTC) and there was a python-launchpad-bugs update since then, does that still happen ?
<Hobbsee> stgraber: ~18 hours
<iwj> ion_: Thanks for that report.  That was due to me not having rerun autoconf before uploading.  I keep getting caught out by that - must pay better attention.
<iwj> 1.14.5ubuntu12 should fix it.
<mvo> iwj: what is the issue with -ubuntu11? I just uploaded a version for the upgrade-pre-requists based on this ubuntu11
<StevenK> seb128: You're sure it's okay to upload gimp? :-)
<iwj> mvo: I forgot to run autoconf.
<iwj> Looks like I got there first.
<iwj> If you mail me your debdiff I'll merge it.
<iwj> The consequence of not running autoconf is that the version number dpkg thinks it has is not correct and as a result the triggerisation of ldconfig doesn't take effect.
<mvo> iwj: oh, I see. thanks, I will update my package tomorrow then. the upload is a "fork" (a new source package) that is build as a udeb just for the release upgrader
<iwj> Glrgk.
<iwj> What's the version number ?
<iwj> I really mean: what's the version number in ./configure ?
<iwj> Sorry to cause you inconvenience, anyway.
<mvo> iwj: I don't know, no worries, I can attack the problem tomorrow
<iwj> Sure.  If you took ubuntu11 then if you just rerun autoconf it will fix it.
<iwj> Your build processes may have done that already.
<iwj> grep 1.14.5 dpkg-strange-thing/configure will tell you too
<iwj> PACKAGE_VERSION='1.14.5'    ... wrong
<iwj> PACKAGE_VERSION='1.14.5ubuntu12'    ... right (provided value of 12 is at least 10)
<iwj> If you get at all bogged down point me at the package and I'll fix if need be.
<norsetto> keescook: ping?
<keescook> norsetto: hello!
<norsetto> hi :-)
<norsetto> keescook: I wonder if you can give a look @bug 136302?
<ubotu> Launchpad bug 136302 in sylpheed-claws-gtk2 "Sylpheed POP3 Format String Vulnerability" [Medium,Confirmed]  https://launchpad.net/bugs/136302
<keescook> norsetto: yup, I've been following it.  I was going to get the patches built and uploaded shortly.
<norsetto> keescook: ok, thanks. what do you think about sylpheed?
<norsetto> keescook: I hope you don't mind to be referred to as the "security advisor" :-)
<keescook> norsetto: ah, there has been a lot of discussion since I last looked
<keescook> norsetto: I'm so confused.  What is adnarim saying is missing?
<norsetto> keescook: he is complaining about sylpheed; I did not fix that becuase he cannot provide any reference to the needed code change
<norsetto> keescook: I could fix the other two, the reference is clear. Mind you, it makes sense that that function call is wrong too.
<keescook> ah, it seems like the issue is identical (i.e. the code is the same between both packages?)  I haven't looked at the cod yet.
<keescook> what have other distributions fixed for their updates?
<norsetto> almost sylpheed-claws, sylpheedclaws-gtk2 use the alertpanel_error_log function, sylpheed the alertpanel_error one
<norsetto> keescook: indeed by looking at the changelog of other distros could help, but he hasn't done so, and I was busy doing the 8 patches....
<keescook> norsetto: hehe, understood.
<norsetto> keescook: I don't know if I will do another 8 patches in a row like this ;-)
<norsetto> keescook: hope I didn't screw anything
<keescook> norsetto: heh, yeah, it can be a lot of work!
<keescook> norsetto: yeah, looks like sylpheed is buggy too, as adnarim says
<norsetto> keescook: it seems reasonable to me as well
<norsetto> keescook: but if you or somebody else ask for a reference , it cannot be provided (not now at least)
<keescook> sure, it's the same reference.  (same code)
<norsetto> keescook: well, it isn't, its "similar"
<keescook> norsetto: for future security patches, also please include the CVE in the changelog (i.e. CVE-2007-2958)
<norsetto> keescook: ok, will remember that
<keescook> norsetto: ah, and please follow the security versioning.
<keescook> e.g. 2.1.1-1ubuntu1 -> 2.1.1-1ubuntu1.1
<norsetto> keescook: ok, I didn't know about that!
<keescook> It's in the middle in https://wiki.ubuntu.com/SecurityUpdateProcedures
<norsetto> keescook: should I resubmit the patches?
<keescook> (step 4)
<keescook> norsetto: that would be great, yeah.  you can add the CVE too.  :)  thanks!
<norsetto> keescook: I'm quite sure its in there, but I got an headache in the middle of it :-)
<keescook> norsetto: hehehe, understood.  :)
<norsetto> keescook: any tip about the CVE? I actually tried to gather it, but I couldn't find a way to do it
<keescook> norsetto: I'm not sure what you're asking.  The CVE for this issue is already linked (on the left) to the bug report (CVE-2007-2958(
<keescook> norsetto: if you wanted to look for a CVE, you could start at http://cve.mitre.org/cve/cve.html
<keescook> and that gets you to http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sylpheed  which confirms the CVE-2007-2958
<norsetto> ok, got it now
<stgraber> asac: good, I'm finally back at home. Do you have anything you want me to try to fix that wpa_supplicant issue ?
<keescook> norsetto: thanks again for preparing all those patches!  I know it's a lot of work.
<norsetto> keescook: thanks for the comments, if you have anything else please let me know?
<keescook> sure, it looks good -- you're already using the built-in patching systems, so that's perfect.  :)
<norsetto> keescook: yeah, that saved some work :-)
<silwol> is this the right channel to get help in packaging best practices with bzr?
<Hobbsee> er, #launchpad or #bzr is better, i suspect
<silwol> okay, then i'll have a look there... thx Hobbsee
<iwj> Oh, bugger, debian-changelog-mode made me upload -2 rather than -1ubuntu2.
<Hobbsee> asac: is the updated ipw3945 driver in yet?  -10 seems to be there fo nm
<seb128> StevenK: yes
<seb128> StevenK: upload, if there is a breakage we can fix it
<iwj> Uh, do uploads to LP missing `ubuntu' in the version number silently disappear or something ?
<bryce> seb128: I have fixes to the BPX bugs you discovered yesterday
<bryce> seb128:  The core problem we ran into was that issue with kde-guidance not allowing the 'disable' keyword.  I have a tiny patch to fix this issue:  http://people.ubuntu.com/~bryce/Uploads/ kde-guidance*.  Would you or Riddell be able to upload this fix?
<calc> can someone bump stlport4.6 into main for me? :)
<calc> it was already in main in the past but fell back into universe
<bryce> I'm going to test the fixes for BPX and should have that upload ready in a little bit.
<Riddell> bryce: I'll do it (so I can put the patch upstream too)
<bryce> Riddell: excellent, thanks
<calc> Riddell: ^ ? ;)
* calc seems to recall Riddell having archive access
<Riddell> calc: let me look
<calc> Riddell: thanks :)
<calc> stlport5.1 fell back into universe recently, and it didn't seem to work properly with OOo anyway, but 4.6 does
<Riddell> calc: do you know why it was dropped?
<calc> Riddell: i believe it was due to doko using 5.1 for OOo for a while but it had issues
<bryce> Riddell: sebas says he's committed the fix upstream (lp #137683)
<ubotu> Launchpad bug 137683 in kde-guidance "[PATCH]  xorgconfig.py crashes on "disable" in Modules section" [Undecided,New]  https://launchpad.net/bugs/137683
<calc> i was using internal stlport in the meantime and stlport5.1 went back into universe recently
<Riddell> bryce: oh, cool
<calc> i think stlport 4.6/5.1 was only being used by OOo at least afaict
* calc hopes his other new MIRs don't fall back into universe before he gets the next OOo uploaded, heh
<Riddell> calc: done
<calc> Riddell: thanks! )
<calc> :)
<Riddell> will take the usual hour before the next publisher run
<calc> yea
<calc> it will be a while before my next upload i still have to verify that ooo-l10n-common isn't completely broken, which means a l10n build, heh
<calc> that takes quite a few hours
<doko> Riddell, calc: I'd rather use the internal copy now that OOo is the only user of 4.6 in main
<calc> doko: oh ok
<calc> doko: i can go back to using internal copy that is fine
<doko> then we don't have to support 4.6 in main
<calc> ok
<Riddell> calc: shall I demote again?
<calc> doko: would it be better to demote it or to have OOo use it instead of its local copy for security fixes, etc?
<evand> It's too late to get a package into universe then main, correct?
<calc> evand: depends on how important it is i think ;)
<calc> evand: if you make a really good case you may be able to get it done
<calc> evand: i got some stuff in that way just a week or so ago
<evand> I don't think it's critical.  It's the usplash for gobuntu.
<keescook> calc: odd, how did stlport5.1 end up back in universe?
<keescook> if it compiles against 5.1, I think we should try to use it.  4.x is totally unsupport upstream.
<calc> keescook: apparently only OOo used it and it didn't use it anymore due to issues with 5.1/OOo interaction
<keescook> bleh
<doko> calc: well, maybe, but I never did see an security update for stlport, and upstream plans to drop the use of stlport completely
<calc> i can try to see if i can get it to work with 5.1 i don't recall what the old issues with 5.1 were
<calc> doko: do you happen to know what the 5.1/OOo problems were?
<keescook> doko: they've had security issues, but they're mostly impossible to exploit
<calc> doko: oh if they are dropping using stlport altogether then i can just use internal copy in the meantime
<calc> Riddell: yea demote it
<calc> evand: new is frozen but there is exception process
<evand> ok, I'll give it a shot.  Thanks calc
<Riddell> down it goes
<doko> calc: crashes =)
<calc> doko: ok :)
<calc> crashes are fun >;-)
<calc> except when i get a lot of reports about it
<calc> lol
* calc looks at his todo list to see what else to stick in this build
<calc> doko: btw the changelog/copyright missing files issue had existed since sometime in 2.2.1, got it fixed with the current build though
<doko> nice
<calc> it appeared to be caused by the ordering of installchangelogs/installdocs along with some if stmts, but i'm not really sure when it was broken due to not finding the full history of the rules file from back then
<calc> its good now which is all that really matters
<calc> asac: you still here?
<geser> doko: re your mail to my libvte-java upload: the build fails with -I/usr/jvm/java-gcj-compat/include in CFLAGS: error: jni.h: No such file or directory
<doko> geser: -I/usr/jvm/java-gcj/include
<calc> doko: how is the icedtea debs coming along?
<doko> not ready for upload
<calc> ok
<bddebian> Am I supposed to poke someone about an upload to feisty-proposed, or do you folks just see it?
<jdong> they sense it...
<jdong> with their whiskers of archivedom...
<seb128> bddebian: we see it when we look at the queue but feel free to ping if you think there is an hurry
<bddebian> No no hurry, but if anyone is bored I uploaded a rebuild of mod-cband to feisty-proposed.  Though I think I did it a little wrong because I filed the bug after I uploaded so there is no reference in the changelog :-(
<bddebian> jdong: :-)
<geser> doko: still the same with -I/usr/jvm/java-gcj/include, jni.h isn't found
<bddebian> So fix it! ;-P
<jdong> lol :)
<doko> geser: $ ls /usr/lib/jvm/java-gcj/include/
<tkamppeter> doko, I have corrected HPLIP now.
<seb128> bddebian: upload accepted
<bddebian> seb128: Oh, excellent, thanks
<seb128> you're welcome
<doko> tkamppeter: looking
<geser> doko: ah, it's /usr/*lib*/jvm and not /usr/jvm as you told me twice
<doko> geser: dlocate jni.h usually helps ;)
<geser> doko: I used packages.u.c to find it in libgcj8-dev
<geser> doko: it works now. Should I reupload the java package with set CFLAGS instead of CC?
<doko> geser: not that important, keep it in mind for the next upload
<geser> doko: ok, thanks for your help
<seb128> evand: around?
<evand> seb128: ja
<seb128> evand: gobuntu-artwork-usplash usplash/usplash-theme-gobuntu.c is under GPL but the license text is not distributed in the tarball and that's not mentioned in the debian copyright
<seb128> evand: could you fix that?
<evand> seb128: whoops, sure thing
<evand> thanks for looking at it in the first place
<seb128> evand: xubuntu-artwork has the same bug, bonus point if you also fix this one ;)
<evand> will do
<seb128> thanks
<seb128> I'm rejecting your upload for now
<evand> still needs a version bump though, right?
<seb128> no
<evand> ok
<evand> seb128: can I upload it to upload.u.c, or will it reject it because I'm not in core-dev?  Sorry if this has an obvious answer.
<seb128> evand: are you a MOTU now?
<evand> yes
<seb128> evand: gobuntu-artwork-usplash has not been promoted yet so that's an universe package you can upload
<asisak> evand: IIRC you can upload to universe and multiverse, main and restricted will get rejected.
<evand> ah, I should've specified.  gobuntu I know is fine, but I'm assuming I'll have to upload xubuntu elsewhere for sponsorship, right?
<seb128> correct
<seb128> I'm happy to sponsor it for you
<seb128> just copy it on people.ubuntu.com or somewhere else
<evand> seb128: http://people.ubuntu.com/~evand/upload/xubuntu-artwork_0.18_source.changes
<evand> thanks!
<seb128> thank *you* for doing the work ;)
<asac> calc: ?
<mekius> hi, does the auto X configuration on the live cd only support loading drivers for nvidia/ati and all others just get vesa?
<asisak> evand: Another obvious question: can anyone have people.ubuntu.com access?
<evand> asisak: I believe you have to be a Canonical employee on the distro team or in MOTU or core-dev.
<asisak> I mean MOTUs or ubuntu members
<evand> MOTUs get access, afaik, but I'm pretty sure ubuntu members do not
<evand> mekius: It loads the same driver that it would use on an installed system
<calc> asac: sorry i forgot what i was going to ask you, if i remember i'll email you
<mekius> evand: ok, i'm trying to do a custom live cd, PC has a via video card, yet the vesa driver is chosen, how can i make it recognize the card?
<seb128> evand: can you mention before the next text that usplash/usplash-theme-gobuntu.c is the file under the GPL? The tarball also need to contain the GPL license text, you can copy /usr/share/common-licenses/GPL-2
<evand> seb128: sorry, will do
<evand> mekius: to be quite honest X is not my area of expertise.
<Kopfgeldjaeger> gn8
<mekius> evand: alright, wasn't sure if you knew somewhat how it handles that, do you know who would and when they are around?
<evand> seb128: actually, I'm somewhat confused.  What do you mean by "before the next text", and doesn't copyright already contain the GPL v2 text?
<ajmitch> asisak: no, only canonical people get access, MOTUs & other core-devs don't
<seb128> evand: in the copyright, do something like that
<evand> asisak: whoops, sorry for leading you astray there
<seb128> "usplash/usplash-theme-gobuntu.c:
<seb128> 
<evand> ohh
<seb128> This package is free software; you can redistribute it and/or modify
<ajmitch> evand: it's ok, it was discussed at a TB meeting sometime last year :)
<asisak> evand, ajmitch: thanks, I was asking because I did not now :)
<seb128> evand:  and the 10 lines you copied != license text
<evand> seb128: does ubuntu-artwork need to be modified then?  It doesn't do that.
<asac> calc: i think it was about nm/ipw ?
<evand> ok
<seb128> evand: ubuntu-artwork has no .c under the GPL, does it?
<dobey> hmm
<dobey> hey seb128
<seb128> ajmitch: hi
<seb128> hi dobey
<seb128> ajmitch: did you read what I wrote about f-spot yesterday?
<ajmitch> seb128: yes
<evand> seb128: ah, sorry, I was looking at the wrong package
<seb128> ajmitch: do you plan to do an upload or should I do one with this patch?
<ajmitch> seb128: yes I plan on doing an upload tonight (after work)
<seb128> ajmitch: ok, cool, thanks ;)
<evand> mekius: as I believe it's not a live cd issue, bryce would probably be the best person to answer questions as to which driver is used for which card and why.
* lamont looks around for a release manager
<seb128> lamont: what do you need?
* ajmitch should leave for work in approx -20 minutes ;)
<lamont> I just figured it'd be a good thing to double check before I upload util-linux_2.13-3ubuntu1 to replaces the 2.13~rc3 version already in gutsy
<lamont> it's only minor tweaks between them, etc, etc.  The intent was always to make it the non-RC version once it came out and had some time in debian to cook
<lamont> -1 hit debian on aug 27
<seb128> lamont: you want to ping Riddell or Hobbsee
<lamont> Riddell/Hobbsee: what seb128 said
<lamont> seb128: thanks
<seb128> no problem
<mekius> evand: alirght
<mekius> evand: i agree that it isn't a live cd issue, just want to know how it is determining which video card, so i will ping him
<mekius> bryce: ping
<Riddell> lamont: yeah, go ahead, assuming it's only bugfixes, final release is better than a candidate
<lamont> that was my thinking.  uploading
* lamont does one last diff first, just to look
<lamont> Riddell: most of the diff is po file updates
<lamont> bug fixes and debian/rules cleanup to make my life sane
<lamont> that last part being the reason I wanted to let it age in sid for a bit before I uploaded to ubuntu
<Riddell> lamont: all sounds fine
<lamont> thanks.  done.
<evand> seb128: http://pastebin.ubuntu.com/51/ , better or does it really need to have the entire GPLv2 rather than just the reference to /usr/share/common-licenses/GPL in there?  I know the lines I copied are not the entire license, but I thought that block was the proper debian procedure, no?
<seb128> evand: it needs the complete license text to be distribuable
<evand> am I missing something obvious?  No other packages seem to take this approach.  Ubiquity, for example, has the exact same block.
<seb128> hum
* seb128 apt-get
<seb128> evand: ubiquity has a d-i/source/console-setup/GPL-2
<seb128> evand: usually softwares have a COPYING and a COPYING.LIB
<seb128> which has the license text
<seb128> dunno why that's not the case for ubiquite, cjwatson should know ;)
<evand> ah, indeed
<evand> seb128: http://pastebin.ubuntu.com/52/ better? or should I just make a COPYING file?
<seb128> a COPYING file would be nicer
<evand> will do
<Riddell> I don't require the whole licence for a native package, but it's still best to have one
<evand> do I need to make a separate COPYING file for the artwork (licensed under CC SA), or is it suitable to put both licenses in the same COPYING file?
<Luke> asac: sent it to your ubuntu account. I'll open a but report though. I just didn't know if this situation would be acceptable for that.
<Riddell> evand: neater to have a separate one
<Riddell> evand: and make it clear which files have which licence
<evand> I figured as I saw that for DOCS, but is there a standard convention, something like COPYING-ART?
<Riddell> evand: no, but that seems a good suggestion
<evand> fair enough, thanks
<cjwatson> iwj: e2fsprogs? all your uploads (including -2) got rejected due to "No copyright file found." which means that debian/copyright doesn't exist, which LP recently started enforcing (mistakenly in my view)
<cjwatson> iwj: so you can safely go back to the -1ubuntu* versioning scheme
<cjwatson> iwj: but I see you already did so :-)
<xerakko> hi cjwatson
<evand> Can I have an extra pair of eyes on http://people.ubuntu.com/~evand/upload/gobuntu-artwork-usplash_0.1_source.changes before I upload it, particularly the license text and whether I finally got it right :)?
<mekius> hey, i'm doing the oem install and it makes you put in a password for the defautl user, how is a user who receives a computer with this oem account on it suppose to know how to login to make their account?
<cjwatson> mekius: the password is only for the oem customisation user
<cjwatson> mekius: after it's shipped to the end user, the end user will enter their own password
<mekius> how do they do this?
<cjwatson> mekius: the computer is not supposed to be shipped with the oem account still fully active
<mekius> ok
<cjwatson> mekius: per the instructions in the installer, you're meant to run 'oem-config-prepare', shut down, and then duplicate and ship
<mekius> ah ok
<mekius> sry :)
<cjwatson> that causes oem-config to pop up next boot
<mekius> ah ok, that is good, this makes sense now :)
<cjwatson> gutsy should be clearer, there'll be an icon on the desktop to run oem-config-prepare
<mekius> yep
<mekius> we are basing our cd on gutsy
<cjwatson> ah good
<mekius> well dvd heh, it's a bit too big to do a cd :)
<cjwatson> I just fiddled with oem-config today to actually make it use the right theme, only two years later ;-)
<mekius> now we replaced gnome with enlightenment, will it still boot up and run oem-config?
<mekius> or is it gnome specific?
<cjwatson> err
<cjwatson> I have no idea offhand
<mekius> ok, i will give it a shot :)
<cjwatson> oem-config's first-boot mechanism relies on metacity being present
<wasabi> damn. i really should see about spending this evening to fix mdadm/lvm2
<wasabi> what a pita.
<cjwatson> if you've removed that it probably won't work right now - also gnome-settings-daemon as of today, to make the theme work
<mekius> so when i restart after installing oem style, i just run the oem-config-prepare and probably answer some questions and on reboot it should give them something to create an account and such with?
<cjwatson> oem-config-prepare is noninteractive
<mekius> cjwatson: hmm, i see...
<mekius> cjwatson: any way you can think to hack around that limitation?
<mekius> it require gnome-settings-daemon?  doesn't respect a .gtkrc-2.0 in the users dir?
<cjwatson> sure, file a bug and tell me how I can go about starting up the enlightenment window manager by hand
<wasabi> Advice from udev pro's:   Currently during the initramfs boot, udev is used to activate MD volumes and also LVM volumes. Any suggestions on a design to alter teh way in which udev activates degraded volumes after a certain timeout?
<cjwatson> oem-config has its own tiny display manager that starts up the stuff it needs
<mekius> does it check for metacity and not run if it isn't running
<mekius> ?
<cjwatson> it runs some hardcoded programs
<mekius> ah ok
<mekius> i see
<cjwatson> I can make it try something else too, if I know what to trry
<cjwatson> try
<mekius> is it a binary, or a script?
<cjwatson> it's a python script, /usr/sbin/oem-config-dm
<wasabi> Who is the best person to talk to about the structure of initramfs' local-init/top/bottom?
<mekius> ok, so i could just modify it myself eh?
<cjwatson> mekius: yes
<mekius> ok, will give that a shot, thx for all the info :)
<mekius> you've been a big help
<cjwatson> I'm happy to integrate changes you send me to that
<mekius> yeah, will do :)
<mekius> you hang out here often, i can just ping you when i have something working?
<cjwatson> mekius: sure, or just file a bug on https://bugs.launchpad.net/ubuntu/+source/oem-config/+filebug, which will ensure I don't lose it
<mekius> ok :)
<paran> how is updates of new changelogs to http://changelogs.ubuntu.com handeled?
<paran> I it very often out of sync with the apt-archives which is quite annoying.
<mekius> cjwatson: is this just a gtk program then?
<mekius> ah i see :)
<mekius> cjwatson: i will submit a patch if we create our own version of this program, but until then i'm just gonna hack it
<cjwatson> mekius: no worries
<mekius> cjwatson: also, the oem-config desktop icon that is there after the initial install only shows in GNOME;XFCE; is this file easily editable or is it part of the oem-config package?
<cjwatson> it's copied to the desktop
<mekius> cjwatson: where is it stored?
<cjwatson> /home/oem/Desktop/ somewhere
* cjwatson -> bed
<mekius> alright, night :)
<mekius> gah, it deletes the configuration stuff setup on the live cd :/
<kevev> hello
<kevev> is this the place to ask for support on Gutsy Gibon?
* Spads looks at the topic
#ubuntu-devel 2007-09-07
<mneptok> eep. opp. ork. uh-huh.
<ajmitch> well said, mneptok
* mneptok bows deeply, tumbling off the stage
<zul_> evening
<bryce> Riddell: do you think you'll have a chance to upload the kde-guidance patch today?  http://people.ubuntu.com/~bryce/Uploads/
<wasabi> Um. Samba/Winbind problem: Winbind password cache is broken in gutsy package. It is fixed in Debian.
<wasabi> What's the procedure for asking for the package to be merged these days? And are we beyond that point in freeze yet?
<wasabi> Also why can I never find this stuff on the wiki heh
<bddebian> Heya
<pygi> morning bddebian
<bddebian> Hi pygi
<pygi> how are you doing?
<bddebian> OK thanks. Yourself?
<pygi> tired :P
<pygi> 2:17AM =)
<wasabi> keescook: Actually I think my entire post distils down into two things: a) My mdadm.conf wasn't updated. The wrong uuid was in it. Maybe that was my fault. b) 85-mdadm.rules does not specify --auto=yes
<mekius> anyone have any good ideas about how i could install google toolbar onto a custom live cd?
<mneptok> could someone please immolate NetworkManager? kthx luv u bai.
<zul> get right on it
<zul> oh hey mneptok
<mneptok> heya Zul
<mneptok> there is no Dana.
<Amaranth> bryce: why did you move bug 137745 back to compiz? it's a limitation in the X stack
<ubotu> Launchpad bug 137745 in compiz "compiz can only used by one user" [Wishlist,New]  https://launchpad.net/bugs/137745
<Amaranth> dri, drm, and/or the drivers, something nvidia doesn't use
<sbalneav> Evening all
<bddebian> Hey sbalneav
<sbalneav> hey there bddebian!
<sbalneav> Tomorrow's Fix It Friday for Edubuntu!!!
* sbalneav plans to put in 18 hours.
<sbalneav> Booked the day off work :)
<bddebian> w00t
<bluefoxicy> smoothest nipples i've ever felt
<bluefoxicy> I mean hi IN
* mode/#ubuntu-devel [+o bhale]  by ChanServ
<bhale> meh, both of you clean up your act
* mode/#ubuntu-devel [-o bhale]  by bhale
<bddebian> bhale: !!
<Hobbsee> <pin drop>
<bddebian> BOING
<Hobbsee> argh!
<keescook> wasabi: 85-mdadm.rules missing --auto=yes could be a bug, yes.  What things were you seeing going wrong with it?
<wasabi> Well, on my systems, it simpley "doesn't work". No MD devices appear in iniramfs and I go to console.
<wasabi> So, I usually run it manually
<wasabi> mdadm --examine --scan > /etc/mdadm/mdadm.conf
<wasabi> mdadm --assemble --scan --no-degraded --auto=yes
<wasabi> If I don't add auto, it doesn't work. Says /dev/md* doesn't exist.
<wasabi> Seeing that udev doesn't add auto......
<wasabi> On top of that my mdadm.conf did not have my arrays listed in it. The UUIDs were out of date. Probably because I reconfigured them at some point, or did not configure them from the installer. It makes me wonder if that file is even required though.
<wasabi> And udev can't just use --examine.
<ajmitch> curious
<keescook> wasabi: yeah, the initial creation of the mdadm.conf is critical to this, unfortunately.
<ajmitch> lvm & mdadm have been working fine for me in gutsy
<wasabi> Is there a reason we don't do --examine and auto detect?
<ajmitch> which would mean that I have a working mdadm.conf, I guess :)
<wasabi> Since we auto detect everything else, like LVM, I can't see why.
<keescook> wasabi: I thought we did, actually.
<keescook> wasabi: in that as devices appear, udev tries to start them up.
<keescook> I haven't tried having a totally empty mdadm.conf.
<wasabi> Well yeah, udev runs mdadm, but without --examine.
<wasabi> So it relies on the mdadm.conf copied during update-initramfs
<keescook> hm.  I'm of two minds: 1) it should auto-start everything!  2) zomg don't auto-start unless you expect it
<wasabi> Yeah. Completely contradictory.
<wasabi> If you pick 2, you have a *lot* of issues though.
<wasabi> Which I don't think we can reasonable solve right now.
<wasabi> That is, you shouldn't auto activate LVM either,e xcept for the root device.
<wasabi> And that means you should only active MD's which contribute to the activation of the LVM.
<wasabi> But no others.
<wasabi> Which is just too hard to think about.
<keescook> heh
<wasabi> root=md/UUID=UUID-of-MD;lvm/UUID=UUID-of-lvm
<wasabi> Get into crap like that.
<wasabi> Anways, --auto is a big ommisions. I'm not sure why yours works without it.
<wasabi> Unless something else is creating your md* nodes.
<wasabi> Clearly if I enter teh initramfs with mount=break, and run the mdadm command without --auto, it says no thanks.
<keescook> hunh
<keescook> I wonder why I have /dev/md* then.
<keescook> I need to get my vmware set up with multiple drives
<wasabi> I'm glad those scripts in local-top are gone though.
<wasabi> Those were maddening
<wasabi> Anyways, I sort of solved it by invoking mdadm twice from udev: once with --examine, another time without, using a temporary config file.
<wasabi> tmp=`mktemp`; mdadm --examine --scan > $tmp; mdadm --assemble --scan --auto=yes --no-degraded --config=$tmp
<wasabi> That automatically activates all non-degraded arrays known to the system, regardless of the user's mdadm.conf
<wasabi> I doubt that's suitable for you though.
<wasabi> Because it ignores superblock 1 arrays. ;)
<wasabi> or no-super block arrays, as they may be
<keescook> so, it seems that 85-mdadm is basically doing its best to start up all the known arrays (mdadm.conf) each time a new linux_raid type device shows up.
<wasabi> but i have no idea if those are supported anyways
<keescook> we could just say type 1 isn't support.  :)
<wasabi> Yeah, except for the lack of auto, that's fine. I still do not understand why you don't need auto.
<wasabi> auto is what makes the nodes for me. Nothing else does.
<keescook> yeah, I'm honestly a bit confused myself.
<wasabi> Do you have some option in mdadm.conf inferring auto?
<wasabi> I see, mdadm.conf supports auto added to a listed array.
<wasabi> Mine did not have that.
<keescook> nope, just DEVICE partitions followed by my ARRAY lines: ARRAY /dev/md0 level=raid1 num-devices=2 UUID=337ca5ec:8f193d47:50a102cf:df548069
<wasabi> Hmm. Yours doesn't either.
<wasabi> That file was... useful, with non-superblock arrays.
<wasabi> I don't think it's useful anymore.
<keescook> I don't see a reason why --auto=yes would _hurt_ anything -- I'm just curious why I don't need it
<wasabi> Well, jump into an initramfs in premount.
<wasabi> And run it. ;)
<keescook> which is odd considering Debian switched to requiring it
<keescook> I would but that woudl require me rebooting.  :)
<keescook> I'm tweaking a vmware profile atm
<wasabi> Another bug I've discovered is vgchange -a y is dangerous.
<wasabi> But that's another story.
<keescook> dangerous how?
<wasabi> If you plug in a drive from another LVM set, and it has the same name as an existing one on the system.
<wasabi> Activating it puts the system into a state that can't be repaired without rebooting.
<keescook> oh yeah, yeah yeah bad bad
<wasabi> Because it actually DOES activate the second named one, and result in the user space tools beind unable to distinguish them.
<wasabi> So ou can't unactivate it
<wasabi> If you vgscan, and then vgrename it, before activating it, it's fine.
<keescook> yeah, it's an f'in disaster
<keescook> I name all my vgs uniquely now.  I used to just use "systemvg" everywhere.
<wasabi> That might be a consideration for the installer to name them automatically.
<keescook> perfects example of "enable everything" seriously backfiring
<wasabi> Then again, simply preventing vgchange from doing that probably solves the real issue.
<wasabi> "Hey, you have tow of these! I"m not activating it!"
<wasabi> "Duh!"
<wasabi> We could use a dbus signal for broken arrays too.
<keescook> mdadm patch to poke hal!  :)
<wasabi> totally.
<wasabi> then a notification icon can be done
<keescook> vgchange> yeah, that would be a more sensible fix.  :)
<keescook> wasabi: hmpf, I was able to do a mdadm -C without --auto=yes
<wasabi> Weird. What's -C?
<wasabi> Ahh, specify config path?
<Hobbsee> evand: @ people.ubuntu.com - only canonical employees.  not core dev, not MOTU.  (unfortunately)
* Hobbsee has asked previously for access, and got told no :P
<wasabi> # auto-create devices with Debian standard permissions
<wasabi> CREATE owner=root group=disk mode=0660 auto=yes
<wasabi> keescook: I even have that in my file, but it no works.
<keescook> wasabi: -C is "create"
<wasabi> Hmm. What's creating an array have to do with it?
<wasabi> Should we be using UUIDs in /etc/fstab for LVM?
<Mithrandir> wasabi: I'm fairly sure you can just do dmsetup remove on the relevant devices and then run vgchange again.
<wasabi> LVM is pure dm?
<Mithrandir> wasabi: yes, like everything else in 2.6
<wasabi> cept md/
<Mithrandir> md can be too, at least for raid 1
<Hobbsee> good morning Mithrandir!
<Mithrandir> morning little green alien.
<wasabi> I'm off to bed.
<dholbach> good morning
<\sh> hey dholbach
<mdke> morning dholbach
<dholbach> hey \sh, hey mdke
<dholbach> mdke: you merged in the changes alright?
<mdke> dholbach: I'm doing it now
<dholbach> mdke: also changed the version number of the ubuntu-docs upload?
<dholbach> rock on
<mdke> dholbach: anything else change in ubuntu-docs?
<dholbach> no, just the version
<mdke> ok, all done. Thanks a lot dholbach for working on that
<dholbach> no problem :)
<MacSlow> greetings
<dholbach> heya MacSlow
<mdke> dholbach: I wanted to ask your opinion on something about the possibility of ubuntu-docs using bzr. It's basically this - https://lists.ubuntu.com/archives/ubuntu-doc/2007-August/009160.html
<mdke> dholbach: I thought since you know how the tree works, and how lp/bzr works better than me, you might have a view
<mdke> not urgent of course
<dholbach> mdke: I found the same: the initial checkout was fairly huge and took its time, also the first push to a new branch, but the subsequent merges and pushes were very quick
<dholbach> I support you switching to bzr, it's far more inviting than using svn - also lots of people are used to bzr-lp now
<mdke> dholbach: sorry, I meant more the second part of the email - speed is not a serious blocker for me
<mdke> the second part is more about how we could use lp to improve our current workflow
<dholbach> I'd also stick to the tradition of storing everyrthing in bzr - I don't think there's much sense storing the packaging in another branch
<dholbach> I don't think it's going to be messy to merge changes between different branches every now and then
<mdke> dholbach: so you'd have the same tree as now basically? with the kubuntu/edubuntu stuff there too?
<dholbach> you can have kubuntu and edubuntu branches, where those teams work and merge their changes every now and then
<dholbach> it's what we do for the seeds for example
<dholbach> kubuntu and edubuntu have changes of their own, but merge changes of the ubuntu branch all the time
<dholbach> like kubuntu-desktop and ubuntu-desktop differ, but they basically share ubuntu-standard
<mdke> so the common documents would be basically kept in each branch and kept up to date with each other?
<dholbach> I think that's reasonable
<mdke> interesting
<dholbach> I mean you can always change the workflow and improve it as you go
<mdke> true
<dholbach> you could even have a team of different contributors to kubuntu-docs (if that makes sense)
<dholbach> so the kubuntu-docs people can add people to their team, because they know them already
<mdke> i'm slightly concerned about the teams drawing apart, so i think it would probablybe better for ubuntu-doc-core or something to have commit rights to each, just to make sure everyone keeps working together and knows each other
<dholbach> right
<dholbach> you *can* keep them all in the same team namespace
<dholbach> ~ubuntu-doc/ubuntu-docs/ubuntu-gutsy
<dholbach> ~ubuntu-doc/ubuntu-docs/kubuntu-gutsy
<dholbach> ~ubuntu-doc/ubuntu-docs/edubuntu-gutsy
<dholbach> and so on
<mdke> sure
<dholbach> you wouldn't need new teams, but you could have them
<mdke> ok, that's very helpful, thanks
<dholbach> cool
<MacSlow> dholbach, what's the correct option to reinstall a package with dpkg? Just: dpkg -i --force package.deb?
<dholbach> MacSlow: sudo apt-get install --reinstall <package>?
<MacSlow> dholbach, not it's a local package... I compiled myself... skipping some patches for testing.
<dholbach> just    sudo dpkg -i bla.deb
<cjwatson> dholbach: though, one of these days when I have the time, I plan to merge all the seeds into one big honking branch
<cjwatson> I think
<dholbach> that sounds good and will save a lot of time, I guess
<cjwatson> only concern is what to do with non-core seeds like ubuntustudio and mythbuntu
<dholbach> right...
<cjwatson> the problem I want to solve is that there are certain seeds that are not logically separate (minimal is by definition the same no matter what flavour you are, for example), but we have to pointlessly merge them anyway or germinate gets confused
<kagou> Good morning
<siretart> morning
<siretart> are we still in freeze for tribe6?
<ajmitch> hi siretart
<siretart> hey ajmitch
<ajmitch> I think there's no tribe6 cd being done, so I don't think there's a freeze
<siretart> oh? it has been cancelled?
<dholbach> everybody hug thekorn: he implemented Bug.New() in python-launchpad-bugs
<StevenK> siretart: -devel-announce
<Mithrandir> dholbach: hm, 3.18 of bluez is out, both libs and utils, as well as 0.14.  It fixes some audio related bugs for me.
<ajmitch> see Riddell's message to -d-a about 3 days ago
<ajmitch> Mithrandir: what are my chances on a UVFe for samba 3.0.25c? it's a bug fix release that I'm wanting to merge
<dholbach> Mithrandir: wow... bluez upstream seems to be quite busy
<Mithrandir> dholbach: indeed, they're rocking quite a lot.
<dholbach> Mithrandir: I'm happy to work on the updates
<Mithrandir> dholbach: a quick uupdate here succeeded at least, but I'm wary of granting myself UVFe, so..
<Mithrandir> ajmitch: do you have the changelog somewhere?  And have you had the server team's input on it?
<siretart> StevenK: I'm now seriously confused. on -devel-announce, Riddell has announced that we should focus now on https://launchpad.net/ubuntu/+milestone/tribe-6 - but there was no mention on a target date, so I assumed the Schedule on GutsyReleaseSchedule is still authoritative
<ajmitch> I've talked to soren, and the release notes are at http://samba.org/samba/history/samba-3.0.25c.html
<ajmitch> diffstat is fairly small, and there are fixes from 3.0.25b-2 that we don't have either
<dholbach> Mithrandir: I can absolve :-)
<Mithrandir> ajmitch: I don't see anything particularly scary there, so if soren's happy with it, I say go for it.
<dholbach> Mithrandir: I think it's a good thing to update, I'm building the packages right now and will test them
<Mithrandir> dholbach: cheers
<dholbach> it gets time the mobile team takes care of them ;-)
<Mithrandir> yeah, it'll happen.. soon.
<dholbach> seb128: what do I need to do if I ship something in usr/lib/gstreamer-0.10?
<dholbach> seb128: run dh_scangstcodecs?
<seb128> dholbach: yes
<dholbach> thanks
<Riddell> siretart: there's no freeze, the task is to fix all the tribe 6 bugs
<StevenK> siretart: Yourself.
* StevenK chuckles
<siretart> I see
<StevenK> seb128: gimp uploaded, thanks for your help. :-)
<seb128> StevenK: thank you for the work on it ;)
<StevenK> Mithrandir: Would you mind digging through the logs on drescher to see why pilot-link was rejected? I'd just like a starting point.
<seb128> StevenK: there is a pilot-link upload gutsy-changes
<seb128> StevenK: what version has been rejected?
<Riddell> Mithrandir: could you give back kde4base 3.93.0-0ubuntu1~feisty2
<StevenK> Ahhh. I think someone else uploaded it.
<Mithrandir> Riddell: given-back
<seb128> StevenK: it's from Kitterman
<Mithrandir> 08:10:16 DEBUG   MD5 sum of uploaded file does not match existing file in archive
<Mithrandir> 08:10:16 DEBUG       Recipients: Steve Kowalik <stevenk@debian.org>, Scott Kitterman <ubuntu@kitterman.com>
<StevenK> Yeah, I saw that bit.
<StevenK> Ah ha. dholbach uploaded it.
<Amaranth> MacSlow: any idea why 132_composite-no-clipping.diff makes everything fall over?
<MacSlow> Amaranth, not atm
<Amaranth> "Needed by hildon-desktop to prevent home applets from clipping."
<Amaranth> it was disabled once for breaking X, then supposedly fixed
<Amaranth> err, for breaking compiz
<Amaranth> oh that is a pretty evil looking patch
<MacSlow> Amaranth, I don't know the history of that patch.
<Amaranth> MacSlow: "this patch changes the semantics of manual-redirect Composite windows so that they do not clip sibling or parent drawing"
<MacSlow> hm... I wonder what the Xorg folks have to say about that
<Amaranth> MacSlow: keithp wrote it
<MacSlow> sounds legit then :)
<Amaranth> apparently not :)
<Mithrandir> even Keith writes buggy code. :-P
<MacSlow> I've not tired gutsy with that patch applied on my i915... wonder if it would crash too then...
<Amaranth> i've heard reports but the main breakage seems to be nvidia
<MacSlow> not that OpenGL-apps would work/render correctly anyway under compiz... since redirected direct GLX isn't working with OSS-drivers yet
<Amaranth> there is a branch for that ;)
<MacSlow> Amaranth, well I tried that stuff from krh and airlied... but it only crashed my intel-laptop
<Amaranth> hehe
<MacSlow> haven't tried it since
<Amaranth> it probably only (sort of) works on their machines
<Amaranth> kind of like nouveau's randr-1.2
<MacSlow> airlied admitted that it is still super yound and very unstable
<Chipzz> 2619
<hunger> Where can I find out more about the xorg-amd driver I installed today?
<hunger> Never noticed it before... maybe I should use that:-(
<dholbach> cjwatson: are you OK adding bluez-gnome to the recommends of ubuntu-desktop? cf thread on ubuntu-devel@
<dholbach> if so, I'd just add it right now and do a ubuntu-meta upload
<seb128> dholbach: do it, you already got an approval from mdz and you have a +1 from me ;)
<dholbach> rock on - that should be good enough ;-)
<mvo> dholbach++
<ajmitch> hi mvo :)
<mvo> hey ajmitch
<cjwatson> dholbach: fine by me
<Mithrandir> hmm, I'm making UME create a default user that the UI runs as.  I think I'll be creating /home/ume for it, since the user may well want to store downloaded media or similar there.  Does anybody have a concern over a package creating a user with ~ in /home?
<iwj> cjwatson: Yes, I spotted that.  I was confused because one of the mails about the rejections took much longer to arrive.
<dholbach> cjwatson: thanks, done
<siretart> how does gdm figure out what the display size is? I have a laptop here where xorg-driver-intel and gdm seem to disagree: gdm thinks 1024x768, but the driver is using 1280x800
<siretart> (reported as bug #136783, FYI)
<ubotu> Launchpad bug 136783 in ubuntu "not using whole widescreen" [High,Confirmed]  https://launchpad.net/bugs/136783
<Kopfgeldjaeger> hi
<ogra> hmm
<ogra> all isos are oversized ?
* ogra takes that back ... all isos that are not kubuntu seem to be oversized
<noah__> not a problem if you're using vmware though. :)
<ogra> well, we didnt release a tribe6 CD but imho we should at least have usable isos
<ogra> (it isnt a problem if you use DVDRW either for the CD isos or 800M media, but thats not the point)
<Riddell> bryce: kees seems to have uploaded guidance before I got to it
<pygi> doko, is my survey done?
<xerakko> cjwatson: hi
<cjwatson> hello
<xerakko> cjwatson: Hi
<xerakko> I'm working in LliureX
<xerakko> an edubuntu based distro
<xerakko> and we are going to use
<xerakko> germinate
<xerakko> Have you written any documentation?
<xerakko> about seeds format
<cjwatson> man germinate
<xerakko> cjwatson: In gutsy... ok
<xerakko> thanks
<ogra> xerakko, oh, wow, LliureX bases on edubuntu now ?
* ogra wasnt aware !
<xerakko> yes :)
<ogra> thats awesome news
<ogra> mjg59, ping
<mjg59> ogra: Hi
<ogra> hey
<ogra> mjg59, would it be very evil to add dhcpd to the acpi scripts by default zto fix bug 48212 ?
<ubotu> Launchpad bug 48212 in ltsp "ltsp's dhcpd fails after server is hibernated" [Wishlist,In progress]  https://launchpad.net/bugs/48212
<mjg59> It would be, yes
<ogra> why ?
<ogra> if i suspend a server i'd like to have all services back
<mjg59> If the package needs special casing, have the package drop scripts into suspend.d and resume.d
<ogra> ah, ok
<ogra> i'll look into that, thanks
<sits> hi
<sits> who do I talk to about problems with http://codebrowse.launchpad.net/ ?
<azeem> sits: #launchpad, I'd say
<sits> azeem: cheers
<iwj> Gah, the daily is oversized so I can't check my e2fsprogs fix.
<ogra> iwj, all of them are :/
<ogra> iwj, i resorted to DVDRW for a quick workaround
<seb128> Riddell: what do you think about https://bugs.launchpad.net/ubuntu/+source/beagle/+bug/134341/comments/6 ?
<ubotu> Launchpad bug 134341 in beagle "beagle ftbfs" [High,Fix committed] 
<seb128> Riddell: that's an uvf for the new beagle
<seb128> Riddell: the current version doesn't build and the new one seems to be mainly bug fix
* Riddell looks
<Riddell> why is beagle in main anyway?
<sits> Riddell: I guess we all love searching
<Riddell> seb128: changelog looks fine, if it fixes the fail to build and has been decently tested then go ahead
<Riddell> sits: sure, but it duplicates the two other desktop search engines we have in main
<seb128> Riddell: because nautilus and yelp build with libbeagle to have support for it at runtime
<seb128> Riddell: thanks
<Riddell> oh yes, I remember now
<sits> Hmm I can search my help... OK I didn't know that
<sits> I wonder if I should publish an email detailing the types of bug reports and types of replies (complete with tongue in cheek humour)
<rausb0> is it possible to blacklist a module on syslinux boot prompt when booting the live cd?
<sits> rausb0: which one?
<rausb0> feisty
<jdong> I don't think so....
<rausb0> hmm. that's bad.
<jdong> what module is causing you problems?
<rausb0> 8139too
<jdong> what's the problem with it?
<rausb0> it causes a complete hang when loaded. if built with pio instead of mmio, it works.
<jdong> interesting....
<rausb0> jdong: the machine is a cheap noname notebook (actual manufacturer is twinview)
<jdong> perhaps there's a way to disable detection on the alternate installer
<asac> ogra: fyi, bug 123808
<ubotu> Launchpad bug 123808 in network-manager "NetworkManager Applet does not recognize ethernet bonding.  " [Undecided,Won't fix]  https://launchpad.net/bugs/123808
<rausb0> jdong: maybe, but in this case i just wanted to boot the live cd to test 3d h/w accel for the i945gm card
<jdong> rausb0: try 8139too.blacklist=true
<rausb0> jdong: thanks, i will try that
<jdong> rausb0: according to http://d-i.alioth.debian.org/manual/en.sparc/ch05s02.html it is valid for debian-installer
<jdong> (I am not sure if it'll work on the LiveCD though :(
<rausb0> jdong: oh, okay
* jdong peeks in initramfs source...
<rausb0> jdong: i disassembled the initramfs of the live cd and it looks like udevtrigger loads modules according the present hardware
<jdong> right
<asac> ogra: how about disabling network manager in thin client setups?
<jdong> the debian-installer writes a /etc/modprobe.d/blacklist.local
<jdong> that instructs udev not to load the module
<rausb0> jdong: creating the blacklist from the command line would be a very useful addon to the live cd too
<jdong> rausb0: I can't find any blacklister in casper (the livecd system)...
<jdong> rausb0: I agree, it should be a feature request to casper
<rausb0> jdong: is casper a ubuntu/debian only thing?
<jdong> rausb0: casper is the Ubuntu livecd engine
<rausb0> jdong: so its specific to ubuntu?
<jdong> correct
<rausb0> alright
<sits> rausb0: did you say the module worked in some circumstances?
<rausb0> sits: it works when compiled with other compile time options, yes
<sits> rausb0: ah ok
<jdong> (which might be mutually exclusive with another set of hardwrae...)
* jdong has a desktop that uses rtl8139too, and it works fine currently.
<rausb0> sits: CONFIG_8139TOO_PIO=y
<sits> ok
<sits> I was wondering if it was a run time module option
<rausb0> jdong: yeah, this crappy twinview notebook is the first machine i came across which has problems with 8139too
<jdong> http://ubuntu-unleashed.blogspot.com/2007/08/howto-customize-your-own-ubuntu-live-cd.html
<jdong> EEP.
<jdong> if you want to rebuild the LiveCD.....
<jdong> (it's just about the ugliest way to get the job done :D)
<jdong> is there a postmount breakpoint in initramfs?
<rausb0> jdong: i thought abount remastering too, but it would be much better if it runs with the normal live cd and just some boot param tweaking
<jdong> rausb0: there actually may be.
* jdong looks thru initramfs again
<rausb0> sits: no PIO in modinfo 8139too..
<jdong> anyone remember how break=init would work?
<jdong> I'm thinking we should break=init, then sabotage the 8139too.ko module, then continue booting
<rausb0> jdong: :)
<jdong> I forgot how to continue booting after a break=
<jdong> ugly, but would work.
<Mithrandir> "exit"
<jdong> cool
<rausb0> jdong: maybe:  exec /scriptname
<jdong> well that was easy (tm)
<sits> jdong: would you even need to break?
<jdong> sits: why not?
<jdong> sits: I'd expect as soon as udev starts on the main fileystem, the network card would get probed
<sits> jdong: I'd have thought you could drop yourself to a shell assuming you didn't need something fundamental to typoe like USB
<jdong> sits: eep or maybe 8139too is in initramfs.
<rausb0> jdong: problem is, the 8139too is already in initramfs
<jdong> rausb0: ok, then break earlier....
<jdong> rausb0: break=modules
<sits> jdong: ah I hadn't thought it would be initramfs. Would it be loaded right away though or only when a udev script kicked in?
<jdong> then just rm /lib/modules/wherever/8139too.ko
<jdong> wow this sounds so hackishly wrong :D
<ogra> asac, sure, would make sense
<rausb0> i didn't know this breakpoint thingy when booting, cool!
<jdong> thanks Mithrandir :)
<asac> ogra: i assign the bug to you then :)
<sits> jdong: what is reading break?
<jdong> sits: init script in initramfs
<jdong> sits: see /usr/share/initramfs-tools/init
<ogra> asac, well, i cant get around having nm in edubuntu-desktop (which is used in ltsp setups as well)
<jdong> there are several points where it calls maybe_break
<jdong> at various stages before bootup
<sits> jdong: interesting. I'll have to remember that
<asac> ogra: ogra so what could we do?
<ogra> asac, will nm touch anything without the applet running ?
<asac> ogra: yes i think so
<ogra> gah
<asac> i think only things that need user interaction won't happen without applet
<sits> I guess while I'm here can I get someone to rate the importance of a bug?
<asac> e.g. enter wpa key et al
<sits> asac: it might do scanning
<ogra> well, i have no wlan here if i'm not logged in (my nm isnt up to date though)
<sits> asac: (if networking is enabled) and that might bring the interface up but I haven't looked too closely
<asac> ogra: yes, but as sits points out it probably scans, doesn't it?
<ogra> and the dhcp server interface for ltsp is set up b ythe installer ain /e/n/i
<asac> sits: i think for open networks that might happen ... yes.
<Hobbsee> asac: the -10 upload of nm includes the fix that's fixed my ipw3945, presumably?
<sits> asac: does it just build up a network list
<asac> Hobbsee: no
<sits> (or does it still need prompting by nm-appklet for that?)
<asac> Hobbsee: i need module update first, because i drop a workaround in 11 that helped some wpa ipw3945 users
<Hobbsee> asac: ah right
<sits> asac: I've rebuilt one of your ipw3945 modules btw
<ogra> asac, so as long as nm doesnt touch static interfaces in /e/n/i nm shouldnt be a problem, i think bonding is a *very* special case
<asac> ogra: i will stop nm touching anything in e/n/i
<asac> ogra: thats the idea ... mail to u-d should go out today
<ogra> well, it doesnt now, just dont re-enable it :)
<asac> ogra: no you don't understand ... nm shouldn't even touch auto dhcp interfaces
<ogra> (using 0.6.5-0ubuntu9)
<asac> ogra: so its not a problem for you then i guess
<ogra> oh, ah
<sits> asac: I was having DHCP issues on an open AP (which I'm no longer near). Would the problem manifest on encrypted APs too?
<ogra> well, the fix for the bug reporter would be to just define all his bonding stuff in /e/n/i ... right
<asac> sits: on wep yes ... on wpa it might work without that patch
<sits> asac: ah I'm on a WPA network at the moment. OK
<sits> (and I'm using different drivers to boot)
<asac> sits: so what does modinfo show as version for you now?
<asac> sits: i remember that you were not able to setup the right module
<ogra> asac, what would help i guess (since he talks about thin client users changing the interface) would be if the autostart script of nm-applet would exit 0 if LTSP_CLIENT is set (which is the case on all ltsp clients)
<sits> asac: I'm on different drivers (iwl, hand built) but let me check the ones on disk I built an hour ago
<asac> ogra: ok but then why don't you just disable nm-applet?
<asac> sits: were did you get those from?
<asac> my branch?
<sits> asac: yup
<sits> asac: 1.2.2d.ubuntu1
<asac> ok
<asac> sits: if you have that module ... pleast try wpa with the latest opennet nm branch
<sits> asac: I doubt I have the space to build network-manager I'm afraid
<ogra> asac, i use edubuntu-desktop on workstations, liveCD etc ...
<sits> (I have all the bits but only 34Mbyte of space available)
<asac> sits: no garbage?
<sits> Let me just throw away the unpacked linux-source
<asac> sits: that should be enough ;)
<sits> OK back to 328Mbytes
<sits> (I tried to build nm before so I now I have all the deps)
<sits> s/now/know
<asac> k
<sits> asac: right where's this branch of yours, will it have the patches applied and how do I load the new NM rather than the old one?
<asac> sits: you can either just start ./NetworkManager from src/ directory when the build is through ... or install the .debs
<asac> sits: https://code.launchpad.net/~asac/network-manager/ubuntu.0.6.x.dev.opennet
<sits> asac: remember - I'm currently on a WPA network. Is that OK?
<asac> yes
<StevenK> infinity: sejong currently hates life: NOT OK : <socket.timeout instance at 0x2ad19eafb0e0>
<asac> that branch drops a hack that helped nm to connect for ipw3945 for some ... so its likely that wpa will break with old ipw driver but should work with new.
<asac> sits: ^^
<Hobbsee> people, how do i get rid of 'X Error: BadDevice, invalid or uninitialized input device 171'?  what actually is it?
<ogra> seb128, http://people.ubuntu.com/~ogra/fusa.png shouldnt ogra2 have a checkmark as well here ?
<jdong> Hobbsee: wacom
<jdong> Hobbsee: look in xorg.conf for tablet devices
<Hobbsee> ah, right.
<Hobbsee> jdong: thanks
<jdong> sure thing
<sits> asac: (just preoccupied filing a bug)
<seb128> ogra: it's should be unsensitive and checked yes
<seb128> ogra: works for me, does it happen on a normal desktop or only on ltsp?
<ogra> seb128, yes
<ogra> i assume it checks DISPLAY
<seb128> ogra: yes what?
<ogra> hehe, sorry
<ogra> only on ltsp
<dholbach> calc: can you please take a look at bug 133793 and ACK the sync request, if it's ok?
<ubotu> Launchpad bug 133793 in openoffice.org-voikko "Please sync openoffice.org-voikko from Debian" [Medium,Confirmed]  https://launchpad.net/bugs/133793
<dholbach> also bug 134112
<ubotu> Launchpad bug 134112 in openoffice.org "added Xb-Npp-xxx tags accordingly to "firefox distro add-on suport" spec" [Undecided,New]  https://launchpad.net/bugs/134112
<dholbach> hey mako
<ogra> seb128, do you have a possibility to disable autostart if LTSP_CLIENT is set so it doesnt show up on thin clients ?
<ogra> (i'm fine to make a patch if not)
<sits> seb128: I'm seeing the screensaver kicking in during totem-mozilla. It seems to have been reported before and fixed but I'm looking for where
<seb128> ogra: what do you mean? Like doesn't start things in /etc/xdg/autostart?
<sits> seb128: any quick ideas (otherwise I'll file a new bug)
<Hobbsee> TheMuso: ping
<seb128> sits: there is a bug about it
<ogra> seb128, yeah, or just exit 0 if LTSP_CLIENT is set
<seb128> ogra: it requires code patch but that's trivial, can you open a bug?
<ogra> seb128, sure
<seb128> ogra: are you sure you don't want things like things like the print applet being started on ltsp clients?
<sits> seb128: I've found a closed one that makes reference to another one but I haven't found an open link yet
<ogra> seb128, i only dont want fusa
<ogra> and nm-applet
<seb128> ogra: hum, you just asked to disable autostart on ltsp no?
<ogra> no
<seb128> <ogra> seb128, do you have a possibility to disable autostart if LTSP_CLIENT is set so it doesnt show up on thin clients ?
<ogra> i asked to disable autostart of fusa on ltsp clients
<seb128> ah
<ogra> sorry
<seb128> that's tricky
<ogra> my bad
<seb128> the applet is part of the panel profile
<seb128> that's not an autostart
<ogra> just add "if getenv(LTSP_CLIENT) then exit 0" at the top of fusa ?
<seb128> we would change it to a "display the usersname" thing though ;)
<ogra> its still its own binary i guess
<seb128> well, if it exit 0 the panel will complain that an applet has exited and ask if you want to reload it I think
<ogra> oh, evekn with proper exit status ... ? thats bad indeed
<ogra> seb128, thats the panel profile in gconf ? or something hardcoded ?
<seb128> ogra: gconf
<seb128> ogra: the key have no fixed path though and are user datas after first startup
<ogra> yeah, i see /usr/share/gconf/defaults/05_panel-default-setup.entries
<sits> seb128: OK I see http://bugzilla.gnome.org/show_bug.cgi?id=425469 . Thanks for the tip off
<ubotu> Gnome bug 425469 in Browser plugin "Browser plugin should inhibit screensaver" [Normal,Resolved: fixed] 
<seb128> ogra: making the applet display the user name would not be good enough for you?
<ogra> my prob is that i want fusa on workstations and live systems ....
<ogra> thats fine
<seb128> k, I'll do that then
<seb128> can you open a bug on fast-user-switch-applet?
<seb128> so it gives an indication of who is using the computer and doesn't look weird
<ogra> so you just disable the pulldown menu ?
<ogra> sounds good :)
<seb128> ogra: yes
<seb128> ogra: or make it display one line with "no user switching on thinclient" or something like that maybe
<ogra> yeah, prevents bug reports
<dholbach> calc: also bug 5462
<ubotu> Launchpad bug 5462 in mc "Dutch translation: wrong shortcut" [Medium,Confirmed]  https://launchpad.net/bugs/5462
<ogra> Bug #137980
<ubotu> Launchpad bug 137980 in fast-user-switch-applet "fusa should respect thin clients and not offer user switching but show the logged in username" [Undecided,New]  https://launchpad.net/bugs/137980
<sits> seb128: ok you've managed to head off one bug today what about this one (again I've done a quick search but nothing has come up)
<sits> seb128: gnome-power-manager still "reports" laptop battery information when battery is removed on the fly
<seb128> sits: dunno about gnome-power-manager, that's maintained by ogra
<sits> seb128: diverted again!
<seb128> ;)
<sits> seb128: you're doing well today :)
<sits> seb128: this isn't over - I'll be asking you again soon enough
<sits> ogra: gnome-power-manager still "reports" laptop battery information when battery is removed on the fly - is that a known bug?
* sits does some hasty checking
<ogra> sits, i really only care for g-p-m packaging in the recent times ...
<dholbach> doko: do you think the fix for bug 137909 is OK as it is?
<ubotu> Launchpad bug 137909 in libobjc-lf2 "FTBFS on ia64 and lpia" [Undecided,Confirmed]  https://launchpad.net/bugs/137909
<sits> ogra: where does a bug on g-p-m go?
<ogra> to LP
<doko> dholbach: does upstream really encode the debian architecture name in their config system? lpia ...
<dholbach> doko: I have no idea - it's a sponsoring bug that I'd like somebody to look at - I have no idea if this is the right way to fix it
<seb128> sits: upstream is using bugzilla.gnome.org though
<ogra> seb128, but richard regulary visits LP and goes through bugs there
<sits> seb128: I can never tell if it's an Ubuntu specific feature
<sits> seb128: OK what about this bug -
<seb128> ogra: ok, nice
<sits> seb128: rhythmbox segfaults while holding down enter on aesop's fable example ogg?
<seb128> sits: do you have a backtrace of the crash?
<ogra> seb128, i hope that wont change now that he's RH employee
<dholbach> doko: would you mind following up on the bug?
<sits> seb128: it would be useless because I don't think I have debug symbols installed
<sits> it's highly reproducible though
<sits> (I'll see what I get)
<sits> hmm no segfault immediately this time but the application has locked up
<dholbach> mvo: also bug 134490
<ubotu> Launchpad bug 134490 in apt-watch "Please merge apt-watch (0.3.2-9) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/134490
<sits> seb128: ok got a backtrace but its mostly ??
<sits> only
<sits> #8  0xb7edc58a in rb_entry_view_set_state ()
<sits>    from /usr/lib/librhythmbox-core.so.0
<sits> #9  0x080708bb in rb_shell_player_playpause ()
<calc> dholbach: ok i'll look at them, thanks
<dholbach> calc: thanks a lot
<seb128> sits: where do you do enter?
<ogra> mjg59, http://paste.ubuntu-nl.org/36687/ do you think that would be ok ?
<sits> seb128: you have to have it hightlighted in the list of tracks
<sits> seb128: so import /usr/share/example-content/fables_01_01_aesop.spx
<sits> seb128: then highlight fables_01_01 etc at the bottom
<seb128> sits: k, I get the bug easily
<sits> seb128: then hold down enter/return for five seconds and let go
<sits> seb128: sorry I haven't written up good steps yet
<sits> seb128: if it's unreported I'll file it
<bddebian> Heya
<dholbach> Riddell: there are two qt4-x11 patches on http://daniel.holba.ch/sponsoring - do you think you can take a look at them with your next qt4-x11 upload?
<Riddell> dholbach: yes, I know, they're still on my todo
<seb128> sits: you can open a bug about it
<Riddell> maybe I can do them today before I go away
<dholbach> okiedokie
<dobey> hey dholbach
<sits> seb128: ok will do
<dholbach> hey dobey
<dobey> what's up?
<seb128> hi dobey
<dobey> hey seb128
<dholbach> mvo: there's also some smart goodness in bug 116222 :)
<ubotu> Launchpad bug 116222 in smart "Smart launcher not added to Menu" [Undecided,Confirmed]  https://launchpad.net/bugs/116222
<mvo> dholbach: looks like you are in cleanup mode today
<dholbach> YES :)
<pygi> hey dholbach :)
<dholbach> hi pygi
<infinity> StevenK: All fixed.  And back to my sick bed with me. :/
<ion_> Yay for dpkg triggers. In the previous dist-upgrade, there would have been three runs of ldconfig and two runs of update-initramfs otherwise.
<StevenK> infinity: Feel better soon.
<StevenK> Ooh. update-initramfs is now down with triggers?
<StevenK> Excellent.
<lamont> can we have texlive-$lang crap use triggers, too?  or do they already (or did that happen after we stopped syncing sid for gutsy?)
<ion_> lamont: The change would be trivial.
<cjwatson> ogra: the Depends: acpi-support is wrong
<ogra> cjwatson, well, it wont work without the dirs ...
<cjwatson> ogra: there's no reason why it needs to depend on acpi-support just to ship some files to enhance acpi-support's behaviour
<ogra> oh, wait, sbalneav has a mkdir in there
<cjwatson> ogra: err
<cjwatson> ogra: you *do* know that dpkg creates directories on installation, don't you?
<ogra> heh, yes
<cjwatson> and that the dependency would have made no difference to getting the files in place in debian/rules anyway?
<ogra> yeah
<cjwatson> so, kill the bogus dep :)
<ogra> will do :)
<cjwatson> as written it will break dhcpd on architectures without acpi-support too
<sbalneav> Sorry for the dep :(
* sbalneav hangs head in shame
<cjwatson> not a problem
<ogra> sbalneav, since it was my suggestion dont hang your head
<ogra> tsk
<ogra> canadians
<ogra> <-- is to blame, dont belive him
* Hobbsee blames the new zealanders instead.
<asac> cjwatson: do you have power to approve my post to kernel list?
<cjwatson> asac: no - try BenC or lamont
<sits> is the source symlink in the lib directory of a running kernel a standard thing?
<BenC> kyle and lamont
<BenC> sits: yes
<sits> BenC: when does it get made?
<sits> BenC: just on installation of the headers?
<sits> or installation of something else?
<BenC> sits: it's standard, but we don't use it
<BenC> we use a build symlink
<BenC> which gets installed by the matching linux-headers package
<BenC> build is standard too
<sits> I see build
<sits> but I see no source
<sits> (but checking another distro like Fedora shows a symlink from source -> build, and checking SUSE shows two symlinks with the source one currently broken)
<BenC> source is pretty useless in practice
<BenC> unless you do a lot of local builds
<sits> I was wondering whether source was legacy or just on those distros which also ship fully compiled source (seemingly rare)
* lamont walks the kernel-team list
<asac> lamont: gratias
<sits> BenC: so source isn't made for distro kernels but may be made on others?
<BenC> lamont: can you send me admin pw for kernel-team?
<BenC> sits: for the most part, source link is optional...it's the build link that matters for third-party module compiles
<sits> BenC: I see
* BenC has to run
<sits> BenC: thanks!
<BenC> np
<lamont> asac: done
<lamont> BenC: admin or moderator?
<lamont> and yes.
<lamont> moderator is easy (I know that one).. admin will take me a little work to dig up
<BenC> lamont: just to moderate
<mjg59> ogra: Lose the depends on acpi-support?
<mjg59> Nothing will break if it's not installed
<ogra> mjg59, already happend, cjwatson chimed in here :)
<mjg59> Ok, cool
<ogra> thanks for looking
<sits> right time to test that asac driver
<asac> sits: kernel team is already looking ... feedback still appreciated though.
<ddaa> Is the gnome-panel "Run Application" dialog known to leak memory like an Alzheimer patient?
<seb128> no
<mr_pouit> ogra: edubuntu is probably affected by Bug #115952... (I just fixed xubuntu gdm-cdd.conf)
<ubotu> Launchpad bug 115952 in gdm "Gutsy: No users are shown in GDM" [Low,Fix released]  https://launchpad.net/bugs/115952
<ddaa> seb128: want to try something for me, then?
<seb128> ddaa: yes?
<ddaa> start top, or the gnome system monitor process list
<seb128> hi mr_pouit
<ddaa> look at the gnome-panel's memory usage
<mr_pouit> hi seb128
<ddaa> start the "Run application" dialog
<ogra> mr_pouit, that enabled the browser all the time ?
<ddaa> type one letter, say, "g"
<ddaa> close the dialog
<ogra> s/enabled/enables/
<ddaa> I have the impression that the completion list stuff has a serious leak
<seb128> right,
<seb128> it goes up around 0.1meg every time
<ddaa> more for me
<ddaa> up to 1MB every time
<mr_pouit> ogra: themes without browser are still ok, but themes with user lists won't show any user if Browser=True
<ddaa> was wondering why it was bloating up to hundreds of MB...
<mr_pouit> s/True/False/ sorry
<seb128> ddaa: can you open a bug on gnome-panel? I'll have a look later with valgrind
<ddaa> sure
<seb128> thanks
<ddaa> gtk bugz ftw!
<seb128> heh
<ogra> mr_pouit, i'm not even aware we have en edubuntu browser theme :) i'll check that
<seb128> ogra: you don't need to, that will break any browser theme selected
<seb128> ogra: like if users switch from the edubuntu theme to the GNOME one with browser
<ogra> seb128, oh, right, .conf != theme file, i should stop working for the day
<mr_pouit> yeah, I just switched from xubuntu to human with browser to try, and it was broken. I guess this is the new default behavior since gdm 2.19.
* ..[topic/#ubuntu-devel:mako] : mako
<mako> ergh, can someone undo that
<mr_pouit> seb128: thanks for "fixing" gnome-system-tools btw :)
* ..[topic/#ubuntu-devel:thom] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | UVF in place | Tribe 5 out
<thom> topicdiff++
<seb128> mr_pouit: no problem ;)
<mako> thom: thanks dude :)
<mako> dholbach: hey dude
<thom> no worries mate :)
<kekZpriester> what is uvf?
<lamont> kekZpriester: upstream version freeze
<kekZpriester> thx lamont
<ddaa> seb128: bug 138006
<ubotu> Launchpad bug 138006 in gnome-panel "Memory leak in "Run Application" dialog" [Undecided,New]  https://launchpad.net/bugs/138006
<seb128> ddaa: thanks
<ddaa> mh
<ddaa> I wonder if my having "assistive" stuff enable makes the leak more serious
* ddaa disables and tries again
<ddaa> brb
<xhaker> seb128, sorry for messing up the changelog entries. I had my doubts if I should add the debian ones on a merge.
<xhaker> seb128, talking about #137531
<seb128> xhaker: if you merge on Debian everything from the debian version should be there
<seb128> xhaker: that's basically taking the debian version and adding ubuntu changes
<seb128> ddaa: likely due to a11y yes
<ddaa> bingo, it leaks a lot less with "Assistive Technologies" disabled
<seb128> ddaa: or a a part of if, because it's going up there but quite slowly
<xhaker> seb128, but we do keep the ubuntu changelog entries too right?
<seb128> xhaker: some people do
<ddaa> without it, I observer the same as you, about 0.1MB every time
<seb128> I don't usually, just summarize in the new changelog entry, but I think most of other people keep those
<seb128> ddaa: could you also note what you disabled in the bug?
<ddaa> Yup, coming back to the bug.
<xhaker> seb128, it looks weird with them I know. I kept them. i've attached a fixed debdiff.
<ogra> asac, any big objections against something like that: http://paste.ubuntu-nl.org/36698/ ?
<seb128> xhaker: thanks, I'll do a work break soon but I'll look at that again later
<xhaker> seb128, should be in your mail queue nevertheless :)
<asac> ogra: can't this be done outside of nm-applet somehow? otherwise its ok to have it i guess.
<seb128> cool
<ogra> asac, (yes its missing brackets, i mean the concept)
<ogra> asac, well nm-applet is the most proper place to do it
<terlmann> would you devs consider , in future, implementing kernel code that would allow a system reset without a full reboot ?
<asac> ogra: the brackets are not the main problem, but the patch direction :)
<ogra> otherwise i'd have to go for the autostart function of gnome-session and start maintaining white/blacklists or so
<asac> ogra: ok... if you want it pleaes attach it to some bug against network-manager-applet ... as i will start working on applet soon'ish
<ogra> asac, well, surggest something better :) thats the usual way we use to make apps behave on thin clients
<asac> ogra: ok then thats fine ... is that env distribution specific or an agreed universal standard?
<asac> (read: is it worth to get this upstream) ?
<ddaa> seb128: bug updated
<ogra> asac, i'll put it on bug 123808 since its a part of the fix for that
<ubotu> Launchpad bug 123808 in network-manager "NetworkManager Applet does not recognize ethernet bonding.  " [Undecided,Won't fix]  https://launchpad.net/bugs/123808
<asac> ogra: ok ... pleaes retitle the bug in that turn as well :)
<asac> ogra: and reopen/confirm obviously ;)
<asac> ogra: ah ... and reassign to -applet (if you want)
<ogra> yup, will do
<ogra> now to find a title where i dont have to dicuss 2h with the reporter about :P
<terlmann> rot-13 ?
<asac> ogra: remember that users can still just send dbus messages manually ... if that bothers you.
<ogra> no, it doesnt :)
<ogra> i just dont want an easy gui way for joe user to break stuff
<asac> ogra: i can already imagine how students make fun of playing with NM :)
<asac> ogra: sure ... given that nm won't manage static+auto dhcp interfaces anymore it should be ok i guess.
<ogra> yeah
<ogra> and students shouldnt be in the admin gropup
<ogra> -up
<ogra> ogra2@laptop:~$ nm-applet
<ogra> ** (nm-applet:14286): WARNING **: <WARN>  nma_dbus_init(): could not acquire its service.  dbus_bus_acquire_service() says: 'Connection ":1.79" is not allowed to own the service "org.freedesktop.NetworkManagerInfo" due to security policies in the configuration file'
<ogra> looks really nice :)
<asac> hehe
<asac> the warning does not really describe what happened accurately ... but still not really wrong:)
<ogra> "is not allowed to own the service ... due to security policies in the configuration file" sounds ok to me
<asac> ogra: you sure there is no other applet running?
<asac> ogra: because thats the message you get then
<ogra> ogra is running the applet on the server, ogra2 is on a thin client
<ogra> and ogra2 isnt in the admin group ...
<asac> ogra: if you are still in bug, plesae add beta milestone
<asac> so I won't miss it
<ogra> will do
<ogra> well, the reporter will surely step on our toes (he's that kind of guy) if it doesnt progress :)
<asac> ogra: then he is probably happy now that its not "won't fix anymore" :)
<ogra> yeah
<ogra> he already complained to the ML about us evil devs that dont fix his bugs :)
<ogra> but he's fine again, i sorted that
<asac> now, i am the bad guy, and you are the good one ... I am fine with that ;)
* ogra didnt even know we support bonding in teh default kernel until he saw that bug
<ddaa> seb128: by the way, bug 138014
<ubotu> Launchpad bug 138014 in gnome-applets "mini_commander_applet manpage still here" [Undecided,New]  https://launchpad.net/bugs/138014
<pochu>  we plan to support LTS -> LTS+1 upgrades directly, don't we?
<ogra> pochu, yes
<pochu> So bug 138013 isn't really a bug :)
<ubotu> Launchpad bug 138013 in ubuntu "Migration from 6.06 LTS to 8.04 LTS has to be smooth" [Undecided,New]  https://launchpad.net/bugs/138013
<ogra> no :)
<ogra> pochu, you can invalideate it with a comment that we plan this feature anyway :)
<pochu> Already done ;)
<superm1> mvo, ping
* lamont wonders if we can get git-core 1.5.2.5 into gutsy... Riddell? Hobbsee? BenC??
* mvo waves to superm1
<superm1> hey mvo.  i was going to ask if you can add mythbuntu-desktop as valid as a desktop package to update-manager
<mvo> superm1: sure, I can do this right away
* mvo edits
<Riddell> lamont: sell it to me
<Riddell> (no new features, good reason to have it a bonus)
<mvo> superm1: done, will be part of the next upload (thanks for leting me know aobut it!)
<xhaker> Riddell, bash completion?
<Hobbsee> lamont: hint:  offer beer, or $beverageofchoice
<superm1> thx mvo, i didn't mean right away, i would have filed a bug, just wanted to make sure it was cool with you, but thanks for getting it done so quick :)
<Riddell> xhaker: so it does have new features?
<xhaker> i think it fixes
<lamont> Riddell: "Fix "git add -u" data corruption.
<lamont> 
<lamont>     This applies to 'maint' to fix a rather serious data corruption
<lamont>     issue.  When "git add -u" affects a subdirectory in such a way
<lamont>     that the only changes to its contents are path removals, the
<lamont>     next tree object written out of that index was bogus, as the
<lamont>     remove codepath forgot to invalidate the cache-tree entry.
<lamont> "
<Riddell> that sounds like a good thing
* lamont notes that he didn't ask for 1.5.3.1 :-)
<Riddell> lamont: is that the only change or is there a changelog somewhere?
<lamont> looking at it now
<lamont> someone else just poked me with it, since I'm his ubuntu-guy
<lamont> Riddell: there are a few other bug fixes between .4 and .5
<lamont> all bug fixes though, new features into at least 1.5.3
<milli> lamont: Just looking to get git-core (and friends) 1.5.2.5 instead of 1.5.2.4 to fix that data loss issue.  I would not suggest 1.5.3.x be put in yet (was just released!)
<lamont> +   - "git checkout-index" and other commands that checks out
<lamont> +     files to the work tree tried unlink(2) on directories,
<lamont> +     which is a sane thing to do on sane systems, but not on
<lamont> +     Solaris when you are root.
* lamont loves that one
<lamont> milli: same thinking
<Riddell> lamont: ok, sounds good, go ahead
<lamont> given that sid has already rolled to 1.5.3, and etch has 1.5.2.4, I'll just upload 1.5.2.5-2build1 directly to gutsy, rather than praying that a sync gets done before the source gets removed from the debian archive in a couple hours...
<lamont> Riddell: sound right"
<lamont> ??
<Riddell> lamont: sure
<mvo> superm1: no problem, its easy/quick enough to add :) just two lines the config file of the upgrader (and I'm working on that one anyway ATM)
* lamont does a test build for giggles first
<milli> lamont: and the feisty backport is 1.5.2.3 ... :(
<digisus> Hello! It says "Tribe CD 6 (not released)" on https://wiki.ubuntu.com/GutsyReleaseSchedule -- Is it canceled or postponed?
<lamont> milli: and using -backports repositories has always struck me as silly
<bryce> digisus: canceled
<digisus> bryce: Alright. Thanks.
<lamont> ScottK: wanna trigger a backport of git-core 1:1.5.2.5-2build1 to feisty once it shows up in gutsy??
<ScottK> lamont: If you can get milli to file the feisty-backports bug, I'd be glad to.
<lamont> milli: your ball.
<milli> nod
<lamont> milli: uploaded
<milli> lamont: ty
* lamont builds git-core_1:1.5.2.5-2~0.6.06 for his home machines
* norsetto is away: testing
<lamont> ScottK: btw, doing a backport of git-core to feisty will require either backporting asciidoc from gutsy, or dealing with the build-dep...
* norsetto is away: Gone away for now.
<ScottK> lamont: It takes a core-dev to upload a source backport.  I'd rather change the asciidoc dep.  Would you be up for uploading it?
<ScottK> Dunno what else changing asciidoc would affect.
<lamont> sigh.  sure
* lamont goes looking at the format for the version number
<lamont> ah ~feisty1.  chcek
<milli> lamont: and ScottK, for the asciidoc build-dep, it is completely safe to change it to (>> 7.0.2)
<milli> also may need to change libcurl3-gnutsl-dev --> libcurl3-gnutls-dev  (tsl versus tls typo)
<lamont> milli: that's already fxied
<lamont> ScottK: want me to close the bug in the upload?  (remind me of the syntax one more time... sigh)
* lamont re-uploads to gutsy, since it got snitty about .orig.tar.gz not being there.. (doh)
<bddebian> heh
<davmor2> Riddell: ping
<Riddell> hi davmor2
<davmor2> Riddell: when the update icon shows up at the beginning it is always a green circle saying no updates.  If you go into adept and manually update though there can be loads.  Is this known?
<pygi> oh, iXce !
<pygi> long time no see ;)
<pygi> how are you doing?
<iXce> heya pygi =)
<iXce> pretty well, back to school
<iXce> erm, I'm having a packaging problem with texlive
<iXce> in breezy the file "landscape.sty" was distributed in tetex-extra, but in feisty and gutsy I can't find it anymore
<Riddell> davmor2: beginning of what?
<iXce> (it seems that the package has entirely been redone around early 2006)
<davmor2> Riddell: Sorry not well explained.  When you switch on a machine and start a session.  You get a green circle appear in the task bar which when highlighted says "no updates" or something similar.
<sits> Can I convince someone to rate a xorg bug's priority?
<davmor2> Riddell: in reality just when I switched on there were 51 updates.  But it still said there were none.
* lamont wants a large crowbar in the config to not do the sound at login
<lamont> where would that crowbar go??
<lamont> seb128: ??
<kylem> through your speakers.
<Riddell> davmor2: do you have update-notifier-common installed?
<Riddell> davmor2: by the way #kubuntu-devel may be better for KDE related talk
<davmor2> Riddell: I will check okay np
<bryce> Riddell: unfortunately it appears on my system there is both a kde-guidance and a guidance-backends installed.  I have two copies of xorgconfig.py present, and the one that the kde-guidance fixed is not the one that displayconfig-gtk uses, so I'm still having the same issue.  Any ideas?
<Riddell> err, sounds like packaging breakage
<Riddell> are they in the same place?
<Riddell> guess not with python-support
<bddebian> Could a buildd admin please give-back taxbird now that libgeier is built??
<Riddell> bryce: the guy to ask is glatzor who isn't online just now
<Riddell> bryce: that shouldn't be duplicated as far as I know
<bryce> no one is in python-support, the other is in /usr/lib/python2.5
<Riddell> mvo: does update-notifier work for users who turn their machines off at night?
<Riddell> since it wouldn't do the nightly apt-get update
<bddebian> mmm Arby's
<Arby> hehe
<bryce> Riddell, ahh, I needed guidance-backends, not just kde-guidance.  Works now.
<Riddell> bryce: maybe you have an old kde-guidance then
<Riddell> I don't have xorgconfig.py in my current version
<bryce> could be
<bddebian> Is there a list of buildd admins somewhere?
<torkel> Riddell: isn't anacron taking care of it when they are turning the machine on?
<bryce> possibly I had an old copy of displayconfig-gtk installed with its own guidance backend stuff.  I've checked on a relatively freshly installed machine and also see only one copy of xorgconfig.py there
<Amaranth> bryce: why did you reassign bug 137745 to compiz?
<ubotu> Launchpad bug 137745 in compiz "compiz can only used by one user" [Wishlist,New]  https://launchpad.net/bugs/137745
<desrt> ya... that's definitely not a compiz problem :p
<iXce> yeah, quite
<desrt> i think it's caused by a double free in the nvidia driver...
<Amaranth> hehe
* desrt looks around
<Amaranth> it's a DRI problem
<iXce> desrt : which one? :>
<bryce> Amaranth: well, it doesn't seem like something I can do anything for within X
<Amaranth> bryce: And I can't do anything within compiz :)
<Amaranth> bryce: have to redo the way 3d drivers work to fix it
<iXce> reassign to mesa?
<bryce> Amarath, the reason I put it back to compiz is because ultimately the issue affects compiz, and while "X doesn't support DRI on multiple sessions" could well describe the root cause, I don't think that provides a solution, so I put it into compiz in hopes y'all could come up with a different workaround or something
<Amaranth> bryce: there is no workaround, 3d of any kind does not work
<Amaranth> should i just close it Won't Fix?
<bryce> Amaranth: then perhaps it shold be closed as won't fix
<Amaranth> there is no way in hell we can fix it
<bryce> yep
<mvo> Riddell: it should, anacron will ensure that (if not, that would be a anacron issue)
<sladen> is it a DRI problem, or is it a *DRI ownership* problem
<cjwatson> surely it *should* be fixed, it's just that it's a difficult upstream problem
<bryce> I moved it to be a wishlist, assuming others may complain about it in the future
<mjg59> DRI
<Riddell> mvo, torkel: right
<cjwatson> *we* won't fix is not quite the same as won't fix IMO
<Amaranth> sladen: it's dri, drm, or both
<bddebian> This is wrong isn't it? pkg-config --modversion evolution-shell-$version
<Chipzz> Amaranth: I'ld say not WONTFIX; this is an issue that's not impossible to solve, just very hard to solve, and should be solved upstream
<Amaranth> sladen: i know it works with nvidia
<Amaranth> Chipzz: and won't be solved for a couple years, if ever
<mjg59> Amaranth: Nvidia doesn't use DRI, so it's not especially interesting
<Amaranth> I haven't even seen anyone talking about fixing it
<Chipzz> Amaranth: yes, but that's no reason to mark it wontfix imo
<Amaranth> actually the nouveau driver has the best chance of not having this problem
<mjg59> Well, it also won't run compiz, which makes it less relevant to the problem at hand :)
<Amaranth> oh, i'm sure it has the problem now :0
<Amaranth> but nvidia hardware supports this stuff on it's own
<mjg59> It's not a hardware issue. It's just related to how DRI is designed. Nvidia don't use DRI, so don't suffer from this issue.
<Chipzz> Amaranth: wontfix means something along the lines of: this bug is bogus, I wont fix it, get lost
<sits> cjwatson: CANTFIX?
<sits> cjwatson: or UPSTREAM?
<bryce> it seems it would be best to have a wishlist bug in compiz describing the general problem, pointing to a second bug either in xorg or upstream that describes the DRI issue in more detail
<sits> bryce: almost sounds like you want bug dependencies
<cjwatson> sits: neither exists as a resolution in Launchpad, though it's possible to create an upstream task
<mathiaz> keescook: I've talked with kylem and he's going to upload a new l-u-m which has a apparmor-modules-2.1 provide.
<cjwatson> sits: doesn't need bug dependencies, multiple tasks do the job
<mathiaz> keescook: that may break things with apparmor
<sits> cjwatson: hmm interesting...
<keescook> mathiaz: s'okay, we'll fix 'em.  :)
<bryce> sits, well, just a pointer from one bug to another would be sufficient to communicate to future bug reporters "yes we know there is an issue, but the problem really is over here"
<keescook> cjwatson: so, whatcha think of pam 0.99?  :)  should I move forward and open a UVFe bug for it?
<sits> bryce: the only thing I can quickly think of would be duplicating on an invalid bug. People hate that though
<sits> (the invalid bug would contain the information near the top)
<cjwatson> keescook: if you think we can shake out issues with it in time, sure
<cjwatson> sits: that's a baroque and strange solution
<cjwatson> it's not invalid either. it should be left open
<lamont> kylem: excellent solution, except that I want the speakers to work.. I just don't want it to announce that I booted the machine to the room full of execs...
<keescook> cjwatson: well, that's why I'm looking to you; I'm less familiar with PAM than you, so while I think it's possible, I'm curious to hear other opinions.  :)
<lamont> ScottK: git-core_1.5.2.5-2~feisty1 uploaded to feisty-backports
<cjwatson> keescook: I wouldn't be so sure about that
<cjwatson> keescook: you might as well go ahead with the UVFe request; worst case we say no after looking at it ...
<keescook> heh
<cjwatson> it's too late in the week for me to think hard about it now
<keescook> cjwatson: yeah.  I figure we have to do it some time, and I'd rather shake it out now than in hardy.
<keescook> sounds good
<sits> cjwatson: I guess I'm not thinking in an articulate enough fashion. I just had the impression it's something that can be only fixed upstream
<sits> and won't be fixed directly by someone working in Ubuntu
<cjwatson> sits: which is not a reason for us to refuse to accept it in our bug tracking system
<cjwatson> if we reject it, somebody will just file it again later; we aren't gaining anything at all by trying to get rid of it
<sits> cjwatson: your point of view is far more considered
<cjwatson> I'm not trying to browbeat you, I'm just trying to explain
<cjwatson> a defect in Ubuntu is a defect regardless of who needs to fix it
<cjwatson> now, we might want to open other tasks to log the organisation who needs to fix it
<sits> cjwatson: I can see that : ) I'm trying to adjust my viewpoint while still providing a different point of view to you
<cjwatson> and drop the priority of the Ubuntu bug way down so that it doesn't interfere with other work
<cjwatson> it is certainly important to prioritise what we do
<seb128> lamont: system, preferences, sounds?
<sits> cjwatson: it sounds like a setting expectations problem. By setting the priority that gives people who arrive at it more information...
<cjwatson> we can always explain more in prose
<sits> new bugs can be duped on it... The problem can be described in technical detail
<Amaranth> grr
<sits> cjwatson: Is there anyone else out there who is fixing this?
<sits> (or working on something similar?)
<Amaranth> now how the hell do i add the upstream bug to a bug report?
<cjwatson> I don't know
<Amaranth> this seems to change every time i try
<sits> Amaranth: Add Project?
<cjwatson> Amaranth: "also affects... project"
<Amaranth> that only lets me add compiz-settings
<cjwatson> Amaranth: "Choose another project"
<sits> cjwatson: and is it a small or a big task to solve?
<cjwatson> sits: AIUI, very large
<sits> cjwatson: but it can be done without client X app changes?
<Amaranth> cjwatson: i accidentally added compiz-settings, marked it invalid, and now the UI changed _again_
<Amaranth> so i don't have Choose Another Project anymore
<Amaranth> I have a Project textbox to put something in
<sits> Amaranth: bug #?
<cjwatson> sits: I have no idea. I am not the person to ask
<Amaranth> https://bugs.launchpad.net/compizsettings/+bug/137745
<ubotu> Launchpad bug 137745 in compiz "compiz can only used by one user" [Wishlist,Confirmed] 
<Amaranth> oh, bleh
<Amaranth> that's why
<Amaranth> my URL got changed
<sits> cjwatson: sorry my bad
* Amaranth stabs launchpad
<Amaranth> oh, no, that didn't help
<Amaranth> sits: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/137745 needs to be linked to https://bugs.freedesktop.org/show_bug.cgi?id=3834
<ubotu> Launchpad bug 137745 in compiz "compiz can only used by one user" [Wishlist,Confirmed] 
<Amaranth> sits: if you figure out how let me know :)
<sits> Amaranth: I think I can guess at the problem
<Amaranth> oh?
<sits> Amaranth: let me just check
<sits> Amaranth: can you visit https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/137745 ?
<ubotu> Launchpad bug 137745 in compiz "compiz can only used by one user" [Wishlist,Confirmed] 
<sits> Amaranth: and check whether you are logged in?
<Amaranth> i am
<sits> Then look at the right hand side
<lamont> seb128: thanks
<sits> Amaranth: (click on the link again)
<sits> Amaranth: (the one just pasted)
<Amaranth> still logged in
<lamont> seb128: and turn off 'play system sounds'?
<seb128> lamont: do you want to disable the session sound or the gdm one?
<lamont> hrm...
<sits> Amaranth: and do you see a while and yellow bar?
<lamont> whatever plays the sound when I log in... I want that to be silent.
<seb128> lamont: there is "blong" when the login screen is displayed
<sits> Amaranth: with also effects: beneath it?
<Amaranth> yes
<seb128> and the ubuntu sound on login
<lamont> ah, right.  both
<sits> Amaranth: click Project...
<seb128> lamont: for the login sound, select "no sound" for login sound
<Amaranth> i get a textbox to input a project that is registered on launchpad
<bryce> enter xorg-server
<Amaranth> This is the _worst_ UI ever
<sits> Amaranth: my bad
<sits> Amaranth: back one page
<Amaranth> sits: i'm good now
<seb128> lamont: for gdm, system, admininistration, login screen, accessibility, uncheck the login screen ready
<sits> Amaranth: click on          Distribution/Package
<sits> Amaranth: fair enough
<Amaranth> sits: no, that isn't the right place either :)
<cjwatson> sits: no, don't use distribution/package for this
<lamont> seb128: thanks
<Amaranth> sits: bryce gave me the fix
<sits> I think it's because that bug doesn't have a xorg task
<seb128> lamont: you're welcome
<sits> oh fair enough
<Amaranth> oh, yeah
<bddebian> seb128: Are you a buildd admin also?
<seb128> bddebian: no, pitti, doko, Mithrandir are
<bddebian> Fruck, OK, thanks
<bryce> Amarath, yeah it's a pretty confusing UI
<cjwatson> bddebian: https://launchpad.net/~launchpad-buildd-admins
<cjwatson> bookmark that if you're making requests of buildd admins often
<Amaranth> should just give me a project textbox and a bug tracker url box and let me pick
<Amaranth> maybe i'll file a bug report :)
<bddebian> cjwatson: Will do thank you sir
<bddebian> Of course poor Mithrandir seems to be the one around the most lately :-)
<Mithrandir> bddebian: give-backs aren't much work, though
<bddebian> Mithrandir: OK, well if you get a free sec can you please give back taxbird?
<Mithrandir> bddebian: given it's depwait, there's no need, it'll be retried once all the dependencies are in.
<bddebian> Is it still dep-wait on libgeier?
<bddebian> Do we have visibility of that stuff still?
<Mithrandir> https://launchpad.net/ubuntu/+source/taxbird/0.10-1 tells you it's dep-wait
<Mithrandir> https://launchpad.net/ubuntu/+source/taxbird/0.10-1/+build/363586 tells you glade-gnome is what it's depwait on
<bddebian> Oh, but i386 built?
* bddebian is obviously ignorant and confused
<Riddell> Mithrandir: could you give back kde4pim on amd64 please
<ogra> seb128, i'd like to upload http://paste.ubuntu-nl.org/36727/ to fix the issue with sabayon blocking users if no profile is around ...
<ogra> any objections ?
<seb128> ogra: is the blank line change required?
<seb128> ogra: no, do you plan to send the bug on bugzilla.gnome.org?
<ogra> sure, we can do that
* rgl waves
<ogra> indeed the blank change isnt required :)
<seb128> ogra: feel free to upload; bonus point if you forward upstream ;)
<ogra> heh
<ogra> just didnt want to do it blindly :)
<ogra> thanks for your time
<seb128> ogra: stop
* ogra listens
<seb128> ogra: use a patch
<sbalneav> Hammertime
<seb128> rather than changing the source directly
<ogra> oh, crap, right
<seb128> ogra: thanks ;)
<rgl> how can I update do tribe6?   just the usual apt-get dist-upgrade?
<ogra> sbalneav, do you want to do that, or should i ?
<seb128> ogra: the patch uses simple-patchsys so you can simply copy the change
<ogra> (needs cdbs-edit-patch, like you did for denemo)
<ScottK> seb128: I noticed that you're a bug contact for nautilus-sendto.  Do you care to review the change in Bug #138010 or just leave it for ubuntu-main-sponsors?
<ubotu> Launchpad bug 138010 in nautilus-sendto "Nautilus-sendto suggests obsolete slypheed-claws package" [Low,Triaged]  https://launchpad.net/bugs/138010
<rgl> Kmos, there?
<ogra> right
<seb128> ScottK: feel free to upload
<sbalneav> ogra: Since you're going to fw upstream, through lp magic, I'd expect, it ok if you do it? Or are you bushed?
<ScottK> seb128: Thanks.  I'll hunt around for a core-dev to do it then.
<ogra> sbalneav, i meant redo the patch, but i'm fine :)
<seb128> ScottK: ? the package is to universe
<seb128> ScottK: ups, I'm tried
<ScottK> seb128: nautilus-sendto is in Main.
<seb128> tired
<sbalneav> What do we need to redo on the patch?
<seb128> right, I was think to claws-mail
<seb128> ScottK: I'll upload it for you
<ScottK> Great.  Thanks.
<seb128> no problem
<Mithrandir> Riddell: the feisty one that I've given back before and which failed then too?
* ScottK goes to work on the sylpheed-claws and gpgme removal bugs.
<ogra> sbalneav, instead f being directly in the source, the change should be a separate patch, like the denemo patch you mde before ... since sybaon uses simple-patchsys i can just tweak the file you sent me and make it a patch
* ogra wonders where all the keys went ...
<ogra> i'm sure i pressed them
<Riddell> Mithrandir: yes
<Riddell> Mithrandir: it worked for i386 but amd64 still didn't have all the build-deps
<Mithrandir> Riddell: ok, given-back
<Amaranth> ogra: did your 'a' go on strike?
<ogra> aaaaaaaaaaaaaaaaaaa
<ogra> doesnt seem like
<sbalneav> ogra: If you can do it, go ahead.
<sbalneav> I'm testing some boot stuff in ltsp atm
<ogra> Amaranth, i used xgl for a while, that has this weird keyboard repetition bug here ... probably my system is exhaused wrt vowels now ...
<Amaranth> ogra: hehe, RAOF is still doing some tweaking with Xgl
<ogra> i gave up on it
<ogra> it eats to muc power for the benefit
<ogra> *much
<sits> ogra: really?
<sits> even more than AIGLX?
<Amaranth> I haven't noticed
<Amaranth> I would think using the CPU less would help
<Amaranth> oh, i know why
<Amaranth> it's because with the open source drivers if you aren't using 3d they don't do $REFRESH_RATE interrupts a second
<Amaranth> if you use Xgl it always does
<ogra> right
<sits> Amaranth: wouldn't that affect AIGLX too?
<ogra> my fan gets quite busy over time since my machine is maxed out anyway with tons of other tasks
<iXce``> yeah, nVidia always refresh all the time anyway ><
<sits> (I only ask because I've measured AIGLX usage)
<Amaranth> sits: AIGLX only comes into play if you use GLX :)
<sits> Amaranth: well if you are using compiz
<Amaranth> iXce``: yeah, it's annoying like that
<sits> in theory you will be syncing to frame so the interrupts will go up
<iXce``> definitely
<iXce``> I wish they'd follow AMD soon and help nouveau :/
<sits> (In fact once they rise after AIGLX is used on the Intel I have here the interrupts never fall)
<Amaranth> sits: If you aren't using GLX how could it do anything?
<sits> Amaranth: because often when you enabled compiz you wind up doing the compositing using GL
<Amaranth> iXce``: if i switch to the nv driver and disable my wifi i only get something like 13 wakeups a second when idle in X
<Amaranth> iXce``: with nvidia and wifi on it's 130, so sad
<iXce``> haha
<iXce``> I wonder what's the best hardware for that. Intel?
<sits> Amaranth: that sounds like a quirk of the NVIDIA drivers (presumably they try and go as fast as possible)
<Amaranth> iXce``: yeah
<sits> Amaranth: I have an Intel and while disabling interrupts by taking out DRI does drop interrupts the savings in power are comparatively low
<Amaranth> sits: no, they just always generate an interrupt on vblank while the open source drivers only do that when a 3d app is running (when it's actually needed)
<Amaranth> sits: sure, but it still makes a difference
<iXce``> (they'd just need to fix that xgl problem :o)
<sits> Amaranth: not if you are using AIGLX
<Amaranth> sits: one thing doesn't do much but a bunch of little things add up
<sits> (i.e. using compiz without XGL)
<Amaranth> sits: AIGLX has become a buzzword :)
<Riddell> lamont: you tested that git backport I presume (or is there a bug report?)
<Amaranth> sits: what, exactly, are you referring to?
<sits> Amaranth: sorry my mistake. The interrupts DO rise when you AIGLX
<ScottK> Riddell: There is a bug report.
<Amaranth> sits: When you use 3d, yes
<sits> but it is exactly the same as if you were drawing anything 3D and syncing to frame
<ScottK> Riddell: Bug #138032
<ubotu> Launchpad bug 138032 in feisty-backports "Data loss problem with "git add -u"" [Wishlist,In progress]  https://launchpad.net/bugs/138032
<sits> but what I am actually saying is
<Amaranth> sits: AIGLX is a technique, not a thing
<sits> the difference turned out to be 1W
<lamont> Riddell: there's a bug report (138032), and i made sure it built...
<sits> sorry that's wrong too
<sits> 0.1W when I measured it
<lamont> I'm actually in the process of updating my feisty machines to that version of git
<Amaranth> sits: Yeah, I've always known it wasn't much :)
<Amaranth> sits: I was guessing more like 1W though, nice to see it's so low
<Riddell> ScottK, lamont: accepting
<ScottK> Cool.
<Amaranth> I guess I can close all the "disable compiz when running on battery" bugs now :)
<ScottK> milli: ^^^
<lamont> Riddell: and seems to work OK here.
<Riddell> phew
<sits> Amaranth: it's the difference (I've just double checked my records) of 20 wakesup -> 80 wakesups per second
<Amaranth> sits: nice
<sits> Amaranth: there is difference but unless you are getting down below 10 wakeups per second you are only going to save so much power by sleeping for a long time anyway
<sits> my tests say that there are bigger savings which are far bigger and better to go for first
<sits> e.g. disabling wifi and bluetooth saved 2.4W
<Toxicity999> If anyone applicable to the bug hasn't seen, someone found the patch which created many xcrashes in gutsy https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/130325 last few comments, pretty good news. =]  Amaranth this is the one we talked about a while back and that huge forum thread of people QQing was on about.
<lamont> Riddell: and in a minute or 6, I'll know if 1.5.2.5 fixes the bug I just ran into...
<ubotu> Launchpad bug 130325 in xorg "[nvidia-glx-new]  3D GL apps crash X when using compiz (gutsy)" [Undecided,Confirmed] 
<sits> another big win - dimming th escreen saved 2.1W
<Amaranth> sits: bluetooth is blacklisted here :)
<sits> Amaranth: (this is on a laptop with Intel hardware)
<sits> Amaranth: ah but what about wifi?
<Amaranth> sits: i wish the wireless wasn't so noisy
<Amaranth> it used to be worse though
<Amaranth> when powertop first came out with wifi vs without wifi was like 800 wakeups vs 200 wakeups
<sits> Amaranth: you may find the bulk of the power was wifi in that combo
<Amaranth> now it's the difference between 130 wakeups and 80 or so wakeups
<sits> (but turning off bluetooth definitely saves power but probably not as much as dimming the screen)
<Amaranth> Toxicity999: that's tricky because hildon needs it
<Toxicity999> Oh really? I never skimmed the actual patch.
<Amaranth> sits: unfortunately i opted for the 'ultra bright' screen so my lowest setting is brighter than most people's highest setting
<Toxicity999> Probably a good 3rd party will distribute a package around for gutsy final, good or bad, that always happens.
<sits> Amaranth: I think there are definite bands when it comes to wakeup power usage
<Toxicity999> I won't compile xserver for my own uses until gutsy final is out, compiling your own copy of core thigns sort of defeats the purpose of a testing distro release.
<Amaranth> sits: it's more what is causing the wakeups
<sits> I think you are talking maybe 100s of wakeups reduced to save 0.1W . If you can dim your screen that would save you much more
<Toxicity999> So it does fit in to the "We broke it but it's nvidias bug" category?
<Amaranth> sits: if it's an interrupt then you're also keeping some other part of the hardware awake
<sits> Amaranth: well the only reason you care about wakeups is because you want the CPU to sleep for longer
<Amaranth> sits: not always
<sits> and the longer it can sleep for the less power it can draw
<sits> Amaranth: go on...
<Amaranth> sits: for instance powertop offers helpers to disable bluetooth and etc but not because of the wakeups they cause for the CPU
<Amaranth> the power usage of the bluetooth itself is the problem, the CPU waking up a little more is a small blip
<mathiaz> BenC: I've just download the latest version of linux-ubuntu-modules (linux-ubuntu-modules-2.6.22-11-server_2.6.22-11.25_i386.deb) and the apparmor module is not included.
<sits> Toxicity999: hmm. That's the bug I wanted someone to change the priority of
<Amaranth> sits: to?
<sits> Amaranth: hmm that's a very good point
<Toxicity999> sits well I nominated this one, but the thing was a duplicate got accepted for tribe-6, when it was marked, it was taken off iirc.
<Toxicity999> so it sort of stifled the process.
<sits> Amaranth: I don't know what it should be changed to. That should be down to whoever maintains the package
<ogra> cjwatson, is there any udeb that contains mkfifo ? apparently my udeb isnt happy atm with the installer environment
<Toxicity999> but if this patch is there to make something else work... then it'd more complicated.
<Toxicity999> *it'd
<Toxicity999> erg IT'S
<sits> Amaranth: I don't want it set to X. I'd just like to see it set. I asked twice but there wasn't a reply. It might be nice if it were assigned too so it wouldn't be forgotten but again that should be down to someone else
<Amaranth> Toxicity999: it's also included upstream now so we're going to run into it again right away
<Toxicity999> Ah
<Toxicity999> Nasty.
<Amaranth> not for gutsy but still
<BenC> mathiaz: thanks, I'll do a quick upload to fix that
<mathiaz> BenC: thanks.
<sits> Amaranth: it's hard to know whether its "known" or not you see
<Toxicity999> Well once people figure out what kind of damage the whole thing does, either A) a workaround will be found upstream/our end or B) 3 years from now nvidia is all over it.
<sits> Amaranth: but it keeps attracting duplicates
<Toxicity999> yea there are 6 marked dupes now
<Toxicity999> probably tons more.
<sits> Amaranth: I didn't know what else to do
<sits> Toxicity999: oh? Where?
<Toxicity999> the dupes? Should be listed in the original I linked.
<Amaranth> i think there are like 4 dupes sitting in compiz waiting to be triaged
<sits> Toxicity999: no the "more unduped bugs"?
<Toxicity999> that was just a guess.
<Amaranth> need to set aside a couple hours for that soon :)
<Toxicity999> it's a dupe attracting beast.
<Toxicity999> and they all point do different source packages
<sits> Toxicity999: it's nothing compared to some other bugs I've seen
<ogra> cjwatson, unping, i'll take mknod :)
<Toxicity999> atleast we know what is the actual problem now.
<Toxicity999> What exactly did the patch fix?
* Toxicity999 skims for it.
<sits> Toxicity999: it's not mild but I hate to say it, it could be worse
<Toxicity999> It could
<Toxicity999> I mean I can always use my handy dandy mythprep to kill compiz and avant for running mythtv/games
<Toxicity999> but it's a hinderence for simple ogl stuff.
<Amaranth> Toxicity999: I know it makes hildon and desrt's new gnome-panel work right
<Amaranth> Toxicity999: can't say i know the exact details of how it works, i try to stay a little more high level than XComposite hacking :)
<Toxicity999> wouldn't it be easier to work around it in those areas than sort of set it up to wait on nvidia though?
<Amaranth> no, not really
<Toxicity999> Looks like the mailing list is buzzing as well. Reading up on the patch.
<BenC> mathiaz: fix uploaded
<Amaranth> Toxicity999: what mailing list?
<Toxicity999> Haven't looked yet, just googling.
<Toxicity999> Wait I just found mom entry where this patch was removed, was it later reintroduced? freaky.
<Toxicity999> Way back in July
<Amaranth> yeah, funny that
<Toxicity999> Yea, removed the 13th, back the 25th.
<Amaranth> it was disabled for breaking compiz, then supposedly the patch was updated to fix it so it was reapplied
<Toxicity999> must of been some pretty light testing.
<Amaranth> or it broke something else
<Amaranth> i've been using Xgl since before then so i don't remember anything
<sits> or it didn't break open source drivers
<sits> (it doesn't appear broken on the Intel I have here for example)
<Toxicity999> true
<Toxicity999> it never specifically says anything in the notes about nvidia
<sits> indeed
<Amaranth> this is the double free from inside the nvidia driver, right?
<sits> Amaranth: oh if that's the case I'm thinking of a different bug
<sits> Amaranth: my bad
<Amaranth> sits: nvidia+compiz+gl app == X crash
<Amaranth> sits: but the backtrace goes from somewhere inside the nvidia driver to Xfree so i'm guessing it's freeing something twice
<Toxicity999> Nasty bugger at that. As much as compiz is used in ubuntu now, people are in for a treat come upgrade day.
<sits> Amaranth: going to be tricky to say
<Toxicity999> It seems like we broke it, but it exposed a nvidia bug.
<Amaranth> Toxicity999: distros with xserver 1.4 will see it too
<sits> Amaranth: without the source... (not impossible but very difficult)
<Toxicity999> yea
<Amaranth> don't think any of them exists but still
<Toxicity999> if it's upstream, it will suuuuurely be a hotbutton issue next major distro release party.
<sits> Toxicity999: *shrug*
<Amaranth> nah, i'm sure nvidia will have fixed it by april
<Toxicity999> lol
<Amaranth> looks like they just made a bad assumption
<sits> Amaranth: if they know about it and they see it as a bug on their end
<Amaranth> If they don't know about it they will in about 2 days
<Toxicity999> in the mean time it's easy enough user end to compile xserver without the patch, and to distribute a no guarantees package.
<Amaranth> (when gentoo users will finish compiling X ;)
<Toxicity999> haha
<Toxicity999> I'm just happy to finally see what caused it, I have no patience for a bisect.
<Toxicity999> now I know how to get around it myself.
<Toxicity999> here's hoping nvidia opens up a bit following AMD to avoid this crap >.>
<sits> Amaranth: ;)
<Amaranth> Toxicity999: they don't really need to, the nouveau guys seem to (in general) know how all the hardware works
<Toxicity999> yea
<Toxicity999> they did a killer job
<sits> Amaranth: it's hard to say if its a double free
<Toxicity999> development is racing on that.
<Amaranth> they're just polishing the 2d bits while waiting for the ttm stuff to settle
<sits> Amaranth: it could just  be wondering off into address space it doesn't own or setting the wrong bit of memory which leads something to deference a piece of memory X doesn't own etc.
<Toxicity999> essentially it's going ot be a big debate, should we work around their bug, or leave it to make them fix it. Myself I'll just compile x in a few days-weeks =P
<Amaranth> sits: sure but double free is more likely
<Toxicity999> My guess too
<sits> Amaranth: really? Why?
<Toxicity999> it just feels most likely
<Amaranth> sits: I dunno, it's the one I do all the time :)
<sits> Amaranth: hmm that hasn't been my experience...
<Toxicity999> if the patch has been reviewed to be good enough, multiple times, we're keeping up with the specs, it's just their thing.
<sits> I'd say off by ones are more common
<Amaranth> sits: yay off by one in pointer math
<sits> but I'd have to look up the stats on typical bug counts of C code
<sits> I don't have my code complete book to hand unfortunately
<Amaranth> i suck at memory management, that's why i try to stick to ref counted stuff in C and use a lot of python :)
<sbalneav> Mithrandir: You about for some quick UVFe love?
<Amaranth> Toxicity999, sits: Seems obvious now. aaronp says that patch changes the ABI so our only options are live with the bug or pull the patch
<sits> Amaranth: that makes sense
<sits> Amaranth: how did you get hold of aaronp btw?
<sits> Amaranth: (I was thinking it might have been an ABI change)
<sits> Amaranth: you may want to write that in the bug report...
<Amaranth> sits: IRC :)
<Amaranth> new driver to match the new ABI coming out 'relatively soon'
<Amaranth> but i think that'd require outright using the xserver 1.4 instead of cherry picking things from it
<bryce> yup
<sits> Amaranth: that makes sense
<Amaranth> that explains why the open source drivers don't break
<sits> how else would it know which ABI was being targetted?
<Amaranth> they got a recompile :)
<bryce> UME would be affected if the patch were removed, but I don't think anyone else needs it
<Amaranth> bryce: I think our desktop is more important ;)
<sits> Amaranth: ah it's you! Now it makes sense. You're the person who always knows what the problem with these bugs is before I even start looking at the bug!
<Amaranth> sits: eh?
<sits> Amaranth: Travis right?
<Amaranth> sits: oh, you did a /whois? :)
<Amaranth> yeah
<sits> Amaranth: yes I just did because I've been trying to piece it all together...
<Amaranth> sits: If I didn't want you to /whois me I wouldn't put my name in there :)
<sits> Amaranth: true true. It was very helpful
<sits> now I can put a nick to launchpad name
<Amaranth> sits: but i can't :)
<sits> Amaranth: I still think it would be helpful if a decision could be taken on that bug though. It's only going to rise in popularity...
<sits> Amaranth: sure but unlike me you KNOW people :)
<Amaranth> sits: that's up to bryce
<Amaranth> Well it's probably up to the TB, really
<Amaranth> Break the desktop, break ume, or figure out some way to selectively apply the patch
<sits> it could be simply turning off compiz by default (so less people stumble into it)..
<Amaranth> sits: shh
<sits> I don't really have any good answers unfortunately (as could be seen from my cjwatson conversation earlier - I take the wrong direction)
<Amaranth> sits: nvidia is about the only place where this stuff actually completely works like it should
<bryce> I thought it worked ok with Intel gfx?
<sits> Amaranth: but even you were saying the 100 series driver introduced new problems
<sits> bryce: it does
<Amaranth> sits: Now I dunno
<bryce> if this particular bug only occurs against -nvidia, why not just blacklist that driver for compiz for now?
<sits> (assuming it is unrelated to the VT switching crashes I periodically see)
<Amaranth> sits: my main complaints with the 100.14.11 were this bug and --indirect-rendering not working
<Amaranth> bryce: that is probably going to be the last driver we can enable it on :P
<Amaranth> bryce: and people are going to turn it on
<sits> Amaranth: :)
<Amaranth> bryce: it also breaks when you use xcompmgr, xfce compositing, etc
<Amaranth> someone thinks "kde shadows are safe, they've always worked" and boom, 3d apps break
<sits> Amaranth: s/3D apps/X
<Amaranth> sits: X works fine if you don't use said 3d apps :)
<sits> Amaranth: heh true
<sits> Amaranth: well I'm just glad it's a known issue now
<sits> I wanted to give it my best shot to get it to people's conciousness
<sits> Amaranth: it's also good you've already talked to an NVIDIA employee about it
<Amaranth> *shrug*
<Amaranth> i also talked to him about the VT switch problems when compiz is running and those didn't that didn't get fixed until 8 months later :P
<Amaranth> (in the 100.14.11 driver)
<sits> Amaranth: if they know then if it pops up on their forum they will be aware of things ahead of schedule
<sits> There are some things I wish they would change (they advocate a fairly extreme way of installing the .pkg which could get people into trouble)
<Amaranth> yeah, if you go on the forums with the ubuntu package they shoo you away
<Amaranth> then again they have good reason, we mess things up sometimes :)
<sits> and it would be nice if they replied to NVIDIA issues in launchpad (after the reports have been narrowed down)
<sits> Amaranth: sure but it's tricky. And I've seen their folks in the SUSE bugzilla
<Amaranth> novell probably has some kind of deal with them :P
<sits> Amaranth: case in point I noticed someone filed an upstream bug about a slowdown and it turned out they were using XGL
<sits> Amaranth: who knows? SUSE doesn't seem that pro binary drivers (having said that they do seem to recommend fglrx for some servers)
<sits> (but they don't ship any binary drivers with SLES10SP1)
<aquo> I installed ubuntu-minimal with debootstrap and examined the installed packages with aptitude
<aquo> libgcc1 has version 4.2.1
<aquo> and libstdc++6 has version 4.2.1 too ...
<aquo> if i would install gcc it would have version 4.1
<aquo> gcc depends on gcc-4.1 ...
<aquo> which is the official compiler for gutsy? 4.1 or 4.2?
<sistpoty> aquo: apt-cache show gcc -> look at depends field. 4.1
<sladen> apt-cache show build-essential | grep Depends
<aquo> sistpoty: i know, but is it true?
<sistpoty> aquo: I guess it would be a bad idea to change the compiler version so late in the cycle. IOW: yes
<aquo> sistpoty: yeah, but why is libgcc 4.2.1 and the compiler 4.1?
<aquo> shouldn't have the compiler the same version as the libgcc and libstdc++?
<sistpoty> aquo: not too sure. maybe somewhere versioned depends need to be tightened. maybe there are other reasons as well, which I'm not aware of ;)
<wasabi> Hmm. New video card no worky on Gutsy.
<sistpoty> wasabi: right, the link is missing fwiw
<sistpoty> (to libwfb)
<wasabi> libwfb?
<sistpoty> sorry, /me considered you were having troubles with a nvidia 8000er card
<sistpoty> (as I do)
<mathiaz> BenC: the apparmor kernel module needs a patch so that the audit messages sent to syslogd are correct.
<mathiaz> BenC: I have the patch - how should I proceed ?
<mathiaz> BenC: send it to you or file a bug in LP ?
<Toxicity999> Hey again, sorry local net imploded. Service was out for a bit =[ Miss any discussion on the nvidia drama?
<sistpoty> Toxicity999: I'm working on a fix, however 1) haven't tested it yet, and 2) will need a sponsor then
<Toxicity999> Cool, assuming we're both talking about crash crash with compiz and using other ogl apps?
<sistpoty> Toxicity999: no, rather about the 8000er series still not working
<Toxicity999> ah
<Toxicity999> I was going to say anyway, on this note the problem seems to be more we fixed something and the nvidia driver didn't like it =P caused by a specific patch.
<cjwatson> aquo: the libgcc ABI is stable enough that it's fine for them to be different, and it makes it easier for us to ship the odd binary built with 4.2 (which may need the newer libgcc)
<aquo> cjwatson: is it right that there are packages which depend on libstdc++6-4.2 in the system?
<asisak> aquo: you can ask "apt-cache rdepends <package>".
<aquo> asisak: i am not asking if it is true, i am asking if it is technically correct
<Toxicity999> Whew just added a rather lengthy comment to the bug.
<asisak> aquo: sorry then.
<cjwatson> aquo: yes, that's OK
<Toxicity999> I'm surprised the importance is still undecided, such a showstopper. but then there are tons of bugs to run through.
<cjwatson> aquo: err, on second thoughts no it isn't, there's no such package
<cjwatson> libstdc++6 is from gcc-4.2
<cjwatson> there's libstdc++6-4.2-dev etc., and that's fine
<aquo> cjwatson: ok, there are no packages that depend on libstdc++6-4.2, my error
<aquo> cjwatson: i just wondered about the fact that libgcc1 is version 4.2.1 and libstdc++6 is version 4.2.1, but everthing else is 4.1 ...
<aquo> should i install libstdc++6-4.2-dev or libstdc++6-4.1-dev?
#ubuntu-devel 2007-09-08
<geser> keescook: could you sponsor bug #138149? It includes a fix for CVE-2007-1888.
<ubotu> Launchpad bug 138149 in sqlite "[Fake sync]  sqlite (2.8.17-2.1build1) from Debian unstable" [Undecided,New]  https://launchpad.net/bugs/138149
<cjwatson> aquo: you don't need to install either manually; just use whichever the g++ version you're using depends on
<Amaranth> wow i never knew the upgrade tool told you about packages that have moved to universe
<Amaranth> that's a nice touch
<Kopfgeldjaeger> hi!
<stdin> hmm, I need some advice: how would you split a source-package in to more than one binary-package when each binary-package is just compiled differently. ie: the only difference is the libs they are compiled against
<stdin> not sure how well I explained it there :p
<Fujitsu> stdin: Is this about the Qt[34] /KDE variants bug that I saw earlier?
<stdin> it is :)
<Fujitsu> I ran away quickly.
<Amaranth> stdin: look at totem
<Amaranth> stdin: it builds twice, once against xine, once against gstreamer
<stdin> hmm, I'll go have a look. thanks
<geser> doko: something got wrong with your vectormath package: libvectormath-dev depends on libvectormath1 which doesn't exist
<Hobbsee> hmmm.   sabdfl is emailing us all again.  scary.
<sabdfl> watching quietly here, too ;-)
<sabdfl> how are you, Hobbsee?
<Hobbsee> arg!  he's here!
<geser> Hi Hobbsee, sabdfl
* Hobbsee survived work
<sabdfl> hey geser, glad to hear it Hobbsee!
<Hobbsee> sabdfl: i didnt even kill anyone :P
<sabdfl> my kind of gal
<pygi> Hobbsee, your not that scary, you just pretend to be =)
<zul_> Hobbsee is always scarey
<Hobbsee> pygi: oh, i can be scary.
<pygi> Hobbsee, nop :)
<Hobbsee> sabdfl: it seems to be teh weekend, why are you here?
<asisak> Hobbsee: What do you work that eventually involves killing people?
<Hobbsee> asisak: killing customers.  not staff.  usually.
<jdstrand> mdz: are you seeing odd behavior with your brightness controls and defaults on your laptop?  (I believe we have the same laptop)
<Hobbsee> asisak: at a supermarket
<Hobbsee> oh yay, cprov is back!
<sabdfl> jdstrand: i see that on my X60
<jdstrand> I saw #81407, but it is all over the place (people talking about different symptoms, etc)
<jdstrand> sabdfl: I have a T42
<jdstrand> bug 81407
<ubotu> Launchpad bug 81407 in gnome-power-manager "[Feisty]  Thinkpad (all models) LCD brightness control cycles between lowest settings only" [Medium,Confirmed]  https://launchpad.net/bugs/81407
<mjg59> I'm working on it
<sabdfl> hey mjg59
<mjg59> hal is just broken here
<jdstrand> mjg59: this is for gutsy?
<\sh> nice...I thought my t43 is broken, so I replaced it with a new one *lol*
<mjg59> Yes
<jdstrand> mjg59: cool
<jdstrand> mjg59: another symptom I have is on login it defaults to the lowest brightness.  after a little while things 'settle down' and I can adjust it properly (that is, until g-p-m kicks in, and its reset to the lowest)
<jdstrand> mjg59: I'm guessing its all related?
<sladen> somewhere I was in the middle of killing thinkpad-keys and replacing it with acpi-support events
<jdstrand> mjg59: note that gdm displays the proper brightness
<sladen> which should do with the CPU issue and may deal with the brightness weirdness at 100%
<mjg59> jdstrand: Pretty much
<mjg59> gpm is getting bogus answers from hal because it's not standardised whether stuff sends uints or ints
<jdstrand> hey cool, it just went to its lowest brightness as I read your response
<jdstrand> mjg59: ah.  is there a bug I can subscribe to?
<jdstrand> if its convenient
<jdstrand> I ask cause there are a bunch of seemingly related reports, and I don't know which you are actively updating
<mjg59> I was mostly ignoring them because a huge number of people have started reporting entirely unrelated issues in the same bugs
<mjg59> I'll get it to the point where it should work, then see whether there's still anyone complaining :)
<jdstrand> yes-- I saw that too.  Well knowing someone is working on it is ok by me.  Thanks!
<Amaranth> mjg59: dude that happens to a lot of the compiz bugs
<Amaranth> someone reports a problem and 5 people leave comments with completely different problems
<StevenK> Amaranth: I hate that. "Oh, that isn't my problem at all - this is my problem" in a bug report.
<lucky_lucas> Hi, every one, I just read that the backlight issue is on the track (happy), I would like to konw what is the state of the compiz/X crash ?
<lucky_lucas> I reported a bug but it was somehow unusable
<lucky_lucas> bryce seems to be aware and I saw on the xorg maiing list they know that xorg 7.3 crashes with compiz but don't know if any fixes is planned
<Amaranth> lucky_lucas: nvidia?
<lucky_lucas> Amaranth: both of them
<lucky_lucas> I experience a total freeze on my t43p ati firegl with ati 6.7.192 driver and on the  desktop with nvidia driver
<Amaranth> oh, the only known problem is the nvidia one, afaik
<lucky_lucas> I've read on the xorg mailing list that they are aware of crashes with compiz and x
<lucky_lucas> I don't know if it's a "cross driver " issue
<lucky_lucas> Therre is something I don't understand in the doc for debbuging xorg, I'm connected through ssh but once I attach gdb to X, it freeze the desktop
<lucky_lucas> so I type cont and X goes ok, but I don't have any feedback
<Hobbsee> greetings, jono
<jono> heya Hobbsee
<Hobbsee> bah.
<jdstrand> mjg59: I just upgraded the new hal and rebooted.  _very_ preliminary testing shows the screen brightness on my laptop is working fine again
<jdstrand> gdm still good, login has no brightness changing, brightness comes back to normal after screen blank
<jdstrand> great job!  thanks :)
<bSON> hi
<bSON> will the dodge effect stay the default for ubuntu gutsy's compiz? it is annoying after a short while, way too much movement IMO
<bSON> not the subtleness the default settings should have
* bhale screams. I have "indexing" clearly unchecked in tracker-preferences and trackerd is spinning my disk like mad
<bhale> on batter
<jdong> is it just me, or is tracker a LOT more disk-intensive than beagle?
<geser> I've seen other reporting it too
<jdong> it causes like 5x the midnight-thrashing that I'd see with updatedb...
<siretart> yes, it really drains notebook batteries like nothing
<mekius> hey, after you login with gdm, somehow the X root window is being set to a brown color, what is controlling this?
<mekius> before gdm starts up it is using the color i defined in the gdm.conf
<mekius> but after the login and before the session starts i see brown
<_StefanS_> hi there..
<Amaranth> geser, jdong: Are you guys talking about tracker?
<_StefanS_> I would appreciate if someone in here could review this comment fra Rizlaw : https://bugs.launchpad.net/ubuntu/+source/kdebase/+bug/103401, it seems to be related some session stuff in gnome.
<ubotu> Launchpad bug 103401 in kdebase "Reboot-Restart Button with classic LogOut Dialog (doUbuntuLogout=0) doesn't work" [Undecided,Fix released] 
<_StefanS_> it was reported wrong into a KDE related ticket.
<Amaranth> _StefanS_: looks like he had a session saved or something
<Amaranth> i dunno, i've never used that stuff because it basically never works right
<_StefanS_> Amaranth: yes something like it, is it something you could comment on from a ubuntu kind of view ?
<_StefanS_> Amaranth: oh. ok
<_StefanS_> Amaranth: well it just seems odd to use ctrl+alt+backspace, doesn't it kill the X-server?
<jdong> Amaranth: yeah, I'm talking about tracker
<jdong> Amaranth: its memory/CPU footprint is impressive, but disk intensity leaves a lot to be desired.
<jdong> Amaranth: if I didn't have good quality drives in this thing, I'd be concerned about life reduction.
<Amaranth> jdong: oh?
<Amaranth> it seems fine here
<Amaranth> it stops trying to index if something is writing to the file it's indexing
<jdong> Amaranth: hmm I might just have too much (several multi-GB bzr repos) in my home dir then... because it does about 25 minutes of thrashing per night.
<Amaranth> per night?
<jdong> yes.
<jdong> per night
<Amaranth> oh, i know why
<Amaranth> it ran out of inotify watches
<jdong> eep...
<Amaranth> so it periodically crawls your filesystem manually
<Amaranth> i thought it only did it when it first started
<Amaranth> if you, say, triple the allowed inotify watches... :)
<Amaranth> hopefully that's not a compile time thing but i have a feeling it is
<jdong> what are the downsides of doing that, and how do I go about it?
<Amaranth> (kernel compile time)
<Amaranth> it's a possible DoS or something
<Amaranth> i have no idea how to do that
<jdong> ah
<jdong> oh well minor issue....
<Amaranth> i know rlove pushed really hard to get a high number in there
<Amaranth> but didn't succeed, dunno if ubuntu changes it
<tonyyarusso> cjwatson, pitti, keybuk: I see that https://blueprints.launchpad.net/ubuntu/+spec/dm-crypt (solution to bug #39326) is still marked as Undefined/Drafting/Unknown, even though the technology has been available upstream for quite a while now.  Why is that, and do you have any estimate of a revised timeline for implementation?
<ubotu> Launchpad bug 39326 in debian-installer "installer: dm-crypt support missing" [Wishlist,Confirmed]  https://launchpad.net/bugs/39326
<Kopfgeldjaeger> N8
<stgraber> Seveas: Can you move ubotu from #ubuntu-iso to #ubuntu-testing ?
<Seveas> @part #ubuntu-iso
<ubotu> OK
<Seveas> @join #ubuntu-testing
<Seveas> stgraber, done :)
<stgraber> Seveas: thanks
#ubuntu-devel 2007-09-09
<bhale> jono: that shirt rules
<LaserJock> hi bhale
<bhale> hi LaserJock
<LaserJock> bhale: how goes it?
<bhale> is ok, howre you
<LaserJock> surviving, sorta ;-)
<mjg59> jdstrand: Yeah, might be differently broken
<mjg59> Some more work to do on the Lenovo machines
<keescook> geser: got it; uploading now.  thanks!
<rockets> Is there any chance that a metapackage remover will be added to synaptic?
<rockets> e.g. something that actually removes all the packages it installed
<LaserJock> rockets: there's really not much of a need anymore
<rockets> LaserJock, why do you say that
<LaserJock> rockets: packages installed to satisfy a dependency are flagged as auto removable
<rockets> LaserJock, that works for metapackages?
<LaserJock> for anything
<rockets> cool
<LaserJock> it's been that way since Feisty
<LaserJock> maybe even some in Edgy
<rockets> then how about an autoremove in synaptic :-D
<LaserJock> it is
<LaserJock> there should be an autoremovable section
<LaserJock> when you sort by status
* Fujitsu looks at the Status tabbish thing, with the auto-removable section.
<rockets> ill try it
<rockets> this is in feisty/
<rockets> ?
<rockets> LaserJock, I dont see it, i only see complete removal, which just does a --purge
<Fujitsu> rockets: Click the `Status' button under the section list.
<Fujitsu> And find `Installed (auto-removable)'
<rockets> ah i see it
<rockets> the only thing there is python2.4 though
<rockets> why not other metapackages
<rockets> like ubuntu-desktop, not that i want to remove that but shouldnt it be there
<LaserJock> no
<rockets> why?
<LaserJock> well, packages that are installed by default don't go in there I don't think
<rockets> ok
<Fujitsu> Metapackages aren't autoremovable...
<rockets> thanks!
<LaserJock> because they were there to start with
<Fujitsu> Stuff depended on by metapackages is.
<LaserJock> right
<TheMuso> A common example is old kernels...
<TheMuso> that get left behind by linux-image/linux-generic upgrades.
<calc> i think lpsolve got demoted back to universe, anyone around that could put it back into main?
<calc> i uploaded openoffice.org and its depwait on it now
<tepsipakki> I'm going to upload a new xserver-xorg-video-ati package later today
<Kopfgeldjaeger> tag
<pygi> mjg59, around perhaps?
<knight5482> hello plz can someone help me , i would like to know if it possible to update ubuntu 7.04 Standard personal computer (x86 architecture, PentiumTM, CeleronTM, AthlonTM, SempronTM) to 64 bit version  ?
<Amaranth> knight5482: this is also not the right channel
<Amaranth> knight5482: you want #ubuntu
<Amaranth> but i already gave you an answer
<pygi> mjg59, unping, got it =)
<kagou> hi
<kagou> is it still possible to ask for adding a package not present in gutsy (from debian) ?
<kagou> i need gtkimageview from http://packages.debian.org/search?keywords=gtkimageview&searchon=names&suite=unstable&section=all
<kagou> StevenK, ping
<StevenK> kagou: Pong
<kagou> StevenK, can you rebuilt ufraw package
<kagou> StevenK, it's seems that " gimp (<< 2.4)" under source don't allow installation on gutsy
<kagou> StevenK, Bug #138404
<ubotu> Launchpad bug 138404 in ufraw "ufraw gimp 2.4" [Undecided,Incomplete]  https://launchpad.net/bugs/138404
<blablabla> Please help me: http://tinyurl.com/2yu2te
<funman> hi
<kgoetz> !seen cjwatson
<ubotu> Sorry, I don't know anything about seen cjwatson - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<kgoetz> bloody bot
<funman> !seen pyro
<ubotu> Sorry, I don't know anything about seen pyro - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<funman> !seen fboudra
<ubotu> Sorry, I don't know anything about seen fboudra - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<funman> :/
<funman> !seen funman
<ubotu> Sorry, I don't know anything about seen funman - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<funman> !seen ubotu
<ubotu> Sorry, I don't know anything about seen ubotu - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<funman> :/
<kagou> thank you StevenK for ufraw :)
<mdke> I've just upgraded to gutsy and all seems to be ok; except udevd is really hogging my cpu, between 60 and 85%. Is this known already?
<ionstorm> wrong channel for this but I know you guys are smart, nobody knows how to fix my issue in any support channel https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/138440
<ubotu> Launchpad bug 138440 in linux-source-2.6.20 "P4 Hyperthread enabled wont boot generic Kernel" [Undecided,New] 
<mdke> ah, yes, plenty of bugs about it
<soren> ionstorm: Everyone (well, almost) is on weekend.
<ionstorm> ic
<ionstorm> ;] 
<ionstorm> so im not allone?
<ionstorm> alone* thats good
<ionstorm> im wondering if linux-2.6.22 will fix it, going to compile it
<mdke> (it was bug 115616, ftr)
<ubotu> Launchpad bug 115616 in evms "Device-mapper errors: dm-linear, lookup failed" [High,In progress]  https://launchpad.net/bugs/115616
<ionstorm> so my bug is related to device mapper errors?
<mdke> ionstorm: no, my question
<mdke> ionstorm: I don't know about your issue
<ionstorm> ah
<calc> ionstorm: someone on the kernel team will probably have to look at your bug to determine what is causing it
<ionstorm> cool
<ionstorm> thanks calc
<calc> ionstorm: how far does it get into the boot process when it hangs?
<ionstorm> not far, let me look at the bug log I posted to know exactly
<ionstorm> well it gets to enabling processor 1/1 or something like that
<ionstorm> i dont have a digital camera to take a pic of it, it happens fast too
<ionstorm> loads quick and reboots instantly
<ionstorm> I hope those logs are a help in the bug report
<calc> asac: cool, saw the report about fixed ipw driver
<albert23> ionstorm: you could try and run a live cd with HT enabled, see if that works
<ionstorm> i will definately try that
<ionstorm> I will post the results on that report
<calc> ionstorm: oh ok
<ionstorm> right now im compiling another kernel to try
<ionstorm> could be just the generic kernel
<albert23> ionstorm: one remark: please add log files as attachment in launchpad, instead of pasting the text
<ionstorm> albert23, good idea
<ionstorm> i will definately do that in the future
<pochu> jdong: could you please check a backport failure? It doesn't look like the package's fault: http://sharkattack.media.mit.edu/inventory/view_log/174
<pochu> jdong: forget it, it's tracker's fault.
<Kopfgeldjaeger> nacht
#ubuntu-devel 2008-09-01
<theunixgeek> Would anyone like to do me a favor of going into Synaptic, checking off libgtk2.0-dev and libgtk2.0-doc for installation (just checking the check box, not installing unless you want to) and then go to File>Generate Package Download Script, please? as in this picture: http://2.bp.blogspot.com/_fs6jwQq0LQk/SLsbgxQZ7KI/AAAAAAAAAQw/FSqht56jDO8/s1600-h/Screenshot-Synaptic+Package+Manager+.png
<theunixgeek> hardy heron 8.04.0 please :)
<theunixgeek> and the script can just go on a pastebin somewhere
<theunixgeek> http://ubuntuforums.org/showthread.php?p=5702397#post5702397 :0
<theunixgeek> * :)
<crimsun> \sh: is this post-upgrade of nspluginwrapper 1.1.0?  did you purge and reinstall flashplugin-nonfree afterward?
<ion_> You mean dpkg-reconfigure flashplugin-nonfree?
<theunixgeek> please someone? :(
<theunixgeek> http://ubuntuforums.org/showthread.php?p=5702397#post5702397
<theunixgeek> it only takes 5 seconds
<cjwatson> theunixgeek: one moment, I need to remove those packages first
<cjwatson> theunixgeek: err, will intrepid do?
<lukehasnoname> http://mibbit.com/pb/cwQqez
<lukehasnoname> theunixgeek:
<lukehasnoname> there you go.
<lukehasnoname> And thanks to hitting execute instead of display, I have flooded my home folder.
<cjwatson> (I hope nobody's still running 8.04.0, BTW)
<lukehasnoname> Nobody would be, unless auto updates are off, correct?
<cjwatson> 00:09 <theunixgeek> hardy heron 8.04.0 please :)
<mika_videodev> Q: what is the status of kubuntu 8.10? can bugs still be filed and will the fixes make it to the 8.10 when it is released ?
<cjwatson> mika_videodev: feature freeze; yes, bugs can still be filed; depends on all the usual things (whether a developer is paying attention and has time, how complex and invasive the fix is, whether it's reasonably fixable, etc.) but there's no intrinsic reason why not
<mika_videodev> a part of lspci command output: 01:08.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
<lukehasnoname> theunixgeek_: http://mibbit.com/pb/34mLX0
<cjwatson> mika_videodev: please report bugs at bugs.launchpad.net/ubuntu rather than here, though
<theunixgeek_> lukehasnoname: thank you!!!! :D
<theunixgeek_> thank you so much!!!!
<theunixgeek_> thanks
<mika_videodev> in kubuntu 7.10 there's a problem with that. if in kaffeine, one tries to activate live dbv-c viewing, kaffeine will lock up. work-around: first play any mpeg2 video file or DVD. While it is playing, do command it to live DVB-C viewing mode. Works about 80% of the time, but sometimes kaffeine  locks up anyway (need to use kill command or click the X and answer yes, when KDE asks whether to kill the app)
<cjwatson> mika_videodev: please report bugs at bugs.launchpad.net/ubuntu rather than here
<cjwatson> also, 7.10 != 8.10
<cjwatson> was one of those a typo?
<mika_videodev> I know that, but is there s liveCD snapshot of 8.10 somewhere to download and try if it still has the ame problem ?
<mika_videodev> I am still using 7.10, no typo.
<cjwatson> mika_videodev: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-August/000470.html
<mika_videodev> <cjwatson>: which image do you recommend me to try? The normal 32-bit or the amd64-bit version? I am currently running 32-bit version, but I do have AMD-64-bit dualcore CPU 2300 MHz, and 4 Gigabytes RAM.
<_MMA_> mika_videodev: Try what you like.
<mika_videodev> is there any known problems using 64-bit versions of linux ? like in device driver support ?
<RAOF> No
<crimsun> ion_: sure, that will also work.  It's only important that nspluginwrapper is rerun.
 * NCommander smacks his head on the desk a few hundred times per hour :-)
<leleobhz> pacakge bug! The following packages have unmet dependencies: tzdata-java: Depende: tzdata (= 2008b-1ubuntu1) but 2008e-1ubuntu0.8.04 is installed.
<leleobhz> s/Depende/Depends/g
<leleobhz> all my repositories is updated and system upgraded
<Hobbsee> leleobhz: and irc is now the new bug tracker?
<leleobhz> no
<leleobhz> i only want before i file a bug if its really a bug
<leleobhz> or if someone got this too
<Hobbsee> can you run 'apt-cache policy tzdata-java', and pastebin it please?
<wgrant> I suspect that you don't have hardy-updates enabled for universe.
<Hobbsee> sorry, 'apt-cache policy tzdata tzdata-java'
<leleobhz> Hobbsee: http://paste.milk-it.net/919
<StevenK> Yup. What wgrant said
<StevenK> Enable hardy-updates universe, and apt-get update
<leleobhz> lets see
<Hobbsee> ah, eys
<StevenK> wgrant: Nice catch
<wgrant> StevenK: Not particularly, but thanks.
<leleobhz> added and dist-upgrading
<leleobhz> but tzdata is not included on update list..
<wgrant> tzdata-java should be.
<wgrant> tzdata should not.
<leleobhz> hmm
<leleobhz> now got no warning
<leleobhz> well, thanks :]
<wgrant> Excellent.
<leleobhz> (and sorry by false allarm)
 * wgrant disappears to another lecture.
<JustinF_> hello everyone
<ion_> Hi, doctor Nick!
 * pitti hugs the channel, good morning
<StevenK> pitti!
<pitti> hey StevenK
<StevenK> pitti: NBS hasn't been the same without you running your broom through it :-)
<pitti> heh
<Hobbsee> pitti!
 * pitti throws a gummybear to Hobbsee
<Hobbsee> \o/
 * Hobbsee throws the gummybear to StevenK, and looks for some chocolate
<Darklock> I pitti the fool!
 * StevenK grins
 * ScottK mentions that the MIR queue has been lonely in pitti's absence.
<ajmitch> hello pitti
<pitti> hey ajmitch
<pitti> ScottK: that's part of the backlog I have to grind through now :)
<ion_> Welcome back, pitti :-)
<ScottK> Welcome back.
<ion_> scottk: Thanks
<dholbach> goooood morning!
<ion_> Hi
<dholbach> hi ion_
<pitti> hey dholbach! *hug*
<dholbach> hi pitti
 * dholbach hugs pitti back
 * nxvl HUGS pitti 
<nxvl> pitti: we miss you!
<NCommander> hey jdong
<NLE> hi guys i need help in my VLC command, I always got an error "stream_out_transcode private debug: drift is too high" can anybody help me with my problem thanks
<\sh> crimsun: flashplugin works now, but again without doing any rtmp connections to an fms ... because of missing libs it seems
<\sh> oh good morning pitti :)
<pitti> hey \sh
<\sh> pitti: hope you had a good holiday :)
<pitti> \sh: yes, it was wonderful; lots of fresh air, food, exercise, and sleep, all the things I usually don't get :)
<pitti> \sh: two weeks bicycling through southern Sweden
<pitti> we made some 830 km
<\sh> pitti: I'm jealous...:)
<StevenK> pitti: Damn it! You undid all of the hard work keeping you in a darkened room at UDS!
<StevenK> :-P
<dholbach> pitti: you don't get food?
<dholbach> everybody: please cough up and let's send pitti some food
 * Mithrandir waves.
<dholbach> the poor guy is starving!
<pitti> I mean *lots* of food :)
<NLE> hi guys i need help in my VLC command, I always got an error "stream_out_transcode private debug: drift is too high" can anybody help me with my problem thanks
<pitti> due to being exposed to fresh air all the day, I ate twice as much as usual :)
<RAOF> It's a little known fact, but fresh air makes food evaporate from the body.
<Treenaks> RAOF: that would explain a lot!
<\sh> ok..now everybody is back from the weekend and from holidays...I'll have a question regarding tslib being in universe, but also being a dep of directfb which is in main...this screws up my work on ia32-libs
<crimsun> \sh: what does 'now' mean?  after nspluginwrapper is rerun?  (the ia32-libs bits are known, but someone has to fix the scalability problem.)
<\sh> crimsun: after I reinstalled the whole flashplugin stuff , meaning: purging and reinstalling the base functionality is back..
<\sh> crimsun: and yes, I'm dealing with ia32-libs right now...see the question above :)
<crimsun> \sh: right, that was debugged/discussed in -mozillateam last week.
<dholbach> pitti: do you know anything about the seahorse-agent situation?
<pitti> dholbach: if you mean the gpg part, it still needs to be packaged
<StevenK> pitti: stardict is in NBS, and will FTBFS if it's rebuilt. There are no Ubuntu changes, and the new Debian revision in unstable looks like it will solve it, do I need a FFe to get you to sync it?
<pitti> StevenK: no, it's just a new debian revision; I can sync it right now
<pitti> StevenK: is there a bug for it already? (if not, don't bother)
<StevenK> pitti: There isn't, I'm pulling stuff from NBS.
<dholbach> pitti: I see
<dholbach> hiya thekorn
<StevenK> pitti: Note "looks like it will solve it", I'm test building to see if it holds.
<thekorn> good morning dholbach
<pitti> StevenK: ok, I prepared the sync, tell me when/if to commit it
<StevenK> pitti: Could you also add running a broom through NBS to your todo list if you haven't already? :-)
<\sh> who is responsible for reviewing MIRs?
<StevenK> The ubuntu-mir team
<\sh> lol
<\sh> doko and pitti...who else ,-)
<\sh> I stop asking "who is reponsible for this and that"...the answer is always pitti somehow ;)
<pitti> \sh: you could just look at the team member list :)
<\sh> pitti: I just did
<\sh> pitti: and if you are relaxed, just promote tslib to main (as written on https://wiki.ubuntu.com/MainInclusionReportTslib) so I can start refreshen the ia32-libs stuff and start support the new flashplugin stuff which is missing ;)
<StevenK> \sh: MIRs are done as bugs now
<\sh> StevenK: pitti: bug #255275
<ubottu> Launchpad bug 255275 in tslib "MIR for tslib" [Undecided,New] https://launchpad.net/bugs/255275
<\sh> nevermind..
<pitti> \sh: ia32-libs is in universe, so what does it have to do with MIRs?
<\sh> pitti: directfb is pulled in, and it needs tslib...which is not promoted to main...so freshen fails
<pitti> \sh: seems that ia32-libs needs to be fixed to pull from universe then, although I had expected that it does that already
<\sh> pitti: it is
<\sh> pitti: it pulls from universe...but directfb is manual dep wait because of tslib in universe;)
<pitti> oh, I see
<\sh> pitti: so source is new, but binaries are old
<pitti> what do we need directfb for in main? sdl?
<\sh> pitti: ask doko ;)
<\sh> ScottK: do you agree with bug #261885 ? arj in main for clamav?
<ubottu> Launchpad bug 261885 in arj "MIR for arj" [Undecided,New] https://launchpad.net/bugs/261885
 * \sh really wonders who is using arj these days? I mean we are totally out of the 80ties and 90ties where it was famous being used in mailboxes
<cjwatson> StevenK: (I did at least the empty stuff from NBS on a couple of occasions while pitti was away, BTW; just to dispel the idea that nobody looked at it at all ...)
<pitti> ScottK: argh, so we now need to support every possible unpacker format for clamav? they can't become suggests: or something?
<pitti> even gzip has vulnerabilities these days, I don't want to imagine how many zoo, arj, etc. have...
<StevenK> cjwatson: Ahhh, I thought I noticed it get cleaned up a few times.
 * StevenK kicks stardict for failing with an obtuse error.
<dholbach> hi blueyed
<dholbach> hi seb128!
<seb128> hello dholbach!
<StevenK> pitti: Right, gucharmap is broken, I'll need to fix that first.
<seb128> StevenK: what is broken? there is a new version to package btw ;-)
<StevenK> seb128: There is no .pc file in the -dev, so things using pkg-config to check it fail
<seb128> are you sure?
<StevenK> Fairly sure
<seb128> the .pc name changed this cycle
<seb128> and it's correctly installed there
<StevenK> Ah, nice. That would explain it. stardict is looking for gucharmap.pc
<StevenK> Ah ha, gucharmap-2.pc
<StevenK> pitti: That sync can't be processed, it needs an Ubuntu change. :-(
 * StevenK kicks stardict
<persia> james_w: To avoid further discussion in the mailing list irrelevant to the original subject, what's the best forum to discuss the use of bzr for distributed development and impacts for cases where packages are only touched once?
<james_w> persia: I'm not sure. I assume you would like a mailing list?
<azeem> (there's the vcs-pkg project/lists I think)
<persia> james_w: Or just some of your time to help understand either what I'm doing wrong with regard to performance, or whether we can identify specific issues that might need attention.
<james_w> azeem: yes, I'm on it thanks, I think this is not exactly its mandate, and Ubuntu-specific to boot
<james_w> persia: for that then private email or IRC is fine for me
<dholbach> can we get 1.6 into hardy-backports? :)
<james_w> persia: I would like to have the other discussions though. Perhaps just breaking the thread on ubuntu-devel would let your topic breathe while allowing us to have a discussion
<james_w> dholbach: there's a 1.6.1 this week, once that's in and tested a but I can request a backport
<dholbach> cool :-)
<stefanlsd> im looking forward to the bzr session in dev week.   (totally unfamilair with bzr.  i know some git)
 * mpt cries
<mpt> Ctrl Alt Backspace = stupidest keyboard combo ever
<Robot101> :(
<ion_> I donât know what i do differently, but i never manage to hit it accidentally.
<cjwatson> mpt: https://blueprints.launchpad.net/ubuntu/+spec/xorg-ctrl-alt-backspace; unfortunately deferred from intrepid due to apparent dissension
<cjwatson> (read the wiki rather than the spec title; it's not just about disabling it any more, just making it harder to activate)
<mpt> I doubt any of the "make it harder to trigger" techniques would have helped me
<mpt> I was using Ctrl Backspace to delete words and hit Alt by mistake
<ion_> Ah, thatâs it. I always use ^W.
<mpt> If it had done nothing, I would have just pressed it more/longer, assuming that Ubuntu was in one of its frequent snoozes
<dholbach> mpt: I know your pain
<ion_> How about an instant popup that says âHit Ctrl-Alt-Backspace again to blahblahâ?
<cjwatson> ion_: see the discussion in the spec, please
<ion_> cjwatson: That was an answer to âI doubt any of the techniques would have helped meâ.
<cjwatson> ion_: an answer explicitly addressed in the spec as "unimplementable"
<cjwatson> and with other UI deficiencies noted there
<ion_> Ok
<cjwatson> (well, clearly it's possible to do anything in theory, but that would at least require turning an awful lot of stuff upside down for this one thing)
<cjwatson> and furthermore a dialog would completely fail to address the cases where you *do* need ctrl-alt-backspace for real, e.g. when most of X has locked up
<ogra_> if you are lucky hal didnt start up ... then ctrl-alt-backspace wont restart your session </sarcasm>
<ion_> cjwatson: alt-sysrq-k ;-)
 * ogra_ sat on a blocked gdm screen to often already since intrepid ... no input at all (!) without hal ... not even console switching ...
<cjwatson> we should try to arrange for hal to start earlier; it's very late for what's now such a critical service
<ion_> And as for the display chip possibly being in a broken state after killing X with sysrq, well, hopefully the move-graphics-drivers-to-kernel-and-make-X-use-common-framebuffer-with-virtual-consoles thing gets implemented soon. :-)
<ogra_> cjwatson, no, X should have a fallback mechanism to have *something* if there is no hal
<cjwatson> ogra_: that too
<cjwatson> X is not the only thing that is coming to depend on hal, though
<ogra_> or an automatism to switch you to tty1 or some such
<cjwatson> bryce: perhaps bullet-proof-x should detect this situation
<ion_> How about X simply refusing to start â at least by default â if thereâs no HAL?
<mpt> As Ubuntu becomes more popular, the proportion of users for whom Ctrl Alt Backspace is useful decreases, so the average benefit decreases, while the average harm remains constant
<ogra_> cjwatson, doesnt that need an input mechanism as well ? (note that there is also no mouse without hal)
<cjwatson> ogra_: bullet-proof-x is for when X crashes, and takes its input on the console at least to start with
<ogra_> ah, i thought thats the part that you get to configure yur graphics card in vesa mode
<ogra_> (which needs a mouse for me)
<didrocks> pitti:
<pitti> hi didrocks
<persia> mpt: How does the proportion of users who wish to recover from crashed X decrease with wider penetration?
<cjwatson> ogra_: in any case, the failsafe X configuration seems to manually configure input devices, so that should bypass input hotplug and not require hal, I think
<ogra_> ah, i havet had that screen in intrepid at all yet ... if it does that then it's fine
<mpt> persia, the proportion who *want* to recover from an error of that sort doesn't decrease, but the proportion who know that that's how to do it does.
<cjwatson> ogra_: I think I'm misremembering and you're correct that it goes into X
<didrocks> pitti: (Hi, sorry for the later hilight) for OpenWeekdev, huats and I will handle a session on patching a package. We were thinking about based the session on your previous work as it has been well understandable (adding quilt pach system, eventually)
<persia> mpt: Surely that's a matter of education, rather than removing the capability, no?
<ogra_> and i think currently X gnores all input stanzas in the config file (there was a patch though that enabled it again)
<pitti> didrocks: NB that my original notes already cover quilt as well; just in some IRC sessions I didn't get to it
<cjwatson> I disagree that education helps; arranging that the facility is harder to invoke by accident would be fine
<pitti> didrocks: but it's also documented in the wiki
<cjwatson> (the reason education doesn't help is that even educated users hit it by mistake sometimes)
<didrocks> pitti: yes, we will try to have enough time to speak about it
<huats> pitti: sure
<huats> (hey btw :))
<pitti> hey huats
<persia> cjwatson: I meant education that it was possible to so recover, not that they shouldn't press that combination of keys
<didrocks> pitti: it was just to ask you if we can base our speech on your previous session :)
<mpt> persia, what cjwatson said. And also, where would you propose putting this education? On the CD sleeve? In the installer?
<cjwatson> I don't agree that facilities should be removed simply because their use diminishes; repeatedly applying that principle is a good way to irritate a different 2% of your users each time
<persia> The idea is that the facility *should* be useful for any affected users, and not get hit accidentally.
<pitti> didrocks: of course, it's all "free software" :)
<cjwatson> it doesn't take a very long time of applying that principle before you've irritated most of your users
<didrocks> pitti: thanks a lot :) Will try to be as good as you as a teacher :)
<huats> didrocks: there is no way we can be as good as pitti ;)
<persia> mpt: Within the system: as long as it's sufficiently difficult to accidentally trigger, it's useful as part of the documentation.
<pitti> didrocks: thank you for covering the session; I can lurk in it and be a fallback for questions, if you want
<huats> pitti: that would be a great asset thanks martin
<didrocks> pitti: with pleasure, if you can find the time :)
<cjwatson> it is a fallacy to say that every feature not manifestly obvious to every single user is useless, I feel
<pitti> but how is ctrl+alt+backspace easy enough to hit accidentally?
<mpt> persia, as the user base increases the proportion who read anything labelled "documentation" also decreases.
<mpt> cjwatson, is anyone suggesting that?
<cjwatson> pitti: I do it often enough to be irritating
<cjwatson> mpt: I find your argument distressingly close to that position ...
<mpt> I'm saying that the benefit decreases as the harm remains constant
<mpt> I'm not saying that the benefit is zero
 * ogra thinks a cancel/ok dialog with proper naming would suffice
<stefanlsd> pitti: i was hitting it pretty often in some application. cant remember which.
<cjwatson> mpt: and I'm saying that the correct response is to reduce the harm, not to remove the benefit
<persia> mpt: I don't agree that the benefit decreases, your low opinion of users notwithstanding.
<cjwatson> ogra: for ctrl-alt-backspace? a dialog isn't feasible, as I said above
<pitti> cjwatson: wow, your cat/dog/whatever must have a knack for hitting those three keys :)
<cjwatson> pitti: what usually happens is that I was holding down ctrl+alt for something else, then wanted to delete some text and forgot to let go for ctrl+alt
<mpt> persia, nice fallacy you got there. :-)
<cjwatson> the accident is hitting one while the others are down, not hitting all three at once
<persia> pitti: It can be trivially easy with some hardware configurations: the handykey being one.
<pitti> ogra: in most cases when you actually want to kill X, popping up a dialog (or doing an action in it) is precisely what *doesn't* work any more...
<ogra> hmm ... right
<cjwatson> mpt: the reason I drew the conclusion you did was that your immediate response was to remove the benefit; that's a response that tends to arise from assuming that each 2% doesn't need to be cared for, I find
<persia> mpt: OK.  To put in less contentious terms: I don't agree that the benefit isn't there just because someone doesn't know about it: I do agree that triggering it by accident is unfortunate, but not that this is worth the cost of removing the ability to do this, nor creating wide variance from historically available documentation.
<cjwatson> I'd like to care for the 98% *and* the 2%, not just the 98%
<mpt> cjwatson, my immediate response was to label the keyboard combo as stupid, not the function in general.
<cjwatson> I agree that the keyboard combination is unfortunate
<cjwatson> one reason for it is that it needs to be largely independent of keyboard maps, so a relatively small number of keys (all of which are in common use) are available
<persia> mpt: One issue with changing the key combination is that there is vast amounts of documentation indicating that this specific key combination is the appropriate way to restart X when it locks.  Not support that may cause user confusion.
<mpt> persia, sorry, I left out the word "average" once there. The average benefit is partly dependent on the proportion of people who know about it, which is a function of how long you've been using an X-based system.
<cjwatson> the available keys are essentially the function keys, backspace, enter, escape, tab, cursors, and the insert/delete/etc. block
<persia> mpt: I can accept that argument, although I think it's a function of both how long one has been using such a system, and how one tends to seek support when one has an issue.
<cjwatson> I think it's important to remember that the people who know about it and would be annoyed by its absence are likely to be the most vocal users of Ubuntu right now, i.e. decision-formers
<mpt> exactly
<cjwatson> I've seen one too many bug recently where we made a well-intentioned attempt to improve matters for a big chunk of our userbase, and pissed off people who'd been using Ubuntu since Warty as a consequence
<cjwatson> this is not an argument for never changing anything, of course, just for considering the people left behind
<fta_> pitti, could you please have a look at https://code.edge.launchpad.net/~fta/apport/apport/+merge/758 ? I proposed a fix 2+ weeks ago
<pitti> fta_: right, I saw the page this morning and kept it open for processing ASAP
<mpt> persia, some people will not realize they have an "issue" at all, they'll just think that Ubuntu crashes occasionally when they're typing. :-)
<pitti> fta_: I was away on holiday in the last two weeks, and I didn't get a mail about the request
<fta_> pitti, i figured that out, no problem
<persia> mpt: Indeed.  Making it harder to break the system would be good.  I'm just not sure that disabling a useful feature is the right way to do it.
<seb128> hey fta_, any news about the libcairo update?
<fta_> pitti, someone pushed a new apport in the meantime so there is probably a conflict in changelog
<fta_> seb128, hi, glad you ask. i was about to ping you
<persia> I have one system that regularly has X crashes: when I can invoke the keystroke fast enough, I don't need to reset the PCI bus a couple times to boot again.  Perhaps this system ought be recycled, but it's very useful to me.
<pitti> fta_: that sounds trivial to fix
<fta_> seb128, i've been using this new cairo for 2 weeks now, i see a small difference in the lcd filter but other people are complaining too so it may not be my cairo... see http://ubuntuforums.org/showthread.php?t=902556
<fta_> seb128, for me, it's perfectly acceptable, not like in that screenshot at all
<seb128> fta_: ok, seems good enough to upload the new cairo then, where is you package update? ;-)
<fta_> seb128, i can update my debdiff (as i added 03_from_git_fix_lcd_filter_default.dpatch since the 1st one)
<fta_> i need 2 secs.
<fta_> seb128, http://www.sofaraway.org/ubuntu/debdiff/cairo_1.7.4-0ubuntu1.diff.gz http://www.sofaraway.org/ubuntu/debdiff/cairo_1.7.4-0ubuntu1.dsc
<seb128> fta_: thanks
<bigon> seb128, must I ask a UVFe for gnome pkg in universe (like empathy) or such pkg automatically get UVFe?
<wgrant> bigon: Why would universe be different? We have our policies too.
<seb128> bigon: GNOME has a standing exception so no need to ask one to update it
<bigon> great
<seb128> wgrant: GNOME has a standing freeze exception
<NCommander> pitti, I think you need to check who submits give-back bugs, I"m not a core-dev :-)
<seb128> NCommander: hey
<wgrant> seb128: Ah, I see. Some people have historically ignored the fact that FF applies to universe as well.
<NCommander> Ooh, seb128
<pitti> NCommander: oh, I just saw dholbach's mail
<NCommander> seb128, I haven't seen you online in awhile
<NCommander> pitti, Don't worry, we still love you :-)
<seb128> NCommander: I was on holidays
<NCommander> seb128, wow, what is this holiday you speak of?
<NCommander> seb128, you've missed my work since you went away :-P
<seb128> ;-)
<seb128> NCommander: did you get pangomm in shape? ;-) looking for other updateS?
<seb128> updates
<NCommander> er, well
<NCommander> seb128, https://edge.launchpad.net/~sonicmctails - the Xubuntu guys stole me
<NCommander> (although I did get a FTBFS fix for update-notification uploaded)
<seb128> lol
<seb128> NCommander: going to update libgsf, goffice and gnumeric then? ;-)
<NCommander> seb128, well, as revenge for disappearing, I went and processed the entire outstanding hardy backports queue, so roughly 40-50ish bugs await the archive admins ;-)
<NCommander> (my revenges are usually producive and usually result in someones mailbox getting flooded with bug fixes)
 * NCommander looks on the status of pangomm
<NCommander> Wooo, STILL in the NEW queue
<seb128> NCommander: can you get fake sync for ubuntu? ;-)
<NCommander> You don't ask much, do you :-P
<NCommander> (knowing my luck, upstream has released a new pangomm)
<seb128> NCommander: there is a new GNOME due today so they will probably
<seb128> NCommander: if you want to do some updates you are welcome to do so btw
<NCommander> Ok, hold on
<NCommander> Rolling a fast sync for our lovable archive admin
<NCommander> On its way to my PPA
<NCommander> seb128, that was notification-daemon who's FTBFS I fixed
<NCommander> and I made sure the changes made it into the packaging teams BZR :-)
<seb128> cool
 * NCommander tries his best
<NCommander> you could add me to ubuntu-desktop so I could commit my work to your bazaar branch
<NCommander> ;-)
<NCommander> seb128, my PPA rejected pangomm -_-;
<NCommander> Says I already uploaded it with the same version
<seb128> which is probably true ;-)
<NCommander> Uploading the source package somewhere you can get to it
<NCommander> which is easier said than done since I can't think of a public server I have access to ATM
<seb128> NCommander: attach the diff.gz and .dsc to a bug?
<seb128> I can get the tarball upstream
<NCommander> o
<NCommander> *ok
<NCommander> seb128, https://bugs.edge.launchpad.net/ubuntu/+bug/254050
<ubottu> Launchpad bug 254050 in ubuntu "[needs-packaging] pangomm-1.4" [Wishlist,Fix released]
<seb128> NCommander: thanks
<NCommander> my list of uploads grows
<NCommander> *strokes beard*
<seb128> NCommander: wants some updates to do then? ;-) did you start on the gtkmm one?
 * NCommander is away: This creature sleeps beyond the reaches of time itself
<Hobbsee> !away | NCommander
<ubottu> NCommander: You should avoid noisy away messages in a busy channel like #ubuntu, or other Ubuntu channels; it causes excessive scrolling which is unfair to new users. Use the command "/away <reason>" to set your client away silently.  See also Â«/msg ubottu GuidelinesÂ»
<NCommander> seb128, not at the moment, need some sleep
<seb128> ok
<NCommander> Lets try that again
<seb128> NCommander: 'night
<NCommander> good
<NCommander> ... well
<NCommander> Expect I'm unmarked away when I speak ;-)
<azeem> NCommander: consider using screen_away.pl in case you use irssi
<cjwatson> azeem: thanks, hadn't seen that before
 * wgrant finds it excellent.
<wgrant> persia: Wow, is http really faster than bzr+ssh for you?
<persia> wgrant: considerably, although I have a high-bandwidth high-latency environment, which I think is rare.
<wgrant> That's rather surprising.
<seb128> NCommander: the GPL text should be in the tarball since there is some file under the GPL licence
<persia> Could well be due to some QoS adjustments by my provider: there's a lot of focus on giving the appearance of fast speeds here, and there's only so much more improvement available to be done to the infrastructure.
<wgrant> Ah.
<persia> I also suspect caching, as repeated http runs against the same source got successively lower speeds, whereas pushing the pulled branch, and checking that out went back to the higher speeds.
<cjwatson> successively *lower* speeds?
<cjwatson> anti-caching?
<persia> s/speeds/times/
<cjwatson> aha :)
<persia> Thanks for the correction :)
<jpds> cjwatson: Thanks for the manpage corrections.
<cjwatson> no problem
<siretart> cjwatson: assuming that wpasupplicant would produce a working udeb at some point, in what seed would it need to be in in order to end up on the alternate cd?
<cjwatson> udebs mostly go in the installer seed
<cjwatson> (in platform.intrepid)
<siretart> I see. thanks
<cjwatson> is somebody working on adding wpa support to netcfg?
<cjwatson> hmm, apparently so (stuff on debian-boot)
<siretart> I believe so, but nobody has cared to contact the wpasupplicant maintainers in debian about this yet
<siretart> ah, it seems kel has been notified. ok
<ogra_> woah, scrollkeeper is noisy with current livefs builds
<pitti> didn't we switch to rarian nowadays?
<ogra_> no idea, scrollkeeper is still seeded
<ogra_> and the postinst didnt change yet apparently ...
<ogra_> seems there are issues with XInclude in /usr/share/gnome/help/libs/C/legalnotice.xml
<ogra_> /usr/share/gnome/help/libs/C/legalnotice.xml:13: parser error : Extra content at the end of the document
<ogra_> <copyright>
<ogra_> ^
<ogra_> heh
<pitti> zul: do you have any tester for bug 180493 or can verify yourself with the hardy-proposed .debs? and can you please upload the fix for bug 242325 to intrepid? after that is done, I can consider accepting the next samba SRU which is sitting in the queue
<ubottu> Launchpad bug 180493 in samba "[SRU] nmbd shuts down when network disconnected" [Undecided,Fix committed] https://launchpad.net/bugs/180493
<ubottu> Launchpad bug 242325 in samba "[SRU] Samba with "ldap passwd sync = only" fails to change passwords" [Undecided,Confirmed] https://launchpad.net/bugs/242325
<pitti> seb128: FYI, i386 retracer finished consolidation, python duping in progress (works fine)
 * seb128 hugs pitti
<seb128> pitti: thanks for the sru copies, I asked to slangasek before my holidays but apparently he did do those
<pitti> seb128: feel free to do them yourself in such cases (verified, and forgotten to copy)
<seb128> pitti: right, will do next time, I was a bit in a hurry and I though slangasek would look at those while we were in holidays
<pitti> fta_: I don't understand your apport change, the regexp: ((firefox|seamonkey|flock)[^\s]*)
<pitti> fta_: why the ^\s*?
<pitti> fta_: shouldn't it match for "firefox %s", too?
<pitti> fta_: oh, it would already, it's just a very confusing regex
<Adri2000> pitti: zul: bug #222804 as well, it seems the fix wasn't even uploaded...
<ubottu> Launchpad bug 222804 in fail2ban "[SRU] fail2ban fails to start after reboot" [High,Confirmed] https://launchpad.net/bugs/222804
<Adri2000> cjwatson: amsn still on your radar? :)
<fta_> pitti: the idea is to match firefox, firefox-2, firefox-3.0, firefox-3.1, seamonkey, seamonkey-2.0, etc...
<pitti> fta_: oh, I see what you mean now
<fta_> pitti, someone requested opera too but i don't know wherever opera uses -new-window, or --new-window or something else.
<fta_> should be trivial to add now
<pitti> fta_: I'll fix the epiphany regex and merge
<fta_> pitti, it is not correct ?? i tested it
<pitti>                         browser = re.compile('(epiphany[^\s]*)', preferred_browser)
<pitti> fta_: before you used "(epiphany)"
<pitti> fta_: suppose you have a program epiphany-2.22
<pitti> fta_: then the regex would only deliver "epiphany" and you'd call the wrong program
<fta_> pitti, well, should not happen but ok, fine with me :)
<pitti> fta_: just for the sake of consistency with the other re, and correctness :)
<fta_> sure
<pitti> fta_: thanks for the fix!
<fta_> np, my default browser is firefox-3.1 so i needed this fix too ;)
<dholbach> how is the X utility called again with which it's possible to run scripts that require X without having an xsession?
 * dholbach routinely forgets its name
<seb128> dholbach: xvfb-run?
<dholbach> that's the one, thanks seb128!
<seb128> you're welcome ;-)
<dholbach> seb128: I know... it's my own fault - if I was still on the Desktop Team..... :-)
 * dholbach hugs seb128
<seb128> lol
 * seb128 hugs dholbach
<asac> james_w: http://paste.ubuntu.com/42414/
<asac> james_w: why does bzr builddeb needs to be so picky and fail on that?
<james_w> asac: that's fixed in my branch
<james_w> asac: sorry for introducing the bug
<asac> james_w: no problem
<asac> james_w: will the "default result-dir" change also be reverted?
<asac> (i had to put result-dir in builddeb.conf)
<james_w> asac: I don't think so
<dholbach> james_w: bzr bd --figure-out-what-my-problem-is-and-do-something-about-it isn't a default option yet? :-)))
<james_w> asac: it just won't fall over if you specify the result-dir to be the same as where the packages end up
<asac> james_w: ok. however, the fact that --result=DIR is the option while builddeb.conf needs result-dir=DIR isnt obvious ;)
<james_w> dholbach: that's planned for version 24
<dholbach> james_w: I asked for it ages ago ;-)
 * dholbach hugs james_w
<james_w> asac: ah, I hadn't noticed that. I should probably unify them somehow.
<james_w> asac: thanks for the bug
<asac> james_w: yes. maybe use --result-dir in command line and keep support for --result= ...
<asac> at least -dir is in line with the rest
<james_w> yeah
<james_w> asac: bug 263643
<ubottu> Launchpad bug 263643 in bzr-builddeb "Option is --result, while configuration option is "result-dir"" [Low,Triaged] https://launchpad.net/bugs/263643
<asac> james_w: another good thing would be: --export-upstream-dir=... so
<asac> i can actually place them into --tarballs-dir directly ;)
<cjwatson> Adri2000: done now, sorry for the delay
<asac> in that case bzr builddeb should bail out if there is a tarball with the same upstrewam version imo
<james_w> asac: what would --export-upstream-dir do?
<asac> james_w: it would export the orig.tar.gz produced in the given directory
<asac> james_w: atm it gets into --build-dir=...
<james_w> it goes to --tarball-dir I think
<asac> james_w: no it doesnt ... at lesat if you use the default for --tarball-dir
<asac> (unless it changed in 2.0)
<asac> nope. i can confirm that it doesnt get placed inteo ../tarballs/ ... just in --build-dir=...
<asac> i think that makes sense ... one probably doesnt want to wipe a good tarball in --tarball-dir= ... unless explicitly stated
<james_w> asac: ah, yeah, I was thinking of the uscan downloading
<Adri2000> cjwatson: thanks!
<asac> james_w: so ... option a) use --export-upstream-dir=... and overwrite whatever exists there ... _or_ copy to --tarball-dir unless a tarball with the same name exists there
<asac> that would be my ideas on this
<Q-FUNK> howdy!   could someone look into bug #259036 ?
<ubottu> Launchpad bug 259036 in xserver-xorg-video-geode "Please sync xserver-xorg-video-geode 2.10.1-3 (main) from Debian experimental (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/259036
<james_w> asac: there are two use cases here, and I think it was originally written for the wrong one
<james_w> asac: but I'm not sure it's possible to do the right one in a way that is both useful and correct
<Q-FUNK> oh, thanks! :)
<cjwatson> Q-FUNK: synced on the basis of bryce's +1. I'm not going to look at the SRU until somebody offers up a candidate patch that meets the usual requirements though; perhaps the X team can help with that
<Q-FUNK> cjwatson: understood and agreed. the Hardy SRU is more involved.
<cjwatson> "fixing deficiencies of packaging" would not be a normal valid SRU target
<cjwatson> fixing hardware that's just plain broken can be provided that the risk of regression elsewhere is very carefully handled and limited
<cjwatson> anyway, I don't really want to get into that; a sync was quick :)
<Q-FUNK> indeed :)
<asac> james_w: --result-dir isnt honoured for source bits :(
<james_w> asac: using -S or --source, or doing something like "--builder 'debuild -S'"?
 * ogra curses 
<ogra> my laptop doesnt survive DPMS
<ogra> tjaalton, bryce, is there anything known with intel ? it *seems* that i dont have any input after the screen switched to dark ...
<tjaalton> ogra: with .27?
<tjaalton> kernel
<ogra> though killing X via ssh didnt bring anything back either
<ogra> yeah
<tjaalton> right
<ogra> ah, known ?
<tjaalton> seen that too, same with .26 but fine with .24
<tjaalton> so I'd blame the kernel :)
<ogra> i didnt have it with .26
<ogra> i use to keep my lappie running over night and find a black screen since .27 in the morning
<ogra> so seems to be a kernel issue
<tjaalton> think I tried .26 when I first saw that
<tjaalton> downgrading the driver at least didn't help
<ogra> hmm, looking at #ubuntu my xchat stopped logging at 16:07 (i left the machine at 16:04 and got back around 17:00 (20 min ago))
<ogra> so its triggering something else, though nothing seemed to hang when i looked via ssh
<ogra> weird
<ScottK> pitti: Not every possible packer format.  Those two are the ones that are currently recommends from Debian.  There are plenty of others that are not.
<Don-S> I have written a program in Python and would like to make a package out of it, but I'm not really sure what to do...
<Don-S> Can anyone help me on it?
<ScottK> Don-S: #ubuntu-motu is a better place for that kind of question.
<Don-S> Okay, thanks.
<geser> are there any known issues with xvfb? I ask because I've seen some builds where the test suite failed because xvfb won't start
<Ng> ogra: fwiw disabling compiz seems to "help" with that, fsvo help meaning "it doesn't crash, but it's slow and ugly instead"
<ogra> aww
<lool> Hey what do you people do to solve "X--tag=CC: command not found" kind of libtool build failures with Ubuntu's libtool?  I did libtoolize  :-/
<lool> what I run in my autofoo patch is: libtoolize --force --copy && aclocal-1.10 -I m4 && automake-1.10 --add-missing --force --copy && autoconf && rm -rf autom4te.cache
<cjwatson> lool: try autoreconf -i -f
<cjwatson> lool: http://lists.gnu.org/archive/html/autoconf/2008-07/msg00047.html
<lool> Hmm right, I could have used the official tool rather than being clever
<Keybuk> it's worth noting as well that libtoolize --force doesn't do what you think
<Keybuk> --force means "break my build"
<cjwatson> Keybuk: interesting that autoreconf passes --force through to libtoolize
<lool> cjwatson: (thanks for the pointer)
<cjwatson> (should we not be using autoreconf -f either?)
<cjwatson> also, libtoolize --install isn't documented in its man page
<cjwatson> and the info docs appear not to be packaged
<lool> So I should be running libtoolize --force --copy --install instead?
<lool> cjwatson: libtool-doc has an info?
<cjwatson> I think that's the idea, but I've just been converting stuff to autoreconf
<cjwatson> oh, so it does. I wonder why 'info libtool' ignores it then
<lool> I don't like autoreconf because it tends to run more stuff than needed and wont pick the upstream versions of the tools if possible
<cjwatson> perhaps because libtool-1.gz is missing and libtool.gz only has references to it rather than any actual documentation
<cjwatson> bug 254182
<ubottu> Launchpad bug 254182 in libtool "info docs are broken" [Undecided,New] https://launchpad.net/bugs/254182
<Keybuk> I can't think of any situation where --force is necessary
<lool> Keybuk: I wonder whether symlinks are converted to real files if you don't run it
<lool> If you don't pass --force that is
<cjwatson> I think I was led to believe that the autotools wouldn't update existing files reliably if you didn't use --force
<cjwatson> this may have been due to inadequately precise documentation
<Keybuk> it's probably more likely to do with the strange state that Debian kept automake in for a while
<Keybuk> it may not have behaved properly, that led everyone just to always use --force
<Keybuk> --force is only intended for "this is broken, fix it!"
<lool> I jsut ran libtoolize and it converted a real ltmain.sh into a symlink
<Keybuk> and if used without --install means "remove the broken stuff, but don't put anything new back"
<Keybuk> lool: --copy ;)
<lool> Keybuk: And --copy wont fix it
<lool> So I think --force is used in e.g. gnome-autogen and misc autogen script to make sure no symlinks are used
<cjwatson> Keybuk: mind if I fix libtool's info docs?
<Keybuk> cjwatson: please do, I saw the bug and couldn't work it out
<Keybuk> info and me are not friends
<cjwatson> it's a matter of appending one line to debian/libtool.info I think
<Keybuk> lool: if you run libtoolize --copy it won't convert a real ltmain.sh into a symlink
<Keybuk> if you do run it without, it may convert, and then won't convert it back
<Keybuk> that's one of the cases for --force
<Keybuk> but you only care if you do it wrong in the first place
<lool> Keybuk: No, but if a maintainer ever ran libtoolize, it will convert to a symlink
<Keybuk> in general
<Keybuk> "autoreconf -i" when checking out of revision control
<lool> And then you need --force to fix it
<Keybuk> and whenever you want to update to newer tools
<Keybuk> otherwise rely on automake's inbuilt maintainer script handling
<lool> The point is, if you can run a single command which always fixes this situation, it's easier than having to distringuish between two use cases
<lool> But I heard you that "libtoolize --force" might break stuff
<lool> I'm just trying to explain the likely rationale with using --force in many autogen scripts
<Keybuk> there's no rationale for autogen scripts in the first place ;)
<cjwatson> I find autogen useful to keep sanity checks in, followed by running autoreconf
<cjwatson> also, autoreconf doesn't call gnulib-tool yet
<lool> gnome-autogen allows forcing this or that autofoo version you're using
<cjwatson> ah, now, I definitely don't believe in forcing autotools versions
<cjwatson> it's an excuse for not writing correct code
<lool> Unfortunately, some GNOME modules rely on automake 1.7
<Keybuk> lool: err, why not just use AM_INIT_AUTOMAKE([1.7]) ?
<cjwatson> right, so they've just arranged to forget about the bug :)
<lool> Keybuk: I don't know; they don't use it though :)
<cjwatson> lool: do you mean "exactly 1.7" or "at least 1.7"?
<cjwatson> AM_INIT_AUTOMAKE is the latter
<lool> Exactly 1.7 as in newer would break stuff
<Keybuk> newer shouldn't break things
<Keybuk> those are called "regressions"
<cjwatson> Keybuk: there aren't internal interfaces in 1.7 that automake broke?
<Keybuk> cjwatson: shouldn't be
<cjwatson> (but that people were using anyway)
<Keybuk> oh, if they were doing crazy shit, suuure :p
<cjwatson> that is surely the common case with the autotools ;-)
<lool>         Autom4te::Channels::msg('ac_config_headers="$ac_config_headers config.h"\x{a}\x{a}\x{a}#\x{a}# For eac...', 'configure.in:154', 'warning: The macro `AM_DISABLE_STATIC\' is obsolete.\x{a}You shou...') called at /usr/bin/autom4te line 1020
<Keybuk> in theory, the option allows compatibility too
<lool> Is what autoreconf -i tells me after setting version to 1.7
<Keybuk> so if you say 1.7, and 1.12 breaks something, it can see you wanted 1.7 and behave that way anyway
<Keybuk> gettext does this
<Keybuk> lool: that's a warning?
<lool> aclocal: autom4te failed with exit status: 1
<lool> is how it fails
<Keybuk> that's a bug ;)
<Keybuk> it's clearly trying to emit a warning ;)
<lool> Right; I believe there are many requires changes to get gtk+ and other GNOME modules of comparable size to build with newer autofoo
<lool> Upstream even said they would take patches :)
<Keybuk> I tried that with GNOME
<Keybuk> I got told they were porting to scons, or cmake, or some other thing
<lool> Some modules now support two build systems   :-(
<Keybuk> autostuff's main problem is that it's too easy to get at the innards
<Keybuk> and too easy to get wrong
<lool> Keybuk: But I don't think platform libs are in that camp; some module maintainers might like it, but most people have learnt autofoo anyway
<cjwatson> should be msg $cat, $loc, "warning: $msg", (type => 'warning'); shouldn't it?
 * lool finds it a pity to require people to write in so many various syntaxes to update autotools
<cjwatson> (on autom4te:1020)
<ScottK> cjwatson: Thanks for the pass over hardy-backports.  It's been wanting for some time.
<cjwatson> and probably 1024 too
<cjwatson> ScottK: only partial, I'm afraid, but got the list down a bit
<cjwatson> hmm, actually, isn't the problem that ac_config_headers=blah is being passed as the message category? that's clearly rubbish
<cjwatson> it's supposed to be something like 'syntax'
<lool> Hmm I had a spurious patch in my tree, I wonder whether I typoed when I generated the one calling libtoolize
<lool> Anyway, it works with libtoolize --force --copy --install
<cjwatson> so can we get gnome-autogen.sh fixed at least in our gnome-common package?
<cjwatson> to use --install
<lool> Keybuk, cjwatson: Sorry folks, it works with simply calling libtoolize --force --copy
<lool> I tried again and it works without --install
<lool> It produces exactly the same changes
<cjwatson> it'll work the *second* time if you've already run with --install ...
<lool> I just mistyped my patch update
<lool> cjwatson: I did not
<lool> seb128: You file FFEs for GNOME stuff?
<NCommander> ScottK, you available to chat?
<ScottK> Breifly
<ScottK> Urgh.  If spelled correctly, that's what I meant.
<seb128> lool: no, GNOME has a standing exception
<lool> seb128: I'll push what I did for pygobject; I pondered betweek a private lib in /usr/lib/pygobject/pythonX.Y and /usr/lib/libpyglib-pythonX.Y, did the former, and now upstream prefers the latter of course
<lool> seb128: I'll push what I did for pygobject; I pondered betweek a private lib in /usr/lib/pygobject/pythonX.Y and /usr/lib/libpyglib-pythonX.Y, did the former, and now upstream prefers the latter of course
<lool> seb128: So I'll push that now but it will likely change upstream to public libs, and we might have to add a new binary package or two
<seb128> lool: ok, thanks a lot for working on that!
<cjwatson> File: libtool.info,  Node: Top,  Next: Introduction,  Prev: (dir),  Up: (dir)
<cjwatson> much better
<lool> cjwatson, Keybuk: (sorry again for wasting your time on the non-issue)
<cjwatson> --install isn't documented in the info docs either :P
<lool> cjwatson: Ah thanks for fixing this
<lool> vi on the info file wasn't too confortable
<Keybuk> lool: errr
<Keybuk> you certainly need --install if you use --force
<lool> Keybuk: There's no difference between the two patches with --install and without
<cjwatson> lool: it is possible to get lucky
<lool> cjwatson: Sure, I understand that
<Keybuk> lool: depends on the order you run automake and libtoolize
<lool> I run libtoolize first
<Keybuk> if you run libtoolize after automake without --install, it will cheerfully *remove* config.sub, config.guess and install-sh
<lool> Now, I'm happy to learn what install does
<Keybuk> if you run it before, automake --install will put them back
<lool> And also to fix gnome-common upstream and in Debian/Ubuntu
<Keybuk> fix => just use autoreconf, really
<lool> I outlined briefly why I don't use autoreconf
<Keybuk> I missed that?
<lool> Goal being not to have megabytes of patches
<NCommander> cjwatson, thanks for processing part of the backports queue :-)
<lool> Well autoreconf will run the latest version of the tools, might not be the one upstream uses, and it might run tools which aren't really needed
<lool> For instance it might run automake even if I only touched configure.ac
<Keybuk> if you touched configure.ac, you might need to run automake ;)
<lool> Not sure my example is good enough
<lool> Right
<Keybuk> you certainly need to run autoheader
<Keybuk> bet you don't run that one <g>
<lool> You might
<lool> I run autoheader when I add defines
<lool> But I don't run it systematically
<Keybuk> it's worth pointing out that if you touch configure.ac, when you "make", automake will run itself anyway
<lool> If you don't use AM_MAINTAINER_MODE certainly?
<Keybuk> right
<Keybuk> if you're using AM_MAINTAINER_MODE, I'll just make funny faces and laugh at you whenever you have an autostuff question <g>
<lool> Keybuk: Consider cdbs' bug which removes patches before running distclean
<NCommander> Can someone please giveback kdeutils, and kdeedu?
<lool> This means that if you touch autofoo files, you get automake, autoconf etc. run when calling distclean
<Keybuk> yes...
<NCommander> Keybuk, recently autotools default MAINTAINER_MODE to on, with no way to disable
<lool> I don't want my build to trigger auto* because of timestamp things
<Keybuk> NCommander: you have misunderstood the meaning of the macro
<lool> The .diff.gz and the cdbs patch system issues make this possible though :-/
<Keybuk> lool: do you want your build to make .o files because of the timestamp of .c files? :)
<Keybuk> or, for example, if you have a .y file - do you want your build to run bison if you change that?
<lool> Keybuk: Yes; but the build-deps required to run auto* are not the same as those for building the package
<Keybuk> the usual preferred way I've seen cdbs handled is to make your patches
<Keybuk> and have a 99-autoreconf patch in which you run "autoreconf"
<Keybuk> therefore the last thing that cdbs does when applying patches is the effect of an autoreconf
<NCommander> Keybuk, the meaning of the macro is the cause autoconf rerun itself when one of its config files are touch. An annoying design when it comes to packaging
<Keybuk> and therefore the first thing that it does when unapplying is reverse that
<Keybuk> NCommander: false.
<lool> Keybuk: Read above: I only consider the *unpatch* case
<cjwatson> I think that's workable with cdbs, but not with .diff.gz, because the timestamp order may not be what you want
<lool> cjwatson: Actually .diff.gz isn't too much of a problem
<cjwatson> oh, actually, that dpkg-dev bug got fixed didn't it
<lool> Because timestamp is reset after applying
<Keybuk> NCommander: the meaning of the macro is, confusingly, the exact opposite of your statement
<cjwatson> nowadays I think it sets them all to the same timestamp
<lool> cjwatson: exactly
<cjwatson> right, I filed the bug suggesting it should do that :)
<Keybuk> adding AM_MAINTAINER_MODE will cause automake to *NOT* run autostuff when the source files are changed
<lool> cjwatson: Now we would need to do that after applying quilt patches or simple-patchsys patches
<lool> And after unapplying them
<Keybuk> or, more exactly
<lool> But it's not easy to know what to touch after un applying them
<NCommander> Keybuk, maintainer-mode is what triggers the autobuilding of files!
<Keybuk> NCommander: false.
<Keybuk> or, more exactly
<cjwatson> lool: right, the problem here is that multiple files in a cdbs patch (e.g.) might end up with different timestamps after application
<Keybuk> adding the macro causes an --enable-maintainer-mode and --disable-maintainer-mode options to be added to configure
<cjwatson> or at any rate that's one of the problems
<Keybuk> with the default as "disable"
<cjwatson> because patch might be unlucky and run across a second boundary
<lool> cjwatson: That, and unpatching will also touch the timestamps
<Keybuk> *without* the macro, there are no options, and the default is "enable"
<cjwatson> you need to have quilt etc. do it, really
<lool> cjwatson: Typically if you patch configure.in in patch 1 and configure in 99, unpatching will cause configure.in to have a newer timestamp
<lool> cjwatson: Problem is: which files do you reset the timestamp of when unpatching?
<lool> You would need to save all timestamps or a list of fiels to timestamp
<lool> And it becomes unworkable for dpatch and simple patchsys; probably even so for quilt
 * cjwatson <- glad he avoids patch systems, really :)
<lool> haha
<cjwatson> works fine if your whole tree's in bzr ;-)
<Keybuk> cjwatson: I got berated for failing to add a patch system when patching an Ubuntu package ;)
<lool> The most annoying bug is that cdbs bug which unpatches before distclean
<lool> Because even if I add MAINTAINER_MODE, it will have no effect
<lool> cjwatson: It also works fine if debian/patches is a quilt series and you use the format 3.0 (quilt) mode; we'll come to that I guess :)
<lool> I really sound stupid when I go ask upstream to please add am_maintainer_mode because our antique patch based build system breaks when it's not in the upstream tarball
<Keybuk> lool: why ask the upstream?
<lool> I inevitably get told (correctly) that am_maintainer_mode isn't good, isn't recommended upstream etc.
<lool> Keybuk: Because if it's not in the released tarball, I can't patch it in usefully
<cjwatson> Keybuk: I either ignore such complaints or point out why they're wrong, depending on my mood. I believe that current MOTU mood is that this is wrong
<cjwatson> (actually, though, I get hardly any such complaints)
<lool> seb128: GNOME #550235 for the 62_install-pyglib-in-libdir-with-python-version stuff
<ubottu> Error: Could not parse XML returned by Gnome: timed out (http://bugzilla.gnome.org/xml.cgi?id=550235)
<Keybuk> the irony is
<Keybuk> the way cdbs works gets this right
<Keybuk> if you patch the source files only
<Keybuk> you can entirely rely on automake to do the right thing
<Keybuk> you just need it in the build-deps
<Keybuk> yes, it'll run it on build and clean, but that's not a bad thing
<lool> Keybuk: It's fragile to run auto* without looking
<Keybuk> it isn't
<lool> How many times have I seen missing macros silently dropped from aclocal.m4
<Keybuk> if you read the automake run-things rules, you'll see they sanity check their own work
<lool> Many upstreams don't ship proper m4 files, or don't set aclocal flags correctly
<Chipzz> cjwatson: looking at debian-boot archives wrt wpa stuff; can't find anything. which thread?
<cjwatson> Chipzz: I googled for "wpa netcfg"
<cjwatson> first hit
<lool> Keybuk: It might be correct in the tools, but too many upstream and packagers get this wrong
<Chipzz> ah k, just not August :)
<mathiaz> james_w: FYI, I've been using bzr looms to handle the openldap package.
<mathiaz> james_w: https://code.launchpad.net/~mathiaz/openldap/pkg-ubuntu
<mathiaz> james_w: I'm using sftp:// rather than lp: to push the code as the lp bzr server doesn't support loom apparently
<tormod> slangasek: what happened with bug #192772, you promised to upload before FF?
<ubottu> Launchpad bug 192772 in linux-wlan-ng "please merge linux-wlan-ng 0.2.9+dfsg-1 from Debian main unstable" [Low,Fix committed] https://launchpad.net/bugs/192772
<saivann> I'd like to request developers to take a look at security bug 55159 . I spoke of this problem with siretart and I attached patches to revert the changes, but I believe that this would need discussion
<ubottu> Launchpad bug 55159 in usplash "usplash prevents passwords from being not echoed on the console" [High,Confirmed] https://launchpad.net/bugs/55159
<saivann> I'd like to request developers to take a look at security bug 55159 . I spoke of this problem with siretart and I attached patches to revert the changes, but I believe that this would need discussion
<ubottu> Launchpad bug 55159 in usplash "usplash prevents passwords from being not echoed on the console" [High,Confirmed] https://launchpad.net/bugs/55159
#ubuntu-devel 2008-09-02
<LaserJock> cjwatson: at some point I'd be interested in a blog post on how you use VCS (or would *like* to use VCS) for packaging
<cjwatson> LaserJock: I've been meaning to do a developer video at some point
<LaserJock> cjwatson: that would be good
<LaserJock> cjwatson: I just haven't found a good workflow for bzr-specifically that seemed worthwhile
<LaserJock> I'm maintaining packages with git in Debian and it seems to work ok
<cjwatson> I'm not doing anything particularly special with bzr for packaging
<cjwatson> I think maybe people are just looking too hard
<LaserJock> but I'm really kind of struggling to see a lot of improvements for Universe
<cjwatson> you don't have to
<dmoerner> LaserJock, have you seen this? http://www.eyrie.org/~eagle/notes/debian/git.html
<cjwatson> as I've said multiple times in that thread, if you don't like it, you can ignore it
<LaserJock> cjwatson: well, I don't think that's exactly accurate
<LaserJock> we don't want to have multiple methods around, it's very very confusing for new people
<cjwatson> it is necessary
<LaserJock> and I don't think we can just ignore it
<cjwatson> people will continue to send patches
<cjwatson> whatever you do
<cjwatson> and, frankly, I have a really hard time saying that our current processes are not horrifically confusing for new people
<LaserJock> yeah, but if some people don't take bzr branches
<LaserJock> then that's not a cool thing
<cjwatson> if you step back and look at them dispassionately, they're horribly complicated
<cjwatson> and much of that is directly due to things that revision control precisely fixes
<LaserJock> not participating in an archive-wide workflow is going to cause issues
<LaserJock> oh, I know they're complicated
<LaserJock> but they're largely documented
<LaserJock> and consistent
<cjwatson> they really aren't
<cjwatson> there are two or three different versions of everything spread around the place
<LaserJock> you mean like patch systems?
<cjwatson> even just things as simple as instructions for formatting and sending patches
<lifeless> wow, 38K on using git
<cjwatson> patch systems are a particular culprit, certainly, but an inherited one
<LaserJock> right
<LaserJock> yeah, it's not ideal, I'd agree
<LaserJock> but just adding complexity doesn't seem to help
<cjwatson> archive-wide workflow: I think that will sort itself out over time, and will certainly be no worse than current reality
<LaserJock> if we're gonna move it'd be nice to just move
<cjwatson> I ask people (who seem capable of producing them easily) for bzr branches for things, right now
<LaserJock> but trying to leave a lot of legacy seems like a mess to document and confusing for new people
<lifeless> LaserJock: running two VCS systems is itself complexity :- the source package archive acts as a VCS on its own
<LaserJock> lifeless: yeah
<cjwatson> LaserJock: IME, real systems that involve real people tend to involve real legacy handling
<LaserJock> so far from my experience it's much easier to drop the DVCS and just use the source package VCS
<LaserJock> but I'm hopeful there'll be a time when that's not the case
<wgrant> lifeless: The thing there is that at least the archive as a VCS has a format shared between us and Debian.
<wgrant> bzr is not.
<lifeless> LaserJock: nearly all of the complexity in this space is driven by retaining that VCS as primary; I'd like to see it become a read only mirror of a better, primary vcs [e.g. bzr] eventually
<cjwatson> wgrant: hence import work
<wgrant> cjwatson: As much as I love bzr, importing everything seems rather one-way.
<cjwatson> wgrant: but hence also retaining the archive-as-VCS
<cjwatson> wgrant: not in the slightest
<lifeless> LaserJock: the source package vcs has a number of serious scaling and participation problems. for instance, user assigned revision ids.
<wgrant> Say we maintain something in bzr that Debian maintains in git. This is not going to be uncommon. How does this work?
<lifeless> wgrant: its kindof-shared, but no deeper than two tailor imports of a CVS repo, when you look closely.
<LaserJock> lifeless: I'm not saying it doesn't have problems
<lifeless> wgrant: what do you think MoM is, if not a massively large scale tailor for debian source :)
<cjwatson> wgrant: regular incremental import from git to bzr. worst case, the other direction goes by patches; best case, you could probably use bzr fast-export | git fast-import to construct a matching git repository
<cjwatson> (if you wanted to put that effort in)
<cjwatson> note that the worst case is no worse than archive-as-VCS
 * lifeless stops his rant on the VCS-design-headaches of the archive
<lifeless> I'd just written about three lines of rant :P
<LaserJock> lifeless: the problem is, most people don't care :/
<LaserJock> people just want easy ways of uploading packages
<lifeless> LaserJock: we see prospective developers on  #ubuntu-motu DAILY that struggle with the archive-as-VCS problems
<cjwatson> I agree that there is likely to be some difficulty once people are sending bzr branches that some sponsors aren't interested in taking
<lifeless> I want those daily problems to stop happening
<wgrant> Archive-as-VCS does need to die. But moving to something incompatible with most of Debian seems odd.
<LaserJock> wgrant: +1
<cjwatson> my suggestion there is that we develop a very simple tool that people can use to turn that bzr branch into a debdiff
<LaserJock> cjwatson: sure, but it seems like just adding more "stuff" to the pot
<lifeless> wgrant: debian is Archive-as-VCS, those two goals are incompatible unless you get debian to standardise on something not Archive-as-VCS.
<cjwatson> wgrant: only for sponsors, who by definition are more capable; and only for those people who deliberately want to avoid easier tools
<cjwatson> err
<lifeless> wgrant: and that debate has been going on since, *at least* 2004.
<cjwatson> s/wgrant/LaserJock/ sorry
<wgrant> lifeless: Debian seems to largely be moving to git.
<cjwatson> wgrant: I dispute "most"
<LaserJock> cjwatson: what happens when somebody comes into #ubuntu-motu and asks how to contribute?
<lifeless> wgrant: as a toolchain for managing packages, not as authoritative content.
<cjwatson> a sizeable number of developers have moved to git, but very very many developers either use other systems (including bzr and svn) or have ignored version control altogether
<wgrant> cjwatson: It is a not insignificant fraction, and it is growin.
<wgrant> +g
<LaserJock> we say , well you can either use this method or the other method
<cjwatson> wgrant: I'm aware of that, but I completely dispute that that means we have to use git
<lifeless> wgrant: (and I would dispute 'debian' - some prominent develoeprs sure, but other ones are arguing against git continuously)
<lifeless> wgrant: also, svn was very popular at one point, and CVS
<cjwatson> LaserJock: we give them a single method on a wiki page, with footnotes in case they run into problems
<LaserJock> bzr is hardly used outside of Ubuntu, which means most people will have to learn a new VCS
<LaserJock> many people don't know VCSs at all even
<lifeless> wgrant: there is a huge difference between 'many packages are maintained in an external VCS' and 'Archive-as-VCS is going'
<wgrant> cjwatson: I'd like to see us use bzr everywhere. But I'd like to not diverge unnecessarily from Debian.
<cjwatson> "bzr is hardly used outside of Ubuntu" is a fallacy I'm getting tired of
<lifeless> I'll say, thats news to me
<LaserJock> that's just my experience
<lifeless> ubuntu is our smallest user, IME.
<LaserJock> I've seen a handful of repos from gnome
<LaserJock> but other than that ...
 * sistpoty pets good old cvs... stable as a rock, and as many features as a rock
<cjwatson> wgrant: I also don't think our directions to new contributors would be especially improved by moving to git
<cjwatson> it is by far the hardest of the current major contenders to learn
<LaserJock> cjwatson: no, but it'd help them elsewhere at least
<lifeless> the last presentation I saw by a git user, on using git, they had a WTF moment on their second command.
<lifeless> in front of a lecture theatre. And this isn't unusual.
<LaserJock> git's a lot easier for me to use than bzr, though I think bzr will be better in the end
<cjwatson> LaserJock: IME, there are as many ways of using git as there are git users
<cjwatson> so I don't think it would in fact help them
<cjwatson> bzr has been better for me since somewhere around 0.7
<LaserJock> I'm not particularly anti-bzr or anything
<LaserJock> but it's got some real issues when it comes to packaging, IMO
<cjwatson> namely?
<azeem> it's not svn
<LaserJock> speed and complexity
<LaserJock> it takes forever to do anything
<LaserJock> and it often require a lot of commands to do anything
<LaserJock> formats keep changing
<cjwatson> complexity: very similar to svn for regular packaging use
<LaserJock> every time I go to do anything I end up spending a couple hours in #bzr getting help
<cjwatson> formats: name when bzr last broke an old format
<lifeless> LaserJock: No VCS that I know of has finished its formats.
<wgrant> I have the opposite experience to LaserJock.
<lifeless> LaserJock: even git has been making changes.
<cjwatson> speed: have to say it just isn't an issue for me with packaging
<LaserJock> lifeless: it's never been a problem for me, that's all I can say
<wgrant> cjwatson: The problem with formats is that one needs to be run bzr 1.somethingverylarge or one cannot read most of the repositories.
<sistpoty> lifeless: I'd say that cvs has :P
<wgrant> But then again, svn broke compatibility with 1.5.
<LaserJock> bzr seems a bit more complex than any other VCS I've used
<LaserJock> but maybe that's just me :-)
<wgrant> git is as complex as you can get.
<LaserJock> I do better with git than bzr for sure
<LaserJock> though I don't like git
<cjwatson> how many git commands need options to do the right thing by default, and how many bzr commands need options to do the right thing by default?
<cjwatson> (the same goes for cvs actually; less so for svn)
<lifeless> sistpoty: actually, if you look - the atomic changeset UUID added is quite recent
<LaserJock> I don't know, I rarely get bzr to do what I want
<cjwatson> that truly amazes me
<lifeless> sistpoty: only a few years ago now, and I believe there was a locking improvement done too.
<LaserJock> and end up deleting my branches and tring something else
<cjwatson> the basic commands are trivial and almost identical to svn
<sistpoty> lifeless: yeah, it was a bad move in the first place... I'm quite sure the one bug in cvs I saw during the last five years is from the uuid thingy *g*
<lifeless> sistpoty: also, back in breezy I think it was, cvs added a race condition to commit, bug is still open.
<LaserJock> cjwatson: if the basic commands actually did what I wanted then yeah
<lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/cvs/+bug/12230
<ubottu> Launchpad bug 12230 in cvs "cvs checkout is racy, it wasn't in the past" [Medium,Confirmed]
<cjwatson> LaserJock: they do what I want, reliably and consistently
<LaserJock> cjwatson: I'm required to use a much larger "vocabulary" of command in bzr than any other VCS
<cjwatson> than git? you have to be kidding me
<sistpoty> but also, cvs is as user-friendly as a rock... a particular spikey one, to be precise
<LaserJock> git's rather easy
<cjwatson> git's vocabulary is outrageous
<LaserJock> git has a nasty vocabulary, but I only need a small part of it to do what I want
<LaserJock> bzr has a nice vocabulary, but I need to know a lot more of it than I'd like
<wgrant> Are you sure that you're not trying to do different things in bzr?
<LaserJock> who knows
<wgrant> I can't see how anybody could find git easier.
<lifeless> rather than going generic here
<LaserJock> well, every time I try things in bzr there's some problem, some bug, some great new feature I need
<lifeless> how about - LaserJock next time you are willing to give bzr a shot, grab myself, or james_w, and we'll give you a hand
<lifeless> with the version in intrepid :)
<LaserJock> lifeless: that's precisely the problem
<LaserJock> I do that all the time
<LaserJock> with git I don't need to
<_MMA_> LaserJock: +1
<LaserJock> I need hand-holding from bzr experts/devs to use bzr
<LaserJock> bzr makes me feel stupid
<cjwatson> I have to say, I think you are the exception
<LaserJock> git, for the most part, "Just Works"
<cjwatson> this is not my experience of other developers
<cjwatson> without wishing to denigrate your experiences
<LaserJock> hg works somewhat too, though I have some of the same issues with it
<lifeless> LaserJock: That offer wasn't for you, it was for me.
<wgrant> LaserJock: I've never seen anybody else say that.
<lifeless> LaserJock: I want to understand the way you approach your problems, so I can see if there is something I can improve in bzr to fit better.
<LaserJock> lifeless: well, I do appreciate that
<LaserJock> and I really do believe that bzr is gonna be awesome
<sistpoty> now I may be dumb, but I seem to have the same problems as LaserJock with bzr
<nxvl> cjwatson: isn't like 3 a.m. in your tz?
<_MMA_> lifeless: I have precisely that issue. Where I use Hardy for most of my development but Im told, "Its fixed in Hardy". I dont see this as acceptable. I thing the packages in the current release of Ubuntu should be bleeding-edge or backports keeps up. SOmething.
<cjwatson> nxvl: 1:30
<_MMA_> gah "ï»¿Its fixed in Intrepid"
<nxvl> cjwatson: oh! not that bad
<LaserJock> yeah, I don't to track the bleeding edge in my VCS
<sistpoty> and funnily enough, one thing which I first thought would be a problem from me using bzr wrongly, turned out to be a bzr bug... (though I guess that's really the exception *g*)
<LaserJock> I've never had to use anything but distro git/hg/svn
<lifeless> sistpoty: interesting; bzr is closer to rcs than cvs by default, have you used rcs extensively at any point?
<LaserJock> but I'm *constantly* having to get bzr stuff from source
<sistpoty> lifeless: nope
<cjwatson> I have not had to use non-distro bzr for about two years
<LaserJock> cjwatson: I was told by #bzr that I should just use bzr (and any plugins/tools) from bzr branch
<lifeless> sistpoty: that could be it; using a shared treeless repo w/switch might suite you better because that 'feels like cvs' pretty closely
<cjwatson> LaserJock: that's as may be, but nevertheless many people do not and it works just fine
<LaserJock> I find that the formats have changed and I need to upgrade branches to get bzr to work
<cjwatson> naturally, it depends what you're doing, but for simple use ...
<lifeless> LaserJock: well, its not bad advice, because things do keep improving, but its certainly not mandatory - the vast bulk of bzr users are using packaged versions from their distro.
<LaserJock> I'm the most basic of VCS users
<LaserJock> I first learned about VCSs in Ubuntu
<cjwatson> all current default formats work in bzr/hardy, don't they?
<lifeless> LaserJock: we haven't changed the default format since 1.0
<cjwatson> unless you're using experimental things
<LaserJock> I'm told I don't want to use the default format
<wgrant> 1.0 isn't even in gutsy...
<sistpoty> lifeless: actually I guess I (ab)used bzr to do this... :) (but then was tempted by the features, like merging, which is a very good thing imho, but just failed since I got it totally wrong)
<LaserJock> but some latest-and-greatest
<LaserJock> I have no idea what the default format is
<cjwatson> LaserJock: by whom, specifically? ("#bzr" is not what I'm looking for)
<LaserJock> this is my point
<lifeless> gutsy had 0.90, which can't read packs
<cjwatson> did you come to #bzr with some particular problem, or just ask for general advice?
<LaserJock> I'm just trying to use the thing, but I have to know things about formats and VCS guts to use bzr
<cjwatson> you really don't. friends of mine use bzr and have no idea about such things.
<LaserJock> git is nasty and has some of that problem too, but there's tons of Howtos around that help
<LaserJock> cjwatson: by #bzr I generally mean bzr developers
<LaserJock> and bzr-plugin developers
<cjwatson> how about we be quite clear: the simplest possible use of bzr involves your system only, with a local repository
<LaserJock> right
<LaserJock> I do like bzr for local code
<cjwatson> bzr init .; bzr add .; bzr commit
<wgrant> bzr init, bzr add, bzr commit. Can't get simpler than that.
<wgrant> Damn.
<cjwatson> there is no need to know anything about formats for that
<LaserJock> yep, that's all wonderful
<lifeless> cjwatson:  you don't need the '.'s
<LaserJock> well, except people tell me that I need repos
<cjwatson> then you can push to another system, and you don't need to know anything about formats either
<cjwatson> lifeless: distraction
<LaserJock> and that my repos need to be some specific format
<lifeless> cjwatson: :P
<cjwatson> bzr push sftp:///othersystem/...
<cjwatson> LaserJock: "people". you're being vague again
<cjwatson> you don't need repos
<cjwatson> unless you are doing something specific
<LaserJock> cjwatson: well, it's happened at least 5 times, I don't remember all who
<cjwatson> 01:36 <cjwatson> did you come to #bzr with some particular problem, or just ask for general advice?
<LaserJock> usually lifeless, jelmer, and a few others
<LaserJock> abently sometimes I talk with I think
<cjwatson> it sounds like you were given advice that was more complicated than your needs, and I'm trying to figure out why; for example you might have asked for advice on reducing disk space for very large branches, and been pointed to repositories
<LaserJock> mwhudson when it comes to LP related stuff
<cjwatson> but if you just say "people" and won't explain what was going on in context at the time, it's hard to say
<LaserJock> I usually come with "I can't branch something from LP, help?"
<cjwatson> I am amazed that anyone would have advised a repository in that context
<lifeless> there is one particular case that bzr gives people grief.
<LaserJock> well, it was helpful
<lifeless> the bzr-svn integration
<cjwatson> right
<LaserJock> hmm, maybe that's it
<LaserJock> I primarily use bzr through bzr-svn
<lifeless> that *does* require a non-default format, and tends to have *very big* branches because it has ancient projects
<cjwatson> that's a pain, I agree. that's why I was asking *what LaserJock was doing and he wouldn't tell me!*
<LaserJock> as I very very rarely work with code that's in bzr
<cjwatson> LaserJock: *now* you tell us, half an hour later
<LaserJock> bzr just isn't used that much
<LaserJock> lifeless: the other case was the ubuntu-doc repo, which had issues
<lifeless> and, to add to the confusion, bzr-svn support has been changing a lot over the last few releases :- and I do mean a _lot_. Fixing major memory leaks
<cjwatson> I don't think bzr-svn problems are remotely comparable to how most people would be using bzr for Ubuntu package development
<lifeless> ubuntu-doc is another bzr-svn converted repo
<LaserJock> ok, but how am I supposed to know?
<LaserJock> this is exactly the kinds of problems
<LaserJock> "oh, bzr is awesome except X, Y, Z"
<LaserJock> and I'm always doing X, Y, or Z
<cjwatson> well, is it not fairly obvious that using one revision control to work with another is likely to be a fairly difficult case?
<cjwatson> revision control -> revision control system
<cjwatson> and worth mentioning up-front in this kind of discussion
<LaserJock> cjwatson: difficult yes, common and critically important, yes
<cjwatson> sure, but worth mentioning up-front in this kind of discussion
<LaserJock> most packages in Debian that use a VCS use SVN
<LaserJock> bzr-svn working well will be very important
<cjwatson> I'm going to keep battering on about this because you just had us talking for half an hour without mentioning that fact
<LaserJock> cjwatson: I didn't know it was relevant?
<LaserJock> should I say every plugin I have installed?
<cjwatson> I asked several times for anything you could think of
<LaserJock> I was told working with bzr-svn ~= working with bzr
<cjwatson> you just said you were the most basic of users, which suggested to me that you weren't doing anything very complicated
<LaserJock> I didn't think it was
<LaserJock> sorry
<LaserJock> I just bzr branch, bzr pull, etc.
<cjwatson> FWIW, I work with many Debian projects that use svn by means of Launchpad's vcs-imports, which don't involve bzr-svn right now
<LaserJock> but my experience is certainly not exclusively bzr-svn
<LaserJock> I don't use vcs-imports anymore
<cjwatson> I understand there are some plans to move Launchpad to bzr-svn, but I hope that'll involve firming it up and getting the formats to be defaults
<lifeless> cjwatson: I've said that bzr-svn is a bad idea for LP until its 'finished' more, including default formats supporting it etc.
<lifeless> I hope I'm listened too :)
<cjwatson> in any case, as far as this phase of Ubuntu package development in Bazaar goes, interaction with other revision control systems is irrelevant
<cjwatson> it will hopefully become relevant later
<LaserJock> I had 4 projects that I contribute to imported into LP, and 3 of them died without saying anything
<cjwatson> but the first phase will only support it in the kind of way you're thinking of if separate imports have already been done
<LaserJock> so I've moved to just using bzr-svn,git-{svn,cvs}
<cjwatson> so Ubuntu developers will not encounter this to start with; they'll be using bzr to work with bzr branches, period
<LaserJock> cjwatson: why?
<LaserJock> I just don't see how that's possible
<cjwatson> because we aren't solving every problem simultaneously
<LaserJock> if I work on packages maintained by Debichem
<cjwatson> to start with, we're just importing package history, not a full fine-grained import from upstream with Debian branches and Ubuntu branches off those
<LaserJock> then I need to be able to work with SVN
<LaserJock> so it'd make sense to use bzr-svn on that
<cjwatson> we aren't solving every problem simultaneously
<cjwatson> the reason it has taken four years to get to this point is that we were trying to do it the perfect way
<LaserJock> doesn't seem to me that you're solving *any* significant problems
<cjwatson> now we are going to get it done, and fill in the perfection later
<cjwatson> as it happens, we will be solving many significant problems
<LaserJock> I know there are a lot of "down the road" things going on
<LaserJock> but it's not really selling well, IMO, for the "right now" case
<cjwatson> even just having a web-browsable archive of recent packaging history and current code for every single package in Ubuntu is a big deal
<LaserJock> "Launchpad sucks so we'll use a VCS" doesn't really appeal all that well to a lot of people
<LaserJock> many people don't care about history, they just want to work on stuff
<cjwatson> people will be able to experiment with merge workflows that don't involve tossing diffs around, and figure out something better; people will be able to use multiple branches to handle work-in-progress; etc.
<cjwatson> what on earth has this got to do with "Launchpad sucks so we'll use a VCS"?
<LaserJock> cjwatson: you said in your emails that LP doesn't give a good view of history so bzr would be better
<sistpoty> lifeless: btw, what does "N revisions where removed from the branch" tell me, which I get sometimes from RainCT's commits to revu-trunk as commit-mails?
<sistpoty> (where N is usually 1)
<pwnguin> launchpad sucking has nothing to do with using VCS
<cjwatson> LaserJock: please quote the exact text you're talking about so that I know what you mean, because that is not familiar to me
<LaserJock> cjwatson: I'll try. I could be wrong, but that's what I remember anyway
<cjwatson> the second phase of the Ubuntu/Bazaar plans involve a parallel import of Debian into bzr, which will mean that everyone can use 'bzr merge' in place of merge-o-matic if they so choose
<cjwatson> again, per-upload granularity only, but that's the only level that many people are operating on, certainly for the bulk merge
<LaserJock> sure
<LaserJock> I know there's a lot of stuff going on, and I like quite a bit of it
<cjwatson> while we may not get there for intrepid+1 unfortunately, that stuff is not far off
<cjwatson> so I really think it's offensive to say that we're not solving any significant problems
<lifeless> sistpoty: the rev number in bzr is done along the left-hand parents in the graph; RainCT is probably pushing to the common branch rather than using a checkout for edits on it.
<LaserJock> cjwatson: I don't see it "right now" though, was what I was trying to say
<lifeless> sistpoty: which means he may have a shorter path to his new tip, because he's done (say) 2 commits, then merged trunk, committed and pushed.
<LaserJock> cjwatson: long term I totally see it
<lifeless> sistpoty: but other people have done 5 or 6 commits.
<LaserJock> but *right now* I'm trying to figure out what the advantage is for me
<lifeless> sistpoty: for things where a strict 'what was in mainline' doesn't matter, its completely normal
<cjwatson> LaserJock: "right now" == before it's implemented?
<cjwatson> I mean, sure - but I think that's sort of the trivial case
<LaserJock> cjwatson: then why is it being talked about if it's not implemented?
 * LaserJock is confused
<cjwatson> LaserJock: is it not usually traditional to try to design things before finishing implementing them?
<LaserJock> cjwatson: hmm, except I've not seen a lot about desgin
<LaserJock> it's usually "trust us, we hired somebody to work on it"
<cjwatson> hmm, I think that's the sign I should go to bed and give up
<LaserJock> I've been talking some with james_w and it does seems exciting
<cjwatson> this type of conversation never seems to go well, I'm afraid
<lukehasnoname> May I say that I like Hardy's logout screen much more than Intrepid's?
<LaserJock> but I'm confused as to what I'm supposed to get out of your thread
<cjwatson> it's not my thread
<sistpoty> lifeless: I'm not 100% sure yet that I understand it correctly what it means... give me sec, and I'll pastebin you three consequent history events
<LaserJock> cjwatson: ok, granted you didn't start most of it, you just posted a lot
<cjwatson> it's a discussion about the possibilities for how sponsorship could work given various proposed changes to infrastructure
<LaserJock> cjwatson: I'm genuinely interested in how this stuff will work, how it can help me, etc.
<LaserJock> that's why I asked for a blog post
<cjwatson> which very shortly got derailed into people lobbing bricks about how bzr could never work for Ubuntu development
<LaserJock> well, *never* is a long time
<LaserJock> ;-)
<LaserJock> I'm hopeful for the future
<sistpoty> lifeless: http://paste.ubuntu.com/42575/ (in chronological order from top to bottom, separated by #####)
<LaserJock> bzr is just not very easy to me, so I'm a bit nervous about it happening soon
<lifeless> sistpoty: that looks like RainCT pushed something, realised a mistake, so uncommitted, then pushed a fixed version
<LaserJock> in any case, I need to go and I really wasn't looking for a fight
<LaserJock> I'm going to try to take lifeless up on his offer
<sistpoty> lifeless: ah, ok, thanks for the explanation :)
<lifeless> sistpoty: uncommit is different to 'commit the reverse' because we can't necessarily get a diff of what was uncommitted
<cjwatson> LaserJock: ok, sorry, maybe I shouldn't have engaged in one at getting on for 2am
<LaserJock> cjwatson: np, I learned some stuff
<lifeless> sistpoty: in CVS terms, its 'cvs admin -jdead 293 foo.c'
<cjwatson> LaserJock: I certainly will be posting something about packaging in bzr at some point, although exactly which areas I'm not quite sure
<lifeless> sistpoty: or something like that
<LaserJock> cjwatson: thanks
<sistpoty> lifeless: heh, thanks
<LaserJock> I'd like to hear from the experts :-)
<cjwatson> BTW, if distro git is always just fine and stable forever, what's bug 250526 for? :-)
<ubottu> Launchpad bug 250526 in hardy-backports "please backport git-* 1.5.6 to hardy" [Wishlist,Incomplete] https://launchpad.net/bugs/250526
<LaserJock> cjwatson: people gotta have crack? I have no idea
<sistpoty> well, while I was pretty much impressed by siretart merging with bzr, I doubt it's too practical for what we see in regards to universe sponsoring...
<sistpoty> because I saw a number of merges which pretty much just grabbed the MoM output, than thinking about the merge
<cjwatson> sistpoty: I honestly think a good deal of that is down to it being impossible to construct a unified process right now because we just don't have branches for everything
<LaserJock> sistpoty: yeah, I worry about that too
<sistpoty> but of course that's an educational problem, which is imo neither solved by any tool
<cjwatson> once we have Ubuntu and Debian branches for every package, 'bzr merge' will be a much more natural thing to do
<LaserJock> I heard a few "MoM is down, now I can't do merges"
<cjwatson> I can attest to it being *much* easier to merge packages that way
<LaserJock> anyway, gotta run
<LaserJock> thanks for the discussion, it was helpful to me
<sistpoty> cjwatson: that's not really the problem I was thinking of... it's rather the problem of "do the changes still apply" or "I have this tool, it works, though I don't know what I do, but I don't have any conflicts left"
<sistpoty> but that's inherant to the tool in question imho
<sistpoty> inherent? (it doesn't come from the tool used, but is educational *g
<sistpoty> +*)
<cjwatson> that's the opposite of inherent
<cjwatson> independent of, perhaps
<sistpoty> yes. that's it... /me will use only simply words from now on *g*
<sistpoty> simple
<sistpoty> argh
<cjwatson> I have never found merges straightforward to sponsor by any process
<sistpoty> *nod*
<cjwatson> being able to use 'bzr diff -rancestor:../debian' and such can be a timesaver, but no matter what you end up diffing all over the place to try to figure out whether the change is sane
<cjwatson> the cost-benefit ratio is significantly worse than when sponsoring ordinary patches; in terms of time, it's at least a factor of three worse
<ScottK> Wahoo.  Looks like I missed all the fun.
<StevenK> Hm? There was fun?
 * sistpoty heads off to bed, and then off to vacation... cya
<lukehasnoname> later.
<dholbach> gooooood morning
<pitti> Good morning
<dholbach> hi pitti
<lukehasnoname> good... yes, it is morning, isn't it?
<lukehasnoname> holy crap, check this out: http://googlesystem.blogspot.com/2006/03/google-browser.html
<lukehasnoname> damnit
<lukehasnoname> 5 secs after I post it I see it's fake.
<lukehasnoname> well not exactly, I just posted the wrong link
<lukehasnoname> http://googleblog.blogspot.com/
<StevenK> conftest.c:19: error: 'NULL' undeclared (first use in this function)
 * StevenK blinks
<StevenK> I could have sworn NULL is a built in ...
<jdong> no, it's a #define
<jdong> but it is funny to see it not defined
<jdong> should be unistd.h
<jdong> even stdio.h
<\sh> wth? bzr: ERROR: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed.
<\sh> what is that?
<lifeless> its a bug in bzr-dbus
<lifeless> regression actually I think ,cause by a dbus change.
<\sh> nice...I can't branch anything anymore ,)
<\sh> on intrepid that is
<lifeless> remove bzr-dbus from the machine you are branching from
<\sh> lifeless: bzr branch lp:~ubuntu-dev/quassel/ubuntu ,-)
<lifeless> \sh: oh!
<lifeless> \sh: uhm remove it locally ?
<\sh> will do
<pitti> lifeless: is there a particular reason why bzr doesn't record/log cherrypicks (bzr merge -c 1234) the same way it logs 'full' merges?
<lifeless> pitti: yes, a cherry pick requires a non-transitive reference into the graph
<lifeless> pitti: so we need a good,solid, compact, performs well, implementation of that
<pitti> lifeless: so in general it is desirable to do so, but is tricky to implement?
<lifeless> right
<pitti> ok, thanks
<pitti> I wondered whether there is a general conceptual reason not to do so
<pitti> tkamppeter: is there an STR for 90_include_krb5_h_in_job_h.patch.dpatch ? I didn't find one
<tkamppeter> pitti, what is 90_include_krb5_h_in_job_h.patch.dpatch about? The current CUPS does not contain this patch?
<pitti> tkamppeter: it does: debian/patches/include_krb5_h_in_job_h.dpatch
<pitti> tkamppeter: (the patch header said .patch.dpatch, I fixed this; the file name is fine)
<pitti> tkamppeter: look in svn trunk
<tkamppeter> pitti, I have found it now, too. You have removed the unneeded numbers one day.
<pitti> tkamppeter: please svn update first, btw, I just did some changes
<tkamppeter> pitti, I have loaded your last update now.
<StevenK> pitti: Can I bug you for source NEW stuff? :-)
<pitti> StevenK: if it's urgent, yes, otherwise it'll go with the normal archive days
<StevenK> pitti: "Not really"
<didrocks> BenC: around?
<tkamppeter> pitti, I do not remember whether I have STRed this patch upstream, I think I created it very long ago (to introduce CUPS 1.3 into Ubuntu or so).
<tkamppeter> pitti, can you STR it.
<pitti> tkamppeter: what was the bug? FTBFS? or it didn't work correctly?
<pitti> the changelog fails to document the rationale
<tkamppeter> The topic still says "archive: open". So we can still upload CUPS 1.4 (or should we better fix the topic?).
<persia> tkamppeter: The archive is open, but developers are expected to exercise caution about updates, and seek guidance from the relevant release teams about major updates.
<tkamppeter> pitti, AFAIR it did not build without the patch.
<pitti> tkamppeter: we are in feature freeze, so I'd say "no"
<pitti> tkamppeter: build> ok, that's easy to check; will have a go at it
<pitti> tkamppeter: archive freeze != feature freeze
<pitti> the former is whether uploads are allowed, the latter is which kind of uploads
<tkamppeter> persia, I am only asking, as for the last version FF was announced in the topic.
<persia> tkamppeter: Ah.  Good point.  I'll adjust that.
* pitti changed the topic of #ubuntu-devel to: archive: feature freeze | 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
<persia> pitti is faster :)  I was going to say "archive: open, feature freeze in place ..."
<pitti> persia: feel free to adjust the wording :)
<persia> pitti: All is good :)
* tkamppeter changed the topic of #ubuntu-devel to: archive: open, feature freeze in place | 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
<pitti> tkamppeter: oh, I just noticed that intrepid's cups is way apart from the svn trunk...
<tkamppeter> pitti, yes, I have made one upload during your vacation and was about to ask you for resyncing to Debian now.
<pitti> tkamppeter: well, as you saw on pkg-cups ML, I plan to move to bzr anyway, so that we can have proper ubuntu branches
<pitti> tkamppeter: I can probably merge kees' PIE hardening to trunk, but the ufw integration is ubuntu specific
<pitti> well, I can make that ubuntu specific in debian/ruels
<pitti> tkamppeter: I assume yuor changes in 1.3.8-5ubuntu1 are in trunk? do you know whether ion_'s changes in 1.3.8-5ubuntu2 are in trunk as well?
<tkamppeter> pitti, the Ubuntu package is the relevent one, with everything which ion_ and me wanted to have inside. I have committed it also into the Debian SVN. Can you check whether I did not forget anything in Debian, Merge everything missing into Debian and then sync Ubuntu and Debian again?
<pitti> tkamppeter: yes, will do
<didrocks> hum, good news, DD begin to accept the new Ubuntu management of deamon stop links (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495552). Just wait now this to be sponsored by u-m-s
<ubottu> Debian bug 495552 in nvidia-kernel-common "nvidia-kernel-common: Please remove stop links from rc0 and rc6" [Wishlist,Closed]
<pitti> tkamppeter: btw, the package builds fine without include_krb5_h_in_job_h.dpatch, so I'll kill the patch for now, if that's ok for you?
<tkamppeter> pitti, yes, seems to got fixed elsewhere (build system, .h file, ...)
<tkamppeter> pitti, I have sponsored the 1.3.8-5ubuntu2 upload, and AFAIR I have taken everything of ion_'s patch also into the Debian SVN.
<tkamppeter> But please check.
<pitti> tkamppeter: ok, I'll give it a check
<pitti> tkamppeter: yep, looks fine; so I'll just commit the rest
<seb128> hey pitti
<pitti> hey seb128
<seb128> pitti: do you have any idea on how we could debug the "the retracer clean some bugs but don't mark those duplicates"? ie, it removes everything as it was going to dup those but doesn't
<seb128> doesn't happen that often one every 30 bugs or something
<pitti> seb128: hm, I thought we added a workaround for that, for not trying to duplicate to itself?
<pitti> (which happened for retagging a bug)
<pitti> or does it happen to bugs which we didn't manually retag?
<seb128> that is a good question, and I think I forgot to apply the workaround
<seb128> you told me what to change but that was just before holidays and I had a busy day and didn't manage to do that
<famicom> lo
<seb128> bug #263795 is one example
<ubottu> Launchpad bug 263795 in rhythmbox "rhythmbox crashed with SIGSEGV in strcmp()" [Medium,Incomplete] https://launchpad.net/bugs/263795
<seb128> the first mail I got about this one was the retracer cleanup one
<seb128> dunno if somebody retagged it though
<pitti> anything in the logs for it? does it say it's a dup?
<seb128> the launchpad activity log is not powerful enough
<famicom> oh thats a fun one
<famicom> mount unmount bugs
<famicom> does anyone here know who is responsible for ubiqity
<seb128> pitti: Report is a duplicate of #261923 (not fixed yet)
<seb128> pitti: oh, it's trying to mark it duplicate from a bug which is already a duplicate and that's doesn't work on launchpad
<pitti> aah
<pitti> hm, I thought the code would already have a case for that
<seb128> that used to work I think
<pitti>         # check whether the master itself is a dup
<pitti>         m = Bug(master)
<pitti>         if m.duplicate_of:
<pitti>             master = m.duplicate_of
<pitti> maybe that stopped working in current p-lp-bugs?
<seb128> most likely
<famicom> ok, im going to get flamed for this one, but where in the hell can i get some decent low level info on the ubuntu install process. Everything i've found so far is completely useless
<seb128> famicom: try #ubuntu-installer?
<famicom> thank you ;)
<seb128> pitti: ok, so as always iz p-l-b bog
<pitti> bug 261923
<ubottu> Bug 261923 on http://launchpad.net/bugs/261923 is private
<pitti> seb128: testing...
<seb128> pitti: I can mark it public if you want
<pitti> seb128: should be ok
<pitti> I can read it
<seb128> ok
<pitti> I'll do that in some 15 minutes when I am done with wrestling cups
<tjaalton> ogra: you had some blank screen issues yesterday, see bug 262605
<ubottu> Launchpad bug 262605 in linux "[intrepid] X locks up or crashes when screensaver activates" [High,Confirmed] https://launchpad.net/bugs/262605
<famicom> ugh
<famicom> where exactly is the list of packages to install pulled from
<Hobbsee> famicom: http://people.ubuntu.com/~ubuntu-archive/seeds/ubuntu.intrepid/
<famicom> so it's pulled from debconf
<wgrant> Not as far as I'm aware.
<famicom> so where do you specify this?
<Hobbsee> in the seeds.  they're in bzr under ~ubuntu-dev
<famicom> then how do i tell the installer which seed to use?
<StevenK> Hobbsee: ~ubuntu-core-dev
<Hobbsee> oh, core dev, yes.
<famicom> anyway, i see things like "ubiqiquity --desktop %k gtk_ui" , /preseed/cli.seed
<famicom> and theyre' all not very helpfull
<wgrant> ubiquity doesn't know much about seeds, I don't believe.
<wgrant> It installs what's on the CD>
<famicom> so if i were to remove all unwanted cruft such as openoffice and the gimp
<famicom> they wouldnt be installed/
<famicom> I know this isn't directly related to development, but this information is so incredibly buried
<persia> famicom: Well, it also installs a set of tasks, so you'd have to be sure you weren't defining tasks for installation that included that which was removed.
<famicom> ok, so that's tasksel
<famicom> d-i	preseed/late_command	string chroot /target /usr/sbin/ltsp-update-sshkeys
<famicom> i meant tasksel	tasksel/first	multiselect ubuntu-desktop
<famicom> at the same time, i see  /usr/bin/perl -w /usr/bin/debconf-communicate -fnoninteractive ubiquity
<famicom> so something tells me that it's pulling info from debconf
<dholbach> cjwatson: are the seeds on bazaar.lp.net the ones we use right now? (platform.intrepid, etc)?
<dholbach> things might have changed since the last time I touched them (ages ago...) :-)
<StevenK> dholbach: Since like Hardy
<dholbach> hm hm ok
<dholbach> I was just looking into fixing bug 256626
<ubottu> Launchpad bug 256626 in ubuntu-meta "ubuntu-desktop recommends ttf-malayalam-fonts while ttf-indic-fonts-core already provide fonts for malayalam" [Undecided,Confirmed] https://launchpad.net/bugs/256626
<dholbach> does somebody want the honours saving some space on our CDs with that? :-)
<wolfe> hmmm
<cjwatson> dholbach: yes, they are
<dholbach> ok... I'll do it then
<cjwatson> persia: ubiquity doesn't really install tasks; that's done at live filesystem build time
<persia> cjwatson: Oh.  I thought it went through the whole d-i cycle based on the preseeds, and ubiquity only had a shortcut to the process which worked because of the way the live filesystem was built.
 * persia goes back to read more code.
<cjwatson> persia: package installation is one of the bits it skips, by just copying the live filesystem
<cjwatson> it uses selected bits of d-i
 * ogra arghs about us having taken over the sily buerocracy of debian that packages *need* a "needs packaging" bug now ... sigh
<Hobbsee> ogra: i highly doubt anyone is going to stomp on your fingers as you didn't write one before packaging it.
<ogra> well, i just did a REVU review where it was mentioned explicitly by the former reviewer ... probably https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages needs to be phrased differently then
<persia> Hobbsee: No, but lots of people stomp on fingers for not filing one before uploading.
<broonie> The Debian one has only been *enforced* relatively recently.
<pitti> seb128: confirmed, it's broken
<ogra> well, its still buerocracy overhead ... i thought we'd be better  :)
<Hobbsee> persia: oh, interesting.
<Hobbsee> ogra: when beaurocracy is the replacement for employing actual thought...what else do you expect?
<ogra> heh
<persia> Hobbsee: It's REVU + the lintian warning that comes from Debian enforcing it.  Patch it out of lintian, and all finger stomping stops.
<Hobbsee> persia: ahhh
<cjwatson> or teach people to apply human intelligence to lintian warnings, as was always the lintian authors' intention :-)
<Hobbsee> cjwatson: gasp.  what a concept!
<persia> cjwatson: That would be ideal, but it comes down the the education issue...
<pitti> seb128: filed as bug 263933, thanks for pointing out; I guess our grand master thekorn will fix it in no time
<ubottu> Launchpad bug 263933 in python-launchpad-bugs "duplicate_of has stopped working" [Undecided,New] https://launchpad.net/bugs/263933
 * pitti hugs theclaw
 * pitti hugs thekorn, too
<cjwatson> didrocks: reading that Debian bug you mentioned, note that runlevel 1 isn't equivalent to runlevel S in Debian; runlevel S is equivalent to runlevel S in Debian
<seb128> pitti: thank you
<didrocks> "runlevel S is equivalent to runlevel S in Debian
<didrocks> " ? :)
<didrocks> can you point me at any documentation,please? I have not found useful one...
<cjwatson> err, well, you can see that there's a runlevel S by looking in /etc/rcS.d
<cjwatson> also telinit(8)
<cjwatson> switching to runlevel 1 has the effect of stopping lots of processes, and then switching to runlevel S to actually bring up single-user mode
<didrocks> so, what runlevel 1 corresponds to in Debian/ubuntu if it is not single-user mode?
<didrocks> oh ok
<didrocks> I see that in the man now
<didrocks> ok, runlevel S doesn't stop the process before
<didrocks> cjwatson: thanks a lot to have clarified this :)
<ion_> pitti: Yeah, all my changes are in SVN.
<cjwatson> no problem
<pitti> ion_: thanks for re-confirming
<pitti> ion_, tkamppeter: FYI, all remaining ubuntu changes committed to trunk, uploaded to experimental, and (fake-)synced to intrepid
<ion_> pitti: 'stg clean' after 'stg rebasing' my patch stack against a branch 'git svn rebased' against SVN trunk deleted the entire patch stack, so everything should be there. :-)
<didrocks> cjwatson: so, now, I have just to wait for Ben to be there to see if we can upload all my waiting patches for removing the multiuser tags...
<pitti> ion_: heh, you import the svn to stacked git? I import it to bzr :)
<pitti> seems that noone is actually using svn...
<ion_> pitti: git-svn imports it to 'master', a plain git branch, and i have a stgit stack in 'ion' branch, which i 'stg rebase master' after changes to trunk.
<pitti> seb128: I fixed it myself, and committed/pushed
<seb128> pitti: you rock!
<ion_> stgit is like quilt but without the pain. :-) (That is, having to learn a patch doesn't apply anymore the hard way, without the patch system doing no automatic merging etc.)
 * seb128 hugs pitti
<pitti> seb128: can you please manually dup the bug above?
<pitti> seb128: I'll roll out the fix to the retracers
<seb128> pitti: I already did that ;-)
<seb128> and an another one which was in the same case since
<pitti> [done]
<pitti> so, it *shuold* work now
<seb128> excellent
<pitti> sebner: FYI, doing the eog new upstream version sponsoring now
<pitti> sebner: sorry, that should have gone to seb128
<tkamppeter> pitti, what means fake-synced? Is real syncing not allowed after FF, even if no new feature gets pulled into Ubuntu by that?
<pitti> tkamppeter: it is allowed, I just didn't want to wait until tomorrow
<tkamppeter> pitti thanks.
<ion_> Ooh, my puppet module that fixes ubuntu fonts has whopping two (2) users. :-)
<pitti> seb128: wb
<seb128> re pitti
<pitti> seb128: FYI, doing the eog sponsoring ATM
<seb128> pitti: thanks
<\sh> pitti: do you have any update on directfb and tslib?
<pitti> I didn't get to MIR processing yet
<lool> bryce: running Xvfb in a chroot gives me: (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory); adding libgl1-mesa-dri in the chroot fixes it; is this a dependency issue in xvfb?
<\sh> pitti: no worries :)
<jcristau> lool: not really, you can run it with '-extension GLX'. also, failing to load swrast_dri shouldn't be fatal, iirc that's fixed upstream
<lool> jcristau: Packages using xvfb-run to run X11 testsuites wont pull libgl1-mesa-dri; you're saying it's fixed in that if not available it moves to GLX?
<jcristau> lool: if that's not available, it disables glx instead of FatalError()ing
<lool> jcristau: That's fine then; I guess I should pull in the fix in our xvfb package
<tjaalton> lool: just give the commit-id and I'll add it
<tjaalton> lool: found it
<tjaalton> lool: do you need it for alpha5
<lool> tjaalton: I don't strictly need it; I've worked around in the bdeps
<lool> tjaalton: Thanks for adding it
<tjaalton> lool: it's included in 1.5-branch, so when it's released later this week we'll have it
<lool> tjaalton: Ok; thanks
<cjwatson> james_w: https://wiki.ubuntu.com/DistributedDevelopment/Specification moved from private wiki with mdz's OK
<Keybuk> pgraner: err, hi
<Keybuk> I CAN HAZ BOOTABLE KERNEL ON MAI LAPTOP?
<pgraner> Keybuk: sure... got a bug number?
<Keybuk> pgraner: no, I can't boot it
<pgraner> Keybuk: Need a bit more than that to work with
<Keybuk> err, no info
<Keybuk> boot kernel => nothing happens
<Keybuk> it locks up inside the kernel somewhere
<Hobbsee> oh, is this the boot hanging thing?
 * Hobbsee wondered what that was
 * ogra notices a certain creativity with pitti signing packages today :)
<pitti> ogra: WDYM?
<ogra> pitti, Changed-By: Martin Pitt <martin.pitt@ubuntu.com> vs Changed-By: Martin Pitt <mpitt@debian.org> :)
<pitti> oh, whoops
<pitti> I still have my debian DEBEMAIL in one terminal
<ogra> heh
<Keybuk> pgraner: fully off the phone now
<Keybuk> seriously, what debugging information can I provide?
<Keybuk> Dell Latitude D420, 2.6.27, if I pick it, nothing happens
<Keybuk> it doesn't even get to initramfs
<Keybuk> (-2-generic apparently)
<asac> ogra: warrens email? just warren@redhat.com?
<pgraner> Keybuk: https://wiki.ubuntu.com/KernelTeamBugPolicies
<pgraner> Keybuk: lots of techniques there to help you get started
<Keybuk> pgraner: all of these appear to rely on me being able to boot the thing ;)
<nxvl> good morning
<pgraner> Keybuk: https://wiki.ubuntu.com/DebuggingACPI look for the "Trouble Booting" section
<pgraner> asac: if you mean warren togmai at redhat then thats the correct address
<Keybuk> kk
<asac> pgraner: the warren from ltsp
<pgraner> asac: thats him
<asac> thanks
<pgraner> asac: np
<james_w> thanks cjwatson
<asac> pgraner: didnt work ;)
<asac> (the email address)
<hyperair> could someone look into bug #246053? it seems to be a packaging problem (wrong path for s2disk). debdiff included.
<ubottu> Launchpad bug 246053 in pm-utils "pm-utils doesn't detect uswsusp in hardy (with fix)" [Undecided,Confirmed] https://launchpad.net/bugs/246053
<pgraner> asac: shit sorry, is Fedora is warren Red hat is: wtogami@redhat.com
<asac> thanks ill try taht
<ogra> asac, 	Warren Togami <wtogami@redhat.com>
<asac> ogra: thanks. i think i got it right now ;)
<\sh> guys, anyone who has more clue about the buildd then I, please check this buildlog http://launchpadlibrarian.net/17228492/buildlog_ubuntu-intrepid-amd64.kdepimlibs_4%3A4.1.1-0ubuntu2_FAILEDTOBUILD.txt.gz and tell me what's wrong...local sbuild doesn't fail (amd64 only)
<ScottK> \sh: The log won't be there anymore because I retried the build.
<\sh> ScottK: oh yes
<cjwatson> Riddell: don't suppose you got anywhere with oem-config?
<didrocks> pitti: I will quote you a couple of time on wednesday's patching session. Don't be surprised of your are hilighted :)
<\sh> oh nice...who broke dbus?
<asac> amitk: nspluginwrapper 0ubuntu2 should fix the worst issues
<asac> (just uploaded)
<amitk> asac: nice. Thanks.
<skymuss> hi
<Riddell> cjwatson: not yet (I'm on holiday until thursday)
 * lamont wonders how to get firefox to not "randomly" steal focus
<lamont> as in when a page finishes updating, maybe?
<cjwatson> Riddell: oh ok, thanks
<wgrant> Speaking of Firefox focus stealing...
<wgrant> Who is to blame for the *default home page* doing that?
<asac> wgrant: a combination of the "online/offline" page feature and the fact that firefox likes to take focus to the website when loaded
<wgrant> asac: Wrong.
<wgrant> <body onload="focus_search()">
<wgrant> That is deliberate.
<wgrant> The page steals focus.
<asac> oh
<asac> well then ;)
<cjwatson> I think there ought to be a distinction between "adjust input focus location within firefox window" and "steal desktop input focus"
<cjwatson> the former seems quite reasonable
<asac> i am not really aware of the latter
<asac> unless you open a new browser (window) maybe
<wgrant> cjwatson: It's reasonable if you are behind a lightning-fast Internet connection and the focus is stolen immediately.
<wgrant> But as it is now, this search box steals focus from the real search box, leaving people with half a word in each.
<wgrant> Why there is search-box duplication I do not know.
<cjwatson> oh, so your complaint is actually about focus-stealing within firefox?
<wgrant> It is, sorry.
<cjwatson> again, I actually think it's perfectly reasonable to have a notion of focus within a page that's separate from where your focus in the browser chrome happens to be ...
<wgrant> It's not separate.
<wgrant> It steals focus from the chrome.
<asac> yeah. the focus maybe shouldnt move from chrome to website deliberately. not sure if that breaks usability for others though
<wgrant> The default home page shouldn't steal focus to its Google search box which duplicates the widget in the top-right of Firefox.
<cjwatson> wgrant: right, and I think that's a firefox bug not a page bug
<wgrant> Or the default home page should load in a more trivial amount of time.
<cjwatson> anyway, bugs.launchpad.net/ubuntu-website/+filebug would be the best place to object
<cjwatson> to something in the page
<tseliot> seb128: I have to add some error and information messages to show in dialogs in the gnome control center. How does localisation work for this package?
<wgrant> Bug #239831
<ubottu> Launchpad bug 239831 in ubuntu-website "FIREFOX START PAGE:  Focus pulled to start page Google box" [Low,Confirmed] https://launchpad.net/bugs/239831
<seb128> tseliot: standard gettext, and please use normal sponsorship for those updates
<tseliot> seb128: ok, thanks
<seb128> need to talk to kees and bryce about doing random uploads without pinging the desktop team before ;-)
<asac> wgrant: i added firefox-3.0 with a soft-milestone to that bug
<pitti> didrocks: no problem at all :)
<asac> jdong: there?
<cjwatson> doko: have you had a chance to reassess bug 261847 in light of the new information? I'm assuming that the bug I referred to (and some other similar ones) were the reason for the recommendation
<ubottu> Launchpad bug 261847 in openjdk-6 "Installing openjdk-6-jre-headless pulls in dbus/avahi" [Critical,Confirmed] https://launchpad.net/bugs/261847
<doko> cjwatson: on my list (remembering an email from lool); can't read my email yet. my luggage including the power adaptor didn't make it until Berlin. they'll deliver it tonight.
<didrocks> pitti: thanks a lot :)
<saivann> I'd like to request developers to take a look at security bug 55159 . I spoke of this problem with siretart and I attached patches to revert the changes, but I believe that this would need discussion
<ubottu> Launchpad bug 55159 in usplash "usplash prevents passwords from being not echoed on the console" [High,Confirmed] https://launchpad.net/bugs/55159
<didrocks> doko: around?
<doko> didrocks: just ask
<ogra> he's not that round anymore either :)
<didrocks> doko: sorry, did you have the time to look at my email (something like 3-4 days before) on java2-runtime-headless which is not present in intrepid archives?)
<doko> didrocks: no, not yet, back from vacation today
<didrocks> doko: sorry for hearing that :) take your time, there is no rush.
<mdz> asac: have you had a chance to look at bug 258552? it might help with NM bugs
<ubottu> Launchpad bug 258552 in network-manager "apport package hook for network-manager" [Undecided,New] https://launchpad.net/bugs/258552
 * asac looking
<fbond> Hi, I read https://wiki.ubuntu.com/OneTruePath.  I'm not sure this is documented anywhere obvious?  That page is also somewhat ambiguous as to whether we should be using /etc/profile or /etc/environment.
<cjwatson> the intent is /etc/environment
<ogra> hmm, it was never parked as implemented actually
<ogra> *marked
<Mithrandir> /etc/profile is a shell script, so /etc/environment is the one, yes.
<cjwatson> I think "change pam to add default PATH to /etc/profile" was a typo for /etc/environment
<cjwatson> Mithrandir: could you confirm that?
<cjwatson> since that's what's actually done
<Mithrandir> yes, that would be a typo.
<cjwatson> I've fixed it
<Mithrandir> cheers
<ara> hello, does anyone know if it is difficult (in terms of policy) to change the name of a pkg in main
<cjwatson> it's not hard in terms of policy, but can be a hassle both for developers and users
<ara> the hw certification team have a tool hwtest, and the upstream project changed the name to checkbox
<cjwatson> it is usually unwise to change it in Ubuntu if it also exists with the other name in Debian
<ara> the ubuntu pkg (only in ubuntu, not in debian)
<ara> should be renamed also to checkbox
<lamont> cjwatson: you for got to capitalize "UNWISE" ...
<cjwatson> ara: you normally just need to upload a new package by the new name that includes Conflicts, Replaces, and Provides fields for the old package name, and once that's in the archive file a removal request for the old package
<cjwatson> (subscribing the ubuntu-archive team)
<ara> cjwatson: thanks!
<cjwatson> 'checkbox' is an exceedingly generic term and does not strike me as a better name, though
<ara> cjwatson: i guess it is too late for intrepid, isn't it?
<cjwatson> not necessarily, no
<asac> mdz: thanks ... i added a comment
<ara> cjwatson: the reason is that it is no longer a hw certification only tool, but a generic test framework
<cjwatson> I'm not formally objecting to it or anything, it just seems asking for trouble in terms of future name clashes, that's all
<cjwatson> but there's nothing by that name in the archive right now
<asac> ara: just curious, is there a spec or summary of what the testing framework does?
<fbond> cjwatson: Should the preference for /etc/environment be documented anywhere else (i.e. on the system itself)?  ~/.pam_environment is not very obvious, at all, of course.
<ara> asac: well, more than a test framework, it is a test runner
<cjwatson> fbond: probably, but I'm not sure where would be appropriate
<cjwatson> perhaps ask the doc team
<fbond> cjwatson: #ubuntu-doc?
<cjwatson> I think so
<mdz> asac: can you confirm that the gconf command I suggested works?  I don't have any static config on this box
<fbond> cjwatson: Thanks.
<cjwatson> kirkland: I notice that bug 33649 got reopened with very little new information. Do you know what's going on there?
<mdz> asac: then I'll submit it via bzr
<ubottu> Launchpad bug 33649 in debian-installer "root raid installs have bad grub config" [High,Confirmed] https://launchpad.net/bugs/33649
<ara> asac: https://launchpad.net/checkbox is the upstream project. I am afraid that there isn't many documentation yet
<asac> mdz: gconftool-2 -R /system/networking prints out reasonable things for me
<mdz> asac: thanks
<mdz> pitti: btw, it would be nice to be able to have some non-textual separator in apport report keys
<mdz> pitti: I tried NetDevice-wlan0 and it simply vanishes from the report, similar for '_' IIRC
<kirkland> cjwatson: i will ask for more information, but tricky1 has been a bit of a pain on this issue
<pitti> mdz: that's not a problem with the separator, the ProblemReport class' __setitem__() just checks that key.alnum() is true (dots are allowed, too)
<pitti> mdz: that's a pretty arbitrary convention, I can easily allow characters like - and _; I just wanted to avoid potential problems with client-side parsers which might expect identifiers
<pitti> (as in programming languages)
<mdz> pitti: I can use '.'
<mdz> pitti: the parser will be OK with it I assume?
<mdz> pitti: it would be nice if __setitem__ threw an exception or something; it was very confusing that it disappeared silently
<pitti> mdz: yes, the parser splits on ':', so that should be ok
<mdz> asac: I have a bzr branch with the changes; what would you like for me to do with it?
<pitti> mdz: it actually should, it uses assert
<pitti>     def __setitem__(self, k, v):
<pitti>         assert hasattr(k, 'isalnum')
<pitti>         assert k.replace('.', '').isalnum()
<pitti> mdz: I even have a test suite check for that
<pitti>         self.assertRaises(AssertionError, pr.__setitem__, 'a b', '1')
<mdz> pitti: weird
<pitti> mdz: where exactly did it disappear?
<mdz> pitti: that did not trigger for me, or else it did so in a place where I did not see it
<cjwatson> kirkland: yeah, I know
<cjwatson> kirkland: it was just on my sponsoring list so I noticed it
<pitti> mdz: you added something in a hook, and it didn't appear in the .crash file? or when you piped it to/from LP?
<mdz> pitti: correct
<mdz> pitti: the latter
<kirkland> cjwatson: i'll respond, asking for more info, and mark it incomplete?
<mdz> after apport had processed the crash file and added the other keys, I noticed that one was missing
<cjwatson> kirkland: sure. Have you done an end-to-end test yourself to confirm that it is in fact working?
<kirkland> cjwatson: good question; i have not from the latest install media;  i'm downloading the current ubuntu server right now, with the intention of performing that test
<pitti> mdz: actually the entire hook should crash on that (which doesn't cause the apport GUI to crash, though, just the hook to be ignored)
<pitti> mdz: so maybe it was the last field which was written?
<pitti> mdz: to be precise, the hook isn't ignored, but if it throws an exception, that is ignoored, and the hook is terminated
<mdz> pitti: it would have been the last in my test, yes
<mdz> pitti: would that have shown up in /var/log/apport.log?
<pitti> mdz: unfortunately not, since that is only writable by root
<cjwatson> kirkland: it's easy enough for something completely distinct to break stuff (e.g. I tried to test an LVM problem yesterday and discovered that lvm2-udeb's dependencies were broken, so had to fix that first)
<pitti> mdz: it's just a simple try: execfile(); add_info() except: pass construct right now
<asac> mdz: request a merge using the launchpad "merge" feature
<pitti> a better error logging would certainly be good here indeed
<asac> mdz: or give me the url to fast-track ;)
<pitti> mdz: for a start, the UI could just print the exception to stderr, so that calling apport-gtk in a shell will reveal it
<mdz> asac: done, https://code.edge.launchpad.net/~mdz/network-manager/ubuntu.0.7/+merge/906
<asac> cool lets see
<mdz> asac: I forgot to link to the bug when creating the branch; is there a way to add that?
<mdz> pitti: that would be helpful when developing hooks
<asac> mdz: yes you can add the branch to the bug ... there is a link below description "link to a branch"
<mdz> asac: ah, I see it
<asac> err "link a related branch"
<asac> the launchpad diff view could be improved for the sake of reviewing
<mdz> oh, someone already did it
<asac> NEW files are not included in the diff
<asac> mdz: maybe launchpad can now parse changelog? :)
<mdz> asac: that seems worth a bug report on LP
<mdz> asac: or maybe mentioning it in the bug comment triggered it?  some magic happened
<mdz> there's nothing in the activity log
<asac> anyway, whatever that is, it is quite good - though the lack of activity log scares me a bit
<mdz> I bet I get a lot of karma for this, it's a new LP feature ;-)
<ogra> really ?
<asac> any idea what launchpad product the code browser is maintained in?
 * ogra uses it in his cmpc product since quite a while
<mdz> asac: you can just file on launchpad.net/launchpad
<mdz> kiko tells me they triage all the bugs from there and move them to the right place
<mdz> asac: but it's launchpad-bazaar for reference
<asac> ok ... i'll try ;)
<cjwatson> mdz: debcommit
<cjwatson> mdz: if you used debcommit for the change, and put an LP: tag in the changelog, debcommit now parses out those LP: tags and uses bzr --fixes lp:bugnum which turns into a related-branch object when the branch is pushed
<mdz> cjwatson: *hug* debcommit
<cjwatson> it's all really quite nicely joined up now
<asac> awesome ;)
<cjwatson> thank james_w for that change
<asac> cjwatson: is that implemented in bzr itself or in a plugin?
<asac> (i mean the --fixes op)
<pitti> I recently noticed it as well, thanks to whoever did it
<pitti> asac: it's in debcommit, I suppose
<cjwatson> asac: bzr commit --fixes is in bzr itself, though the lp: bit may be in the launchpad plugin
<pitti> mdz: traceback printing from hooks committed
<StevenK> pitti: james_w, with a little of my Python help, if I can borrow some credit.
 * pitti hugs james_w and StevenK
<cjwatson> StevenK: ah, sorry, didn't realise you'd helped
<cjwatson> DYM perl help
<cjwatson> ?
<StevenK> Hm. Perhaps I'm thinking of something else that also implemented bzr --fixes
<StevenK> Ah, yes, I do mean Perl help.
<StevenK> Reading the code brings the memories of suggesting it
<StevenK> map {} FTW
<saivann> tkamppeter : Did you have time to review my patches in bug 251972 ?
<ubottu> Launchpad bug 251972 in brother-cups-wrapper-mfc9420cn "Unnecessary dependency on csh" [Low,In progress] https://launchpad.net/bugs/251972
<saivann> and bug
<saivann> 256873
<ion_> Have you (people in charge of the DistributedDevelopment spec) considered using pristine-tar? E.g. git-import-dsc imports the extracted tarball to âmasterâ branch, uses pristine-tar to store a binary diff between a tarball exported from the given commit to the master branch and the original tarball to âpristine-tarâ branch and branches âdebianâ branch from the âmasterâ branch and applies the diff.gz to it. cjwatson?
<cjwatson> ion_: I believe that pristine-tar is in fact mentioned in there; if not, yes, it's been discussed and I think it's mostly a technical matter of where to store the delta
<cjwatson> at least for branches corresponding to .orig.tar.gz
<ion_> Oh, i only grepped https://wiki.ubuntu.com/DistributedDevelopment/Specification for pristine-tar and didnât notice it there.
<cjwatson> yeah, it appears not to be there
<cjwatson> james_w: ^-
<james_w> cjwatson: it was discussed at the last sprint, I haven't written up the proposal yet
<cody-somerville> slangasek, Why is Xubuntu failing to build? (Hash Sum mismatch)
<kees> seb128: I touched vte and gnome-control-center (both went into bzr).  did I break something?
<seb128> kees: hey
<seb128> kees: not, just suprised to get a random UI change in gnome-control-center without any discussion on the ubuntu-desktop mailing list or in launchpad first
<seb128> kees: usually people don't do random changes without discussing those first or that would be somewhat cahotic ;-)
<kees> seb128: ah, heh.  upstream seemed supportive, and I chatted with bryce about it (since he'd done work on that widget)
<kees> seb128: I didn't think it was a huge change, but I will try to be more vocal next time.  is the addition of aspect a problem?
<seb128> kees: right, I don't say the change is wrong, I'm just not used to have people who don't work on a package usually uploading changes without discussing those with the team which does maintain the package, ie I would not do an xorg change now without asking #ubuntu-x or bryce before
<seb128> kees: otherwise the change looks good, I'm just not sure about the alignments
<seb128> the combo looks weird, I would probably try to align the ratios in a column or something
<kees> seb128: hrm, yeah, I wasn't sure how to do that and still have it be a combo
<pwnguin> sounds like a job for a certain usability expert ;)
<bigon> could someone have a look at https://bugs.edge.launchpad.net/ubuntu/+source/enchant/+bug/261075 ?
<ubottu> Launchpad bug 261075 in enchant ".pc files indirectly adds --export-dynamic to the linker flags" [Unknown,Fix released]
<jameswf-home> Anyone know why a seed file takes if placed in initrd but not if refered to externaly + why d-i seems to ignore some debian syntax
<jameswf-home> example of ignored line d-i passwd/make-user boolean false
<torkel> I'm not sure if using apport-gtk for creating a bug report that apport-gtk has crashed is always a good idea :-)
<cjwatson> DktrKranz: bug 71341; please don't recommend a patch system when people are changing files in debian/
<ubottu> Launchpad bug 71341 in cobex "cobex_get manpage is low quality" [Low,Confirmed] https://launchpad.net/bugs/71341
<cjwatson> jameswf-home: that's only valid if you've also preseeded passwd/root-login to true, otherwise you end up with a system with no users
<cjwatson> jameswf-home: certain items can only be preseeded from the initrd or from the kernel command line, as the installation guide notes. This is because the early steps of the installer happen before the installer knows how to fetch files from the CD or the network. passwd/make-user is not one of those items, though.
<ogra> cjwatson, oh, wow, you uploaded (and edited) the lsusb thingie
<jameswf-home> cjwatson: I understand that but nothing from the seed file takes hold outside but everything (except the user thing) worked inside initrd
<cjwatson> ogra: yeah, took a little while
<cjwatson> jameswf-home: it does work in general (we rely on loading a preseed file from the CD for Ubuntu installations), so I need to know more details about what you're doing.
<ogra> yeah, the patch was hairy i glaced over it shortly but didnt have time for more about two weeks ago
<cjwatson> jameswf-home: what you're saying is that it doesn't work *for you*, so I need to understand what's different between what you're doing and the correct approach
<cjwatson> ogra: it was on dholbach's list of stuff I was supposed to do. :)
<ogra> the sheer size scared me away a bit
<ogra> right, but i said i'd review if someone did a patch
<jameswf-home> cjwatson: I am doing it "the debian way" which is likely the root issue
 * ogra thinks sometimes we should rename bugs.launchpad.net to "sore conscience" ... it so often feels like that
<cjwatson> jameswf-home: I don't see why that would be the case
<cjwatson> jameswf-home: I'm a Debian d-i developer as well
<cjwatson> jameswf-home: first things first: which Ubuntu CD are you using?
<jameswf-home> cjwatson: ubuntu-server 8.04
<jameswf-home> cjwatson: I tacked on to the default ubuntu-server.seed
<cjwatson> jameswf-home: what is your interpretation of "the Debian way"?
<cjwatson> and can I see your preseed file?
<jameswf-home> cjwatson: all the changes I have made are per the debian docs :: http://pastebin.com/m6a36d263 :: no commenting and I am by no means an expert (obviously)
<cjwatson> jameswf-home: could you also post the syslog from the installer? if you've completed an installation, it will be in /var/log/installer/syslog
<cjwatson> jameswf-home: you should remove debian-installer/language, console-display/kbd, and console-keymaps-at/keymap; your syntax for console-setup/modelcode is wrong (missing "string", should be all-caps "SKIP", and why are you preseeding that anyway when you're also preseeding a keyboard configuration?)
<cjwatson> jameswf-home: the locale and keyboard stuff must be done on the kernel command line or by initrd preseeding, not in a preseed file
<jameswf-home> because had no luck with the other so tacked on
<cjwatson> jameswf-home: netcfg/get_hostname and netcfg/get_domain preseeding is unfortunately known-broken (bug 218965)
<ubottu> Launchpad bug 218965 in netcfg "preseeding hostname doesn't work in a network install" [High,Triaged] https://launchpad.net/bugs/218965
<cjwatson> jameswf-home: the rest of it ought to be fine, so if I see the syslog I may be able to figure out why it isn't working for you
<jameswf-home> I applied your suggestions I am going to roll an ISO real quick to test I will let it complete
<cjwatson> jameswf-home: thanks. I'm afraid I have to step away from the computer for a few hours, but stick around and I'll look at what you've got when I get back
<alex-weej> hello
<alex-weej> RGBA anti-aliasing seems to have regressed lately
<alex-weej> are we still carrying the (legally questionable) freetype/cairo patches?
<ion_> alex: My fonts look perfect with the correct settings.
<slangasek> cody-somerville: mirror out of date for some reason
<LaserJock> is https://code.edge.launchpad.net/~ubuntu-core-dev the best place to see if a package is maintained in bzr?
<cody-somerville> no
<LaserJock> cody-somerville: ok, what is a better place?
<cody-somerville> apt-cache showsrc <pkgname> probably is
<LaserJock> doesn't that presuppose that X-VCS headers have been set?
<cody-somerville> slangasek, can you sync it and kick it off again?
<cody-somerville> LaserJock, Indeed.
<LaserJock> s/headers/fields/
<cody-somerville> LaserJock, However, looking at ~ubuntu-core-dev is probably less likely of an indicator. Especially for special interest packages such as xfce4
<LaserJock> between ~ubuntu-core-dev and ~ubuntu-dev should it cover mostly everything?
<LaserJock> or do individual people and teams maintain package branches?
<LaserJock> Riddell: is KDEEdu maintained in bzr somewhere? apt-get source says that it's maintained in Debian SVN
<jpds> LaserJock: It's under ~kubuntu-members I think.
<jpds> ...and I don't think most people use the Bazaar branches there.
<Riddell> LaserJock: it's not in bzr
<LaserJock> Riddell: ok, thanks
<NCommander> persia, you floating around?
<RainCT> Is mvo on holiday or something? (because I can't find him on IRC)
<Riddell> RainCT: yes
<RainCT> Riddell: Ah. Do you know when he will be back, or if I can poke someone else for apturl changes?
<DktrKranz> cjwatson, indeed! I misread it, sorry.
<Riddell> RainCT: thursday
<jameswf-home> anyone have any thoughts? debconf: Obsolete command TITLE
<calc> my son turned 1 on sunday :-)
<_MMA_> ï»¿calc: Congrats! Mine turns 4 this coming Sun. :)
<calc> http://www.new.facebook.com/photo.php?pid=30090053&l=f3c21&id=1376832583
<calc> _MMA_: wow almost ready for school :)
<_MMA_> Yep. Daughter is almost 7. Makes me feel old. :)
 * jameswf-home has 7 soon to be 8 and 10 soon to be 11 
 * LaserJock has a cat
<_MMA_> hehe
 * jameswf-home has 2.5 dogs and a cat...
<RainCT> Riddell: Ah, I'll wait for him to come back then. Thanks :)
<mathiaz> slangasek: is https://wiki.ubuntu.com/PAMConfigFrameworkSpec implemented ?
<slangasek> mathiaz: yes
<slangasek> cody-somerville: apparently not, I evidently don't know what's causing the mirror sync failure
<cody-somerville> : O
<slangasek> cody-somerville: and I don't have time to look at it at the moment, I'm afraid; I'll try again late this evening
<mathiaz> slangasek: http://paste.ubuntu.com/42831/ <- is this a rather accurate short description of the new pam config framework ?
<mathiaz> slangasek: I'm writing up a blog post to recap what happened in the archive for ubuntu-server related packages (which include libpam-ldap and libpam-smbpass)
<slangasek> mathiaz: pam_cracklib, pam_ecryptfs, and pam_ck_connector are also included in the list of modules that support it now
<slangasek> looks accurate though, yes
<emgent`nl> hello
<lukehasnoname> hello
<Drust> hi
<NCommander> cjwatson, hola
<jameswf-home> cjwatson: BTW your suggestions and in reading other suggestions by you in google found irc logs have resolved most of my issues...
<cjwatson> jameswf-home: obsolete command TITLE> completely unimportant; ignore it
<cjwatson> NCommander: hello
<cjwatson> jameswf-home: ok, though since you seem to have the syslog I'd be interested in a quick look
<cjwatson> jameswf-home: I'm curious what your problem actually was
<NCommander> cjwatson, Is it possible we can get a change made to xubuntu hardy seed (or have it moved to our group; we need to make a seed change to resolve a bug)
<NCommander> I can cook up the branch to merge in a moment
<cjwatson> NCommander: it's late for me now, but please push the branch you want to ~xubuntu-dev and send me a reminder mail, and I'll move it across in the morning
<jameswf-home> cjwatson: probably personal stupidity
<NCommander> sweet, thanks cjwatson
<mathiaz> slangasek: there are two bugs in openldap related to the fact that the openldap user is not part of certain groups (ssl-cert and sasl) and thus upgrades stop working.
<mathiaz> slangasek: moreover if slapd is configured to use sasl or TLS the openldap user has to be added to the relevant group
<mathiaz> slangasek: what do you think about adding the openldap user to ssl-cert and sasl group automatically at install time ?
<jameswf-home> cjwatson: I am doing some more tweaking this is the syslog from the lst iso roll http://pastebin.com/m2f1bfcb3
#ubuntu-devel 2008-09-03
<cjwatson> jameswf-home: oh, I forgot to ask for DEBCONF_DEBUG=developer on the kernel command line, which is usually needed for detailed work here. Still, if it's working fine for you now, no need; I don't see anything obviously wrong in that log now
<jameswf-home> cjwatson: The asterisk workd is ownde by RHEL my goal it to chip away from that so hopefully i will get it going good enough to give a base for folks...
<RAOF> My laptop's
<RAOF> ACPI is awesome.  During hardy development there was a time when it wouldn't boot while plugged in.  Now it doesn't boot when it isn't plugged in :)
<cjwatson> jameswf-home: good luck :)
<kirkland> cjwatson: slangasek: either of you around?
<kirkland> cjwatson: slangasek: if so, i opened a new grub bug, with bzr branch/patch that fixes it, https://bugs.launchpad.net/ubuntu/+source/grub/+bug/264160
<ubottu> Launchpad bug 264160 in grub "grub-install onto raid device" [Undecided,New]
<kirkland> cjwatson: slangasek: based on my testing of the latest iso's
<pwnguin> man, google chrome's checkout is like 600 megs
<superm1> pwnguin, how far back does the history go on it?
<pwnguin> good question
<pwnguin> they have this crazy multi tiered checkout tool
<pwnguin> i have version 1663
<wgrant> Does it include a whole lot of modified standard libraries?
<wgrant> If not, it's no fun.
<wgrant> Everybody has to include their own modified libs.
<pwnguin> im not sure if they're modified
<superm1> i'm mostly curious when they "claim" to have started development with it
<pwnguin> but they also use sqllite
<pwnguin> superm1: its svn; i dont know offhand how to query for the oldest revision
<jcastro> it's importing into launchpad right now.
<pwnguin> heh
<wgrant> Could take a while.
<jcastro> yeah
<jcastro> it failed the first few times
<pwnguin> i think like half of it is test and data files
<pwnguin> dictionaries for the world
<wgrant> Hm.
<wgrant> Why is it owned by the mozillateam?
<wgrant> Isn't it WebKit?
<pwnguin> it is
<pwnguin> and a crazy 32bit only javascript VM
<jcastro> mozillateam is really "browser team" these days
<pwnguin> yea. 200 megs of tests
<pwnguin> there apperas to be a reference build in revision control
<wgrant> Ew.
<RAOF> Heh.  The google data .NET library svn contains not one, but 4 different builds in svn.  And a couple of zlib binaires, too.
<pwnguin> im trying to follow their build directions, but it won't take
<pwnguin> i have no src dir
<ajmitch> ah, everyone else is checking out & trying to build chrome too? excellent
<superm1> is anyone sure it will even build at this point?  I would have assumed if it did they just would have released some binaries for linux too
<ajmitch> 'Although many Chromium submodules build under Linux and a few unit tests pass, all that runs is a command-line "all tests pass" executable.'
<jcastro> it's not ported yet
<jcastro> the gui, etc. is all windows only afaict
<ajmitch> they've been using hardy as a development platform for the port though
<ajmitch> which makes getting the right bits in place slightly easier
<ion_> Hopefully theyâll use native Gtk.
<pitti> Good morning
<pitti> kees: still awake by any chance?
<pitti> doko: any idea about the weird libffi4 uninstallability? (it depends on gcc-4.2-base (= 4.2.3-2ubuntu7) )
<pitti> doko: is this a hardcoded binary package version in the gcc-4.2 source package?
<pitti> cjwatson: what's necessary to re-include mobile into http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt ? ATM processing the source/binary demotions list is dangerous due to that
<pitti> Riddell: desktop-effects-kde wants to go to universe, is that deliberate?
<pitti> Riddell: kdebluetooth as well
<StevenK> pitti: Since ubuntu-{mobile,mid} are in universe, most of the stuff in component-mismatches.txt shouldn't be related to it.
<pitti> StevenK: hm, but there's a lot of stuff we moved into main in hardy, which didn't appear in c-m earlier
<StevenK> pitti: I think we should crowbar them back together, and then I'll be happy to dig out the -m{id,obile} stuff out of it.
<pitti> lool: the pygtk FTBFS on amd64 (and others) causes some uninstallability; the error looks weird (segfault during make), I try a giveback
<laughtear> hello everyone, good morning from istanbul
<Hobbsee> annoying intrepid hang, now.
<pitti> ogra: ltsp-client now depends on sshfs, but that is in universe; thus ltsp-client is currently uninstallable
<laughtear> i have intrepid ibex on my computer, i'm an ubuntu for some time. i have a problem in ibex about graphic drivers
<laughtear> anybody could give me a hand?
<RAOF> laughtear: Probably, but not in here; Intrepid support lives in #ubuntu+1
<laughtear> (i am an ubuntu user, i mean..:))
<pitti> Riddell: once you have a moment, can you please have a look at the kdesdk uninstallability? needs some MIRs or changed dependencies
<laughtear> all rite, thank you RAOF
<kees> pitti: actually, I am awake -- just got back from a movie.  what's up?
<pitti> kees: after my holidays I noticed bug 255563
<ubottu> Launchpad bug 255563 in sysvinit "Parallel fsck breaks boot when / is being fsck'd" [High,Confirmed] https://launchpad.net/bugs/255563
<kees> aah, yeah.
<pitti> kees: I haven't done any investigation about it yet, and wondered if you could give me some details what happens here? anything that could help me with a head-start?
<kees> pitti: sure -- I apologize for not digging in but it always happens when I'm in a rush to get back up and booted.  :P
<pitti> the usplash/fsck scripts didn't change since hardy, so either something else in intrepid changed, or we have that grave problem in hardy too
<kees> pitti: I suspect fsck has changed
<pitti> kees: don't worry, I'm not trying to shove it off to you
<kees> pitti: I have about 6 ext3 partitions
<pitti> kees: I just wondered whether you know anything about the problem, i. e. how to reproduce it
<pitti> just having e. g. /var and /usr on a separate partition and having them all fsck'ed will do?
<pitti> that'd be easy enough to do in a vm
<kees> pitti: they're all mounted at boot-time, and when one of the later ones (not root) needs fscking, the fsck init line goes by very quickly (showing "fail", I think, though it might be the mountall).
<pitti> ogra: ah, nevermind, there's an approved MIR for it
<kees> when I come up, a fsck is still running, and I'm missing one of my partitions (since it's being fscked)
<pitti> kees: eww, *all* mounted?
<kees> pitti: all but the fsck'd one mounted, yeah
<pitti> AFAIR it should be checkroot - mountroot - checkfs - mountother
<pitti> kees: so the problem is that the usplash scripts don't wait for the fsck to finish, because it forks off some to the background?
<kees> right, so checkfs happens quickly and exits, and then mountother runs, but one of the partitions isn't available since fsck is still running on it.
<kees> pitti: right, something along those lines
<kees> though I have to say, it's been kind of nice to only fsck one partition per boot.  ;)
 * StevenK glares at pygtk
<pitti> kees: ok, then the right solution is to properly wait
<kees> pitti: right, I assume that's what's going on.
<pitti> kees: do you happen to know, does that only affect the usplash part, or the text-only mode as well?
<dholbach> good morning
<kees> pitti: I didn't try booting without usplash.
<pitti> kees: ok, thanks a lot for the heads-up; I'll try it in a VM then, but this gives me something to work on
 * pitti hugs dholbach, morning
<dholbach> hi pitti :)
 * dholbach hugs pitti back
<kees> pitti: cool, thanks.
<kees> dholbach: thanks for another great mix.  I was enjoying it earlier today.  :)
<dholbach> thanks a lot for the flowers, kees :-)
<dholbach> kees: it's been a while since the last one and it was a good opportunity to plug one of the pictures from India ;-)
<kees> hehe, I never know what that means.  :)
<dholbach> kees: what what means?
<kees> dholbach: "thanks for the flowers"
<dholbach> oh... you don't say that in English?
<dholbach> it's just thanking for a compliment :)
<kees> dholbach: well, it's not a phrase I've heard before, but intent is clear.  I'm always just momentarily confused.  :)
<dholbach> well ... thanks :-)
<kees> regardless, I need to start saying that to people.  :)
<dholbach> hehe
<StevenK> So you can share your confusion?
<kees> say, anyone else on 64bit with sane flash in firefox?
<dholbach> and I need to write that blog post I about India I promised
<kees> StevenK: 'zactly
<StevenK> kees: I'm on 64bit with sane flash. Read as, no flash.
<RAOF> kees: Does the definition of "sane" exclude "opens one decorated window per embedded flash object per page transition"?
<kees> StevenK: heh.  I guess I should clarify.  :)
<kees> RAOF: oh god, yes, I hope so.
<kees> RAOF: but yeah, that's what I'm seeing.
<RAOF> That excludes my flash experience, then :)
<kees> RAOF: I've done exactly 0 bug hunting, but figured I'd just ask since I was just now staring at a mess of them on my task bar.
 * RAOF doesn't actually use a task bar.
<RAOF> They're a nspluginwrapper bug, IIRC.
<StevenK> kees: Thinking, "Oh damn it, they're breeding" ?
<kees> RAOF: yeah, that'd make sense.  I'll go dig
<kees> StevenK: yeah, or "I couldn't possibly be the only person annoyed by this"
<RAOF> It's not _substantially_ more annoying than the standard flash behaviour ;)
<kees> at least swfdec doesn't auto-start them.  :P
<kees> waaait... it couldn't be nspluginwrapper
<kees> that doesn't apply for swfdec
<RAOF> Yeah!  That's right.  I noticed that.  I blame 6am.
<RAOF> I forget if gnash does it, too.
 * kees eyeballs firefox
<RAOF> For what it's worth, banshee(trunk) seems to be having problems embedding its NowPlaying window, too.
<RAOF> That's not unlikely to be unrelated, though.
<kees> is the publisher stuck?
<pitti> lool: nope, failed again
<kees> ff3 built 17 hours ago, but is not in the archive.  https://edge.launchpad.net/ubuntu/+source/firefox-3.0/3.0.2+build3+nobinonly-0ubuntu1/+build/706678 http://archive.ubuntu.com/ubuntu/pool/main/f/firefox-3.0/
<pitti> kees: looks fine here
<pitti> kees: ffox is in binary NEW
<kees> pitti: Aaaaah
<laughtear> RAOF: which channel we were?
<laughtear> RAOF: for intrepid help?
<kees> pitti: what caused that?  the translations?
<pitti> kees: there are some split-out -branding packages
<RAOF> laughtear: #ubuntu+1
<kees> pitti: ah! I didn't open the arrow.  I see it now.  nm.
<pitti> asac: I find the {firefox,webbrowser}-branding packages very confusing TBH; what's the idea of this?
<pitti> asac: also, the package descriptions make it worse; webbrowser-3.0-branding is not a metapackage, talks about "The Awesome Browser", is called "-branding", and describes itself as "unbranded firefox"
 * kees -> really to bed
* slangasek changed the topic of #ubuntu-devel to: archive: main frozen for alpha 5, feature freeze in place | 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
<tkamppeter> pitti, hi
<StevenK> Hm. For want of a depgraph tool
<Mithrandir> StevenK: apt-cache dotty ?
<lool> pitti: Could you make sure it's building against -0ubuntu3?
<lool> Yeah, /me wrote a build-deps dotty generator and later discovered apt-cache dotty :)
 * StevenK fights his machine for some CPU time
<StevenK> lool: Hah. Now fix pygtk!
 * StevenK cracks a whip
<lool> lpia: Successfully built.
<StevenK> What makes you think I was talking about lpia? :-)
<lool> I was thinking you could only be using lpia binaries!
<lool> pitti: (I built it on amd64 on my host before uploading yesterday)
<slangasek> ogra: did you ever submit an MIR for libaubio-dev? (denemo 0.7.7-3.1ubuntu1 changelog, from May)
<StevenK> lool: I have a soft spot for amd64
<lool> Weird, it's -0ubuntu3 in the buildd's log as well
<StevenK> So I care about i386, amd64 and lpia
<lool> pitti: Looks like a xvfb issue
<lool> Xlib:  extension "RANDR" missing on display ":99.0".
<lool> Gtk-WARNING **: Could not find the icon 'drive-optical'. The 'hicolor' theme
<lool> It's not clear to me whether these are fatal
<lool> I get the Xlib ones
<pitti> hi tkamppeter
<lool> I don't get the icon wqrning
<seb128> what is broken?
<lool> seb128: The testsuite failed; I'm trying to understand what bdep to add if any, otherwise I'll ignore its results
<seb128> it built on i386
<lool> Indeed
<seb128> maybe just give it a build retry?
<seb128> but that's weird
<StevenK> seb128: pitti did
<pitti> yep, didn't work
<slangasek> it also failed on sparc and ia64 with the same error
<pitti> slangasek: for the record, I cleaned up some uninstallabilities and component mismatches, going through the MIR queue now
<pitti> slangasek: dailies should be there by now, I'll give them a smoke test
<pitti> slangasek: time to disable the cd cron jobs then?
<slangasek> pitti: great, thanks
<seb128> slangasek: btw thanks for not moving the GNOME sru I asked about before going in holidays :-p
<lool> Oh I wonder whether it's trying to display some filechooser object which needs the drive-optical command to work
<lool> Because these buildds have an optical drive
<tkamppeter> pitti, I have seen another small problem of our PDF-printing-enabled CUPS package: The CUPS test page (not the Ubuntu test pages, the original CUPS test pages) got incompatible. See bug 263049
<ubottu> Launchpad bug 263049 in system-config-printer "CUPS test page not suitable for PDF printing workflow, needs to be replaced" [Medium,Invalid] https://launchpad.net/bugs/263049
<pitti> tkamppeter: ah, needs to become a PDF now?
<slangasek> pitti: well, we probably want to get a full set of images for today; whether cronned or by hand makes no difference to me
<slangasek> seb128: mm, sorry, just keeping up with intrepid took up my time and I never got a chance to push SRUs out to -updates :/
<pitti> slangasek: I'll leave that to you, just asking how you generally handle that
<ogra> slangasek, no, i didnt file a request for aubio since persia and LaserJock cornered me to decide about the other missing deps ...
<slangasek> ogra: sorry, what are the other missing deps?
<seb128> slangasek: alright, no problem ;-)
<tkamppeter> pitti, yes, and as PDF is no programming language, it cannot contain margins and resolution info any more.
<ogra> slangasek, there are more changes in the recent debian version
<slangasek> ogra: but that doesn't seem to be relevant for intrepid?
<ogra> hmm
<ogra> i didnt think abut it that way
<pitti> tkamppeter: can we convert it to PDF on build time, so that we don't need to change upstream?
<lool> seb128: I wonder whether we should recommend gnome-icon-theme in libgtk or pygtk in this light
<lool> I'll push a package adding it only as a bdep for now
<slangasek> ogra: well, we're past FF and well past DIF, so right now I only care about MIRs for the /current/ build-deps ;)
<seb128> lool: I was just going to suggest that
<ogra> slangasek, true but there is still a newer package in debian and for universe i could rather easily get a FF exception .... so i still need to decide if we stick with something old in main to have a scoreeditor in edubuntu or not
<tkamppeter> pitti, but then the data on the test page would be completely wrong.
<seb128> lool: btw you didn't push glib 2.18 to debian?
<slangasek> ogra: oh, well if you're considering demoting it to universe that's fine with me (--> not my problem anymore ;)
<pitti> tkamppeter: alternatively, can we make it use the ubuntu test page everywhere?
<ogra> slangasek, i'll have that decided (and potential MIRs written) by the end of my workday, does that suffice ?
<tkamppeter> pitti, I think this would be the better approach. For Debian one could perhaps also use the Ubuntu page but with a Debian logo inserted into it.
<ogra> (i'm a bi under load with some private errands this morning)
<ogra> *bit
<pitti> tkamppeter: oh, hang on, right, the ubuntu test page is in s-c-p, not cups, right?
<tkamppeter> pitti, yes, I think so.
<lool> seb128: No I wanted to run it first; I ran it overnight and my system is still up so I'll upload it now
<seb128> lool: ok thanks, did you try on debian or intrepid?
<pitti> tkamppeter: nevertheless, I don't think the page would be completely wrong, it's just saying "postscript" which is not really true any more
<lool> On intrepid
<seb128> alright, so I can sync it directly ;-)
<seb128> I would have built and tested it there otherwise
<seb128> hanks
<seb128> thanks
<seb128> brb
<pitti> tkamppeter: also, why doesn't it work? cups must still be able to print a postscript document and convert it to pdf on the fly?
<slangasek> ogra: that's plenty fast, sure; I'm just going through the out-of-date list for main, I don't expect to get these all done in time for alpha-5
<tkamppeter> pitti, the CUPS test page contains paper size, margins, resolution, interpreter name, and serial number. This shows all completely wrong if we statically convert it to PDF.
<pitti> right, that's dynamically created, just saw it
<pitti> tkamppeter: so, why not just keep the .ps for now?
<tkamppeter> pitti, CUPS is capable of converting normal PS files to PDF, but the dynamically created data in the CUPS test page is only created correctly if the interpreter directly rasterizes to the printer.
<pitti> tkamppeter: which parts are wrong?
<tkamppeter> pitti, display the CUPS test page, /usr/share/cups/data/testprint.ps on the screen. It gives you some default page size and a resolution of between 72 and 100 dpi and GPL GS as the interpreter (see the two boxes in the middle).
<pitti> tkamppeter: I did that, yes
<pitti> tkamppeter: but if yuo print to a printer through the filter chain, it should still get the correct target dpi, and all that, no?
<seb128> lool: pygobject 2.15.4 available with your fix btw (and an another change too)
<tkamppeter> pitti, convert the test page to PDF with the ps2pdf command. Display this on the screen. You get for sure a much higher value shown as resolution, between 600 and 720 dpi.
<pitti> tkamppeter: I get 720, yes
<tkamppeter> pitti, the printer prints it always in the user-requested (or ptinter-native) resolution, as the PDF file is vector graphics. What is wrong is the resolution value in the info box and this iritates users.
<pitti> tkamppeter: that still sounds weird to me; shouldn't resolution be propagated through the cups filter chain?
<pitti> at some point the last filter needs to know it at least
<tkamppeter> pitti, one can fake in at least the right resolution (which one can get from the PPD and/or command line): ps2pdf -r600 /usr/share/cups/data/testprint.ps
<pitti> tkamppeter: exactly
<tkamppeter> pitti, any idea how to fake in the margins?
<pitti> tkamppeter: same Q as for resolution -- the papersize needs to be propagated through the filters, isn't that done?
<pitti> if I just run ps2pdf I get letter
<pitti> I shuold get A4 at least when I actually print something
<pitti> but since cups has a wrapper around ps2pdf, I guess that will/should take care of paper size as well?
<tkamppeter> pitti, the biggest problem are the interpreter name and printer serial number. You cannot make the pstopdf filter read this out of a PostScript printer. Perhaps we need to patch these fields out of the test page.
<pitti> tkamppeter: right, that should be fine (patching out of the ps)
<pitti> they are largely uninteresting for the purposes of a test page; the paper size and margins matter most, IMHO
<tkamppeter> pitti, paper size is no problem, run ps2pdf with -sPAPERSIZE=a4 or better with -dDEVICEWIDTHPOINTS=XXX -dDEVICEHEIGHTPOINTS=YYY
<tkamppeter> ion_, are you here?
<tkamppeter> pitti, ion_, we can also make the conversion cleaner if the pstopdf filter propagates page size, margins, and resolution to the conversion process. Imaging a PS file without well-defined page size or wrong page size is sent. The conversion process could correct the situation.
<lool> pitti: pygtk amd64: Successfully built.
<pitti> lool: hm, I wonder what's different on your system
<lool> pitti: I don't have an optical drive
<pitti> lool: and the buildd has one?
<lool> It seems so :)
<pitti> and that breaks pygtk build? WTH?
<lool> That icon name I mentionned earlier is probably needed to display a filechooser during the tests
<lool> It's certainly a bug in pygtk or gtk for having a dependency on this and the package not having a corresponding dep, or for the testsuite to fail on warnings if it's only a warning
<pitti> hm, that does sound kind of relevant for pygtk, thuogh
<pitti> lool: fail on warnings? I saw a segfault there, which seems more serious?
<lool> pitti: Not sure when you saw a segfault
<lool> pitti: Perhaps a build against pygobject -0ubuntu2?
<pitti> lool: the previous amd64 build log had one, hang on, I'm checking the current one
<pitti> oh, hang on, it built now?
<lool> Yes
<pitti> didn't I just see it FTBFS? maybe someone gave it back again
<lool> I uploaded it with a gnome-icon-theme bdep
<lool> (for the optical drive)
<seb128> pitti: http://launchpadlibrarian.net/17256244/buildlog_ubuntu-intrepid-amd64.pygtk_2.13.0-0ubuntu1_FAILEDTOBUILD.txt.gz
<seb128> pitti: that was the build error
<lool> seb128: I think pitti also saw a segfault in the previous log
<lool> Quite probably because pygtk built against pygobject << -0ubuntu3
<seb128> lool: let's pretend that one was a transitionnal issue ;-)
<lool> seb128: I'll leave the new pygobject upstream to you if you like; I don't think it adds anything for us
<pitti> right
<seb128> lool: right we can skip this update
<seb128> lool: did you upload glib2.0?
<lool> seb128: Yes, you can sync it from incoming in a couple of minutes
<seb128> lool: I'm wondering if you had a perfect timing and uploaded just before the dinstall run or if it's just not listed in incoming yet
<seb128> lool: ok good
<lool> I uploaded 3 minutes ago, it will show up soon
<seb128> excellent, thanks
<seb128> brb
<slangasek> pitti: how's the smoke testing?
<pitti> slangasek: just finished rsyncing, alternate and desktop just booting
<slangasek> ok
<tkamppeter> pitti, ion_, bug 263049 is now updated.
<ubottu> Launchpad bug 263049 in system-config-printer "CUPS test page does not display correct print job data. pstopdf filter needs improvements, test page needs some changes" [Medium,Invalid] https://launchpad.net/bugs/263049
<asac> pitti: did you look at the ffox NEW packages yet?
<pitti> asac: yes, see my questions above
<asac> pitti: those are bugs ... no need to keep this out tbh
<asac> pitti: i am bad at writing descriptions
<pitti> asac: right, the bad package descriptions are bugs, but I'd still like to understand the purpose, and why the webbrowser deb has "awesome-browser-*' files
<pitti> and IMHO the names of the packages are highly confusing; we should make them more clear, which is why I didn't accept them yet
<asac> pitti: what is confusing about the packages
<asac> ?
<asac> pitti: the packagename is a generic name, because we want to provide a free branding without any trademarks
<asac> pitti: the "awesome" branding is just a code name for the branding directory i used during development
<asac> pitti: it will disappear from the description
<pitti> asac: still, why should a package named -branding give you an unbranded firefox?
<pitti> asac: as I said, I have *no* idea how the structure *shuold* be, maybe you can tell me?
<asac> pitti: you cannot have an unbranded browser
<asac> pitti: just a browser with a "generic" branding
<pitti> also, I refuse to accept a package which is called "webbrowser"
<pitti> that's namespace pollution
<pitti> if the idea is to take out the ubuntu branding from firefox, then there should be an unbranded firefox-3.0 (representing upstream) and a firefox-3.0-ubuntu-branding which has our changes
<pitti> just calling it -branding doesn't help, since it doesn't tell you *what* branding, so derivatives cannot use the same schema
<asac> pitti: derivitaves can just remove the firefox-3.0-branding packages.
<asac> or dont sync them
<asac> firefox-3.0-branding == firefox branding
<pitti> doesn't work, since they are built from teh same source
<asac> pitti: dont understand. there are 2 things here: 1st. people can just sync the binary bits they want
<pitti> asac: ah, so firefox-3.0-branding is the upstream original, while webbrowser-3.0-branding should really be firefox-3.0-ubuntu-branding ?
<lool> seb128: glib is in incoming
<seb128> lool: it's in intrepid too ;-)
<asac> pitti: no ... firefox-3.0-ubuntu-branding isnt nice
<asac> it suggests that its ubuntu
<seb128> lool: just synced like 15 seconds ago, but thanks for the notice ;-)
<pitti> well, what is it then?
<asac> we dont want that word to reside there
<lool> Ok, didn't show up in rmadison yet
<pitti> lool: rmadison has a ~ 6 hour lag
<asac> pitti: its a webbrowser branding which is completely generic and not trademark encumbered
<pitti> asac: it's not a webbrowser branding, it's at most a mozilla or firefox branding
<pitti> (firefox, according to the .deb contents)
<lool> asac: firefox-3.0-generic-branding?
<pitti> ./usr/lib/firefox-3.0.2/chrome/awesome-branding-en-US.jar
<pitti> and that's not really helpful to either users, developers, or derivatives
<slangasek> pitti: I'm turning in for a few hours of sleep before the foundations meeting; if those images pass the smoke test, can you post the candidates to the tracker?
<pitti> slangasek: yes, I will
<cjwatson> lool: the generic branding specifically isn't called "firefox"
<asac> pitti: filenames / directories and such are not covered by trademarks as far as we understand
<wgrant> Is it really as generic as webbrowser?
<pitti> wgrant: no
<asac> pitti: so its helpful if derivatives want to sync from us, they can just leave the firefox-3.0-branding aside
<cjwatson> wgrant: in the user interface, it winds up just being called "Web Browser"
<pitti> asac: right, but then the package name should explain what it is and avoid confusing/buzz names like "awesome" and "webbrowser"
<asac> pitti: package name and filenames that might be confusing can be (and will be) fixed.
<cjwatson> pitti: can you suggest one that doesn't include "firefox"? We discussed this for quite a while and this was the best we could come up with
<asac> pitti: err package description
<pitti> asac: fixing file names is fine, fixing package names is harder
<pitti> since it requires transitional packages, conflicts, etc.
<asac> pitti: i misread (description)
<cjwatson> pitti: mobile> you mean consolidating component-mismatches and component-mismatches-mobile?
<pitti> cjwatson: if I would know the purpose of this package, then yes; AFAICS, it contains a neutral branding theme for firefox
<pitti> cjwatson: c-m> I faintly remembered that you said you temporarily removed the mobile seeds from c-m
<asac> pitti: the idea is that we get to the point where any distribution can just drop firefox and firefox-3.0-branding package
<asac> and then dont have any trademark issues anymore
<cjwatson> pitti: the full list is in c-m-mobile
<pitti> cjwatson: if the current lists are in the intended state, I'll consult c-m-mobile for demotions
<cjwatson> (sorry, bad naming)
<wgrant> Can the Firefox branding then be appropriately moved to restricted?
<pitti> cjwatson: ok, thanks
<cjwatson> wgrant: please see the Ubuntu licensing policy. non-code is handled case-by-case so the Firefox branding doesn't necessarily have to be in restricted.
<wgrant> cjwatson: It seems odd to have something that clearly cannot be modified in main when it's easily movable to restricted.
<cjwatson> it can be modified, just within certain parameters
<wgrant> That sounds non-free to me.
<asac> pitti: whatever name you choose, downstreams will have to rename it ... either they dont like "iceweasel", or they dont like "supercoolthing" ... or whatever we choose. The best solution after lots of thought that came out is just to call it webbrowser
<cjwatson> it *could* be moved to restricted, perhaps; and it might make sense. I object to you implying that it's required by our policy when it isn't, though.
<cjwatson> wgrant: yes.
<pitti> asac: iceweasel is a proper noun, whereas webbrowser is a program category where dozens of alternatives exists
<wgrant> Policy might not state it, but common sense seems to.
<pitti> asac: I wouldn't mind if you just call it iceweasel or vanilla-webbrowser, but not just 'webbrowser'
<cjwatson> I like vanilla-webbrowser
<cjwatson> I wouldn't mind the firefox branding going into restricted. It's just not a bug that it's in main and I wanted to make that clear.
<liw> does that mean that the browser with branding should be called kinky-webbrowser?
<cjwatson> *cough*
<liw> I would s/vanilla/plain/
<asac> i just want to prevent endless discussions of names ... thats why webbrowser makes sense - where the discussion is mostly about "is it ok to use that" and not "is it a good name"
<pitti> another idea:
<pitti> could firefox-3.0 ship the generic branding, and if you install firefox-3.0-branding, that would give yuo the firefox one?
<wgrant> cjwatson: I don't see where in the license policy unmodifiable code is permitted.
<pitti> thereby removing the need for a new "plain" package name at all?
<asac> pitti: that was the way it was in a previous prototype.
<asac> pitti: the point is that you still want a "webbrowser-3.0-branding" package, that forces the firefox branding off the disc imo
<cjwatson> wgrant: where's the unmodifiable code in the branding?
<cjwatson> I thought the unmodifiable parts were basically images
<wgrant> cjwatson: So it's fine if the code is GPL but I can't modify it because of the trademark restrictions?
<pitti> asac: uninstall firefox-3.0-branding ?
<wgrant> GPL/$(various other free licenses)
<asac> pitti: yeah. but then you end up in upgrade issues ... people now using firefox suddenly loos their branding
<asac> i had recommends on the -branding package ... but that didnt work well enough in upgradfe case
<pitti> asac: firefox depends: firefox-base, firefox-branding, firefox-base recommends: firefox-branding, ubuntu-desktop depends; firefox-base
<pitti> wouldn't that work?
<pitti> s/;/:/
<asac> pitti: ubuntu-desktop DEPENDS firefox-base?
<asac> thought that its a recommend
<pitti> asac: well, or recommends, whatever u-desktop does right now
<asac> pitti: remember we have firefox -> firefox-3.0
<pitti> since webbrowser-3.0-branding depends: firefox-3.0, we won't get rid of the 'firefox-3.0' package name anyway
<pitti> asac: yes, it was just a schema, not the real package names
<cjwatson> wgrant: while I'm not entirely happy about this, general practice has been that we only consider items enforced by copyright law when assessing freedom, since you could always change the name to avoid the trademark. While I'm not sure there's a clause specifically about this in the Ubuntu licensing policy, the parent DFSG has a comment in point #4: "The license may require derived works to carry a different name or ...
<cjwatson> ... version number from the original software. (This is a compromise. The Debian group encourages all authors not to restrict any files, source or binary, from being modified.)"
<asac> pitti: i thought about it ... it doesnt really work for downstreams
<asac> pitti: they dont have a similar vehicle that "firefox" is
<asac> e.g. that tracks them over over upstream version bumps
<pitti> asac: we mainly need 'firefox' for clean upgrades, so downstreams just have to provide that, too; or do you mean something else?
<asac> pitti: ... they need to provide firefox and patch the depends on -branding out of it
<asac> let me think a moment ;)
<pitti> yay, ubuntu desktop CDs seem happy
<cjwatson> asac: I'm reminded of linux-generic vs. linux-image-generic
<asac> pitti: i dont think that it works.
<pitti> asac: how does it work in your proposed schema then?
<asac> pitti: problem is for upgrades you need "depends" ... and depends will couple the branding
<asac> pitti: you apt-get install webbrowser ;)
<asac> then you get webbrowser
<asac> you apt-get install firefox
<asac> then you get firefox
<pitti> asac: those are two different things
<pitti> for upgrades you need 'firefox' no matter what
<pitti> and for apt-get, 'firefox-base' and 'firefox' would give you unbranded/branded
<pitti> apt-get install webbrowser (as it is in NEW now), would still pull in 'firefox-3.0', so you have the firefox package name either way, too
<asac> pitti: so you want to introduce firefox-base and firefox-3.0-base?
<pitti> asac: maybe not -base, could be -unbranded, or something descriptive
<asac> pitti: thats not the point here. the point here is that if you dont have "firefox" installed ... nor "webbrowser", then you wont be upgraded to 3.1
<cjwatson> asac: would a recommends from ubuntu-desktop on the firefox branding package not be strong enough?
<cjwatson> recommends from metapackages have been treated quite strongly for a while
<asac> cjwatson: in apt-get ? or just update-manager?
<cjwatson> asac: apt-get
<cjwatson> in hardy, it had a special bit of configuration that said to treat all recommends from Section: metapackages as depends (unless you were trying to remove those packages etc.; usual rules)
<asac> i'd thiknk that there is a good proportion of users out there that doesnt have ubuntu-desktop installed
<cjwatson> that's probably true
<cjwatson> although, realistically, that's because they didn't want it installed
<cjwatson> (for some specific reason)
<asac> cjwatson: true. but if possible i dont want to unbrand everyone that doesnt have ubuntu-desktop on their system
<cjwatson> oh, I wasn't suggesting that
<pitti> that's why I thought that firefox-3.0 should depend on -branding and -unbranded, -unbranded recommends -branding, and -desktop recommends -unbranded
<cjwatson> I'm actually slightly surprised that recommends from firefox (or firefox-3.0 or whatever) isn't strong enough with intrepid's apt
<cjwatson> asac: would it help if the firefox official branding diverted the generic branding, so that you could install both simultaneously?
<asac> pitti: as long as the user can just apt-get remove -branding, i am sure that good proportion of users will end up without branding
<pitti> then upgrades would keep the branding (even with apt-get), fresh installs would get it through the recommends, and derivatives or users can uninstall -branding
<asac> pitti: why would apt-get upgrade keep the branding? it doesnt install any new package afaik
<pitti> asac: but isn't that precisely what you want? if I purge -branding, I end up with a vanilla one
<asac> it wont hold it back
<pitti> asac: dist-upgrade would
<asac> and on next dist-upgrade the recommends dont get installed
<pitti> asac: dist-upgrade gets the branding because firefox-3.0 depends on both
<pitti> upgrades -> depends, installs -> recommends
<asac> pitti: and also we are again talking about -unbranded and -braded ... which is basically what we have right now
<asac> webbrowser-3.0-branding (aka -unbranded) and firefox-3.0-branding
<pitti> no, it's not what is in NEW
<pitti> I object to webbrowser-3.0-branding
<pitti> it's too generic, it's confusing, and it won't help us to completely get rid of 'firefox-3.0'
<asac> pitti: i dont want to get rid of firefox-3.0 for now
<asac> if thats required we can do so later
<pitti> (neihter do I, but I thought that was the goal)
<pitti> and we'll need it for upgrades at least until the next LTS anyway
<asac> you proposal wants a firefox-3.0-base package ... which still is firefox
<pitti> asac: let's call it firefox-3.0-unbranded, not -base
<pitti> asac: if you are happy with having 'firefox' as the transitional package, then splitting out -branding is all we need, and we don't need a -base or -unbranded
<pitti> i. e. firefox depends: firefox-3.0, firefox-3.0-branding
<pitti> which is solely for upgrades
<pitti> and firefox-3.0 recommends: firefox-3.0-branding
<pitti> for installations
<pitti> this would be the easiest structure if we can live with 'firefox' being the transitional package, not 'firefox-3.0'
<pitti> since u-desktop just depends on firefox, not firefox-3.0, this would be suitable IMHO
<asac> pitti: i dont want firefox as transitional package ... i just want a top level package that users and dowstream can track/seed
<pitti> asac: right, and that would be 'firefox' in the branded case, just like we have now
<pitti> and if you need an unbranded one, this could just be called firefox-unbranded, depending on firefox-3.0
<asac> pitti: thats basically what we have now
<asac> we have webbrowser (aka firefox-unbranded)
<asac> which depends firefox-3.0, webbrowser-3.0-branding
<pitti> asac: so can we merge webbrowser into 'firefox-3.0' and adjust the dependencies accordingly?
<asac> he?
<asac> no ... then we will loose the top-level package that users can track
<pitti> ?
<pitti> why, we'd have firefox-unbranded for that?
<asac> pitti: so your suggestion is to s/webbrowser/firefox-unbranded/ ?
<asac> and keep the rest as it is?
<pitti> not really
<pitti> firefox and firefox-unbranded should just be metapackages IMHO
<asac> pitti: firefox and webbrowser are metapackages atm
<pitti> the webbrowser package, as it is in NEW, has stuff in it
<pitti> which should be in firefox-3.0
<asac> firefox-3.0-branding has firefox branding ... webbrowser-3.0-branding has webbrowser branding bits
<pitti> asac: if it's hard to just put the neutral branding right into firefox-3.0, for my sake we can keep it it in the firefox-unbranded not-quite-metapackage, but that seems harder to maintain in the long-term when we have a new firefox major version
<lool> "* State: Failed to upload" hmm first time I see this
<asac> pitti: so the only point left is webbrowser name
<pitti> asac: not for me
<asac> and you suggest to change that firefox-unbranded
<cjwatson> I'm OK with names of the general form firefox-unbranded, FWIW; as asac points out we still have firefox-3.0 anyway
<asac> which isnt really nice.
<bigon> seb128, it could maybe intresting to rebuild all the rdeps of enchant to be sure libs doesn't export too mush symbols, what do you think about that?
<pitti> asac: no, that's not what I am proposing
<seb128> bigon: after the freeze this week that could be a good idea yes
<cjwatson> lool: which package?
<pitti> asac: give me a minute to draw it
<pitti> asac, cjwatson: my proposal: http://people.ubuntu.com/~pitti/tmp/firefox-dependencies.txt
<asac> pitti: if you have firefox-3.0 (without firefox) installed now and run apt-get upgrade; apt-get dist-upgrade you will end with unbranded browser i guess
<pitti> asac: only if you additionally disable recommends
<pitti> asac: if you disable recommends, remove firefox, and remove ubuntu-desktop, you can't expect a clean upgrade with apt-get, right
<cjwatson> pitti: I've changed component-mismatches to include everything again, and removed component-mismatches-mobile. If you want to put it back the way it was, see the obvious comments in ~lp_archive/dak/cron.sync
<asac> pitti: i think if you run apt-get upgrade .... this will make the reommends on next dist-upgrade void
<pitti> cjwatson: ah, thank yuo
<cjwatson> (and perhaps come up with better names for those files while you're at it, if you do put that back ...)
 * ogra wonders ... i have a mobile image of which i mounted the squashfs in an aufs merged overlay ... mounted sys and proc in there, now if i run "sudo chroot /tmp/mergemount apt-get update" apt just hangs ... i cant ctrl-c or kill it 
<pitti> asac: but that'll just hold it back, until you run dist-upgrade?
<pitti> asac: 'it' being the firefox package
<asac> pitti: no ... it forgets about that
<asac> pitti: thats what i tested
<ogra> anyone an idea ?
<asac> pitti: also apt-get install firefox-unbranded wont unbrand firefox here?
<asac> but thats probably just a conflicts
<pitti> asac: right, you need to uninstall firefox-branding, not uninstall firefox-unbranded
<cjwatson> I think it must be quite rare to have only firefox-3.0 installed
<cjwatson> we've never used that name in our metapackages AFAIK
<seb128> lool: ups, sorry, conflict upload on rhythmbox I overwrote your change
<pitti> cjwatson: ... and trying to upgrade from hardy to intrepid with "apt-get upgrade"
<pitti> instead of dist-upgrade
<cjwatson> I do often use 'apt-get upgrade' as a first pass; it hadn't previously occurred to me that that would mark recommends as "seen"
<asac> there are zillions of people that run apt-get upgrade
<cjwatson> I wonder if that's a bug
<cjwatson> most of those people will have firefox installed, though
<pitti> asac: if you want this work, then firefox-unbranded could conflict to firefox-3.0-branding, yes; I think that makes sense
 * ogra wonders if he hit an ap bug here 
<ogra> *apt
<pitti> asac: updated the text file for that
<asac> pitti: right. but thats exactly what i had before ;)
<asac> pitti: and there were issues with unbranding for users ... even though i uploaded it to mozillateam ppa only
<pitti> asac: nowhere in http://people.ubuntu.com/~pitti/tmp/firefox-dependencies.txt we have a package name "webbrowser"
<asac> pitti: thats true. but thats just "choosing" a different name ;)
<asac> which i think is an endless story
<pitti> asac: no, avoiding the 'webbrowser' package altogether
<asac> but introducing firefox-unbranded instead
<pitti> right
<asac> pitti: which is just a rename
<pitti> no, firefox-unbranded ought to be a metapackage
<ogra> oh, great, even attaching strace to the hanging apt makes strace hang as well :/
<asac> pitti: with "before" i dont mean what i uploaded, but what i uploaded to PPA like a week ago
<pitti> webbrowser-branding isn't a metapackage, it has a them ein it
<pitti> ah, I don't know the ppa package
<asac> pitti: as i said. i had almost exactly that approach
<asac> firefox-3.0 -> free branding
<asac> firefox-3.0-branding -> diverges to firefox branding
<asac> (which was painful btw, to do the diverges)
<asac> but that didnt work out well for users .... they came into channel and complained about lost branding because they ran apt-get upgrade
<pitti> asac: well, I could live with people doing their upgrades that way, since it won't matter for hardy -> final intrepid upgrades, but if you think it's a real problem, I don't mind introducing yet another package and make firefox-3.0 the (sub)metapackage
<asac> pitti: i think its a real problem. i have no time to deal with all the folks complaining that their branding is gone
<pitti> but frankly, if you just have firefox-3.0 installed, without firefox, and use apt-get upgrade for dist-upgrades, you know what you are doing
<asac> pitti: and i still dont buy why webbrwoser cannot be used
<asac> or at least ... we rename the package we have now
<pitti> asac: for the same reason why we don't have packages "shell", "kernel", "terminal", and "mailreader"
<asac> and dont do another depends/recommends shuffling round
<asac> pitti: sure. i am fine with just s/webbrowser/something-else/
<pitti> they are not package names, they are application categories, and since we have more than one alternative for each category, we need proper nouns for applications
<asac> but i dont want to lead the discussion on what the "something-else" is
<lool> cjwatson: package was rhythmbox
<pitti> asac: I want to avoid something-else altogether
<lool> seb128: So what happens then?
<pitti> we won't get rid of firefox, as in the package name
<lool> seb128: I'm surprized that's possible
<seb128> lool: I'll merge your change
<asac> pitti: people should not apt-get install firefox* metapackages to get the unbranded build
<lool> seb128: You did a regular upload with the same version or some archive command?!
<seb128> lool: I did a new upstream svn snapshot, my version is higher than yours and has been uploaded 5 minutes later
<lool> Oh I see, thanks
<asac> firefox-3.0 is a transitional situation ... but the top level metapackages should not contain firefox
<pitti> asac: I updated the text file with the alternative for the stupid 'purged all metapackages and uses apt-get upgrade' case
<pitti> which, IMHO, is really stupid, but *shrug*, if we care, then we can use that schema
<asac> pitti: firefox-3.0 still recommends branding ... which means users that have -3.0 installed will get unbranded on upgrade :)
<pitti> asac: no
<pitti>   firefox-3.0         Depends: firefox-3.0-unbranded, firefox-3.0-branding
<asac> oh ... further down :)
<pitti> asac: I kept my original proposal at the top, and the alternative below, yes
<doko> pitti: libffi4 is not built anymore. it should be removed from the archive
<pitti> doko: hm, I wonder why it doesn't appear in NBS; thanks
<asac> pitti: i really dislike that kind of approach. i had dpkg-diverts before and they dont feel good. keeping the unbranded bits in its own packages is much cleaner
<asac> but i said that before :)
<doko> pitti: and libffi4-dev as well
<pitti> asac: right for diversions, an alternatives symlink to the default theme should certainly do
<asac> pitti: no alternatives are even worse
<asac> please lets not use that
<ScottK> pitti: I agree with you about unzoo and I've asked the Debian maintainer to drop it to suggests.  There's a new clamav upload imminent and I'll change ours if he doesn't get to it.
<pitti> ScottK: hello
<pitti> ScottK: ok, thanks
<asac> pitti: so what is the problem of having a "something-else-3.0-branding" and something-else metapackage?
<pitti> ScottK: I'll review arj next
<asac> except that its funky to make firefox-3.0 the "unbranded" package on its own
<ScottK> ;-)
<pitti> asac: if something-else doesn't expand to "webbrowser", but a proper noun, I'm ok with it
<pitti> but I won't NEW a package "webbrowser" into the archive
<ogra> ubuntu-browser  ?
<pitti> which means, that you either convince another archive admin, or rename it to heatbadger, or vanilla-webbrowser, or something creative :)
<asac> ogra: putting ubuntu into it is bad for downstreams
<asac> pitti: fair enough
<pitti> weaselchrome!
<ogra> thebrowser :)
<asac> pitti: awebbrowser ;)
<pitti> its-the-browser-you-want-trust-me
<Company> mostawesomepackage
<asac> Company: i had awesome-browser at some point
<asac> but that was disliked elsewhere ;)
<Company> :(
<pitti> asac: what about webbrowser-branding -> firefox-3.0-neutralbranding?
<asac> pitti: the property i want to keep up is that the metapackage (and the unbranded branding package itself) dont have the firefox mark in it
<cjwatson> neutral-browser?
<asac> whitebox-browser
 * cjwatson looks at chromium and considers neutronium
<asac> all those are nice ideas ... but they still kick off a new "brand" imo
<asac> hehe
<pitti> I don't understand why firefox-3.0-neutralbranding is a problematic name for a package which depends on firefox-3.0 and ships a theme for firefox-3.0
<cjwatson> neutral-, whitebox-, vanilla-, plain- aren't really brands, imo
<ogra> pure-
<ogra> :)
<pitti> I guess by the time we settled for a name, we'll all use webkit...
<asac> most likely
<Company> so use a name that works for webkit branding, too!
<Company> apple can be nasty with branding ;)
 * ogra really really doesnt get that apt-get thing ... but bug #264048 shows thats happening in other setups too :/
<ubottu> Launchpad bug 264048 in apt "`apt-get update` hangs indefinitely when run against the ubuntu-mid daily images" [Undecided,New] https://launchpad.net/bugs/264048
<ogra> when is mvo back ?
<pitti> asac: reload please, see the bottom part
 * ogra wonders if that could be related ot the new hardening stuff somehow 
<pitti> asac: I think this is what your current intention is, right? (just to understand the structure)
<pitti> asac: except that I split your webbrowser-branding into a metapackage with neutral name (unbranded-webbrowser) and a contentful package firefox-3.0-neutralbranding
<asac> pitti: right
<asac> pitti:  however, i think we should choose one name for "unbranded-webbrowser" ... and use that just like i did in the branding package name
<asac> or is there any reason to keep it in a firefox-3.0 prefixed package?
<ScottK> pitti: You may want to hold off on arj for a bit.  It may get dropped without help from us.
<pitti> ScottK: yay
<pitti> ScottK: an initial grep for sprintf made me weep :)
<ScottK> Apparently the new upstream drops support for external unpackers.
<pitti> asac: yes, because it is a package depending on firefox-3.0, shipping a firefox-3.0 theme; it won't work with lynx or epiphany, etc.
<pitti> ScottK: it's just a recommends, right? so we could promote clamav and the rest without arj for now
<asac> pitti: ok
<ScottK> pitti: They are.
<ScottK> (just recommends)
<pitti> asac: thanks for the discussion, and sorry for my pickyness *hug*
<asac> pitti: cjwatson: i am a bit demotivated now (not too bad ;)) and will push that back a day or two ...  (until alpha-5 is out i guess)
<pitti> yeah, it's a post-alpha 5 thing anyway
<pitti> we are in freeze
<MacSlow> pitti, how to correctly call getenv() from within a gdb session?
<MacSlow> pitti, the gdb "call"-command only works on functions defined in the symbol-table of the process being debugged, right?
<pitti> MacSlow: (gdb) call puts(getenv("HOME"))
<pitti> MacSlow: right, but since getenv and puts are libc6, they should always be there
<MacSlow> pitti, ok I tried it just with getenv("HOME") on a different process and it seem to have worked ... $1 = -870404906 is the reply I got
<pitti> MacSlow: right, but the pointer value isn't very interesting, so you should wrap a puts() around it
<pitti> that will give a segfault for nonexisting variables, of course, but that doesn't hurt
 * pitti lols "Kernel alive" .... "Kernel really alive"
<pitti> linux: I'm not quite dead yet!
<MacSlow> brb
<pitti> Riddell: ouch, seems that kubuntu livefses have failed to build since 20080819
<pitti>   gtk-qt-engine-kde4: Depends: gtk-qt-engine but it is not installable
<pitti> E: Broken packages
 * pitti fixes
<mdz> pitti: dovecot's LDA is choking on a message in my mailbox; it triggers an assertion failure which invokes abort() but no core file or apport crash are generated
<mdz> reading message mdz@fastmail.fm@mail.messagingengine.com:1 of 4 (2019 header octets). (922 body octets).Aborted (core dumped)
<mdz> pitti: the handler for SIGABRT is default, which should trigger a core, which I would expect to trigger apport.  any guess what's wrong?
<pitti> mdz: right, apport ignores aborts
<mdz> oh
<pitti> mdz: I did that a while ago after seb128 complained about all the useless bugs we got from that
<mdz> pitti: why were they useless?
<pitti> since we can't capture the assertion message automatically in a generic way
<mdz> oh
<pitti> (IIRC)
<pitti> mdz: in effect they were similarly useless like gdb stack traces in mono programs
<mdz> pitti: I guess it is the same in this case; it is printing an assertion error before it crashes
<pitti> mdz: if you want to grab it locally, edit /usr/share/apport/apport and delete the paragraph in line 266
<mdz> pitti: perhaps it would be useful to provide some API which would log a crash for assertion failures explicitly
<pitti>     # ignore SIGABRT (we currently have no way of extracting abort() messages
<pitti>     # or mono's stderr for stack traces).
<pitti> mdz: yes, ideally we'd modify libc6's abort() method to create such a dump for us
<pitti> and mono to call the mono debugger (there's even a spec for it)
<mdz> pitti: or provide our own assert() macro
<mdz> once abort() is called it's too late to know what went wrong
<pitti> right, we'd need that, abort(3) doesn't have a message
<mdz> neat, trying to file a bug report about this assertion failure triggers an OOPS in launchpad
<pitti> lol
<MacSlow> pitti, even for upstream gdm (gdm-binary to be precise) "call puts(getenv("HOME"))" caused a segfault in libc for strlen(). As you mentioned before this usually indicates that the sought for env. var. is not set.
<MacSlow> pitti, that sounds fishy to me
<MacSlow> restarting everything and trying XDG_SESSION_COOKIE also failed of course
<pitti> kirkland: currently doing a test-install of ubuntu alternate; d-i asks me whether to create ~/Private, but it asks me for a separate password for it; I thouoght it would just use my account password and unlock it with login?
<MacSlow> seb128, when did you last try upstream gdm?
<pitti> MacSlow: right; did you check ck-lists-sessions? does it have one for you?
<pitti> ck-list-sessions, rather
<pitti> kirkland: ah, nevermind, it explains about the random passphrase; the dialog should explain that you don't need to know it and it's unlocked with yuor account passworrd
<MacSlow> pitti, no that failed with the error "** (ck-list-sessions:8034): WARNING**: Failed to get list of seats: Launch helper exited with unkown return code 0"
<pitti> a-haaa!
<pitti> MacSlow: do you restart dbus at any time?
<pitti> (the system dbus, in particular)
<MacSlow> well sometimes...
<pitti> and do you have console-kit-daemon running?
<pitti> MacSlow: don't do that; you can't restart dbus without losing all your CK sessions
<pitti> if you do, you have to restart consolekit as well, and restart gdm as well
<MacSlow> pitti, in which order: console-kit, dbus, gdm?
<pitti> kirkland: how difficult would it be to use the ecryptfs setup to encrypt yuor entire $HOME?
<pitti> MacSlow: restart dbus, killall console-kit-daemon, restart gdm
<pitti> MacSlow: but why do you need to restart dbus in the first place?
<MacSlow> pitti, sometimes my script refuses to start gdm due to var/run/dbus/system_bus_socket not being accessable
<MacSlow> pitti, I do not have to restart the console-kit-daemon manualy?!
<pitti> MacSlow: no, it should get activated by /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service
<pitti> just killing the current daemon should do
<MacSlow> pitti, ehm... I should add I run all that on non-system-wide installed /opt/gdm-new on hardy still
<pitti> MacSlow: that should be fine
<MacSlow> I'll try that
<asac> hmm ... any clue what i need to isntall in order to make apt-get update use https:// urls?
<cjwatson> apt-transport-https
<asac> thanks
 * lamont wonders if there is something equivalent to a "graphing calculator" in the archive, or if he needs to teach his daughter how to use gnuplot
<Treenaks> lool: gnuplot IS a graphing calculator! :P
<Treenaks> uhr
<Treenaks> lamont:
<lamont> Treenaks: well, yes... OTOH, despite her years of debian-installer testing, daughter is rather a gui person
<lamont> holy crap.  nearing a full decade since she did her first debian install.
<pitti> how old is she then, 11? :-P
<lamont> heh
<soren> I was thinking 10 :)
<lamont> just turned 16
<MacSlow> pitti, while ck-list-sessions now did not spit out a warning like before, it just reported nothing (after I did the proper restarting of dbus, gdm and console-kit-daemon). But now I get "Failed to identify the current session: Unable to lookup session information for process 'yadda yadda'"
<pitti> darn, I remember having a program which would automatically draw graphs nicely laid out, but I forgot which it was (years ago)
<pitti> MacSlow: k-li
<pitti> MacSlow: sorry, ignore that ^
<pitti> MacSlow: hm, weird; if I call ck-list-session from a VT (which doesn't have a CK session) it still works
<pitti> MacSlow: however, it sounds as if gdm failed to register a session for itself
<pitti> MacSlow: you might use dbus-monitor --system to check whether gdm actually contacts consolekit with OpenSession() or OpenSessionWithParameters()
<MacSlow> I try that
<pitti> ScottK: clamav-base ships ./usr/share/doc/clamav-base/examples/main.cvd which is 1.5 MB (and daily.cvd which is 870 KB); maybe those should go into the -doc package?
<seb128> wgrant: hi, around? your synaptic changes don't work correctly
<wgrant> seb128: I be here.
<wgrant> seb128: What about them doesn't work?
<seb128> wgrant: after applying the g-s-d patch the options have no effect, ie when unchecking the enable option the touchpad still move the cursor
<seb128> wgrant: and the double click on the touchpad do something where the option is not enabled
<wgrant> seb128: You're running a recent synaptics driver?
<seb128> dunno
<wgrant> What does `xinput list-props "SynPS/2 Synaptics TouchPad"` say?
<seb128> wgrant:
<seb128> $ xinput list-props "SynPS/2 Synaptics TouchPad"
<seb128> unable to find device SynPS/2 Synaptics TouchPad
<wgrant> xinput list
<wgrant> Find the Synaptics device, and list the properties on it.
<wgrant> You must have it defined in your xorg.conf, so it will have a different name. But that's what this patch is meant to fix.
<seb128> wgrant: http://paste.ubuntu.com/43038/
<seb128> $ xinput list-props "Synaptics Touchpad"
<seb128> X Error of failed request:  BadRequest (invalid request code or no such operation)
<seb128>   Major opcode of failed request:  146 (XInputExtension)
<seb128>   Minor opcode of failed request:  36 ()
<seb128>   Serial number of failed request:  12
<seb128>   Current serial number in output stream:  12
<wgrant> Wow.
<wgrant> Which version of -synaptics do you have?
<seb128> wgrant:
<seb128> ii  xserver-xorg-input-synaptics               0.14.7~git20070706-2.1ubuntu4              Synaptics TouchPad driver for X.Org server
<seb128> let me upgrade ;-)
<wgrant> Aha.
<wgrant> Ancient. That would do it.
<wgrant> If you had the recent g-c-c, you likely wouldn't see the Touchpad tab at all.
<ScottK> pitti: IIRC clamav behaves rather unfortunately if those don't exist, so I think we'd need to then have clamav depend on the -doc package if we did that.
<ScottK> Which would be rather counter productive.
<pitti> ScottK: oh, if clamav needs them, they should be in /usr/share/clamav
<ion_> tkamppeter: Iâll take a look.
<pitti> ScottK: Debian policy mandates that you need to be able to rm -rf /usr/share/doc without ill effects
<seb128> wgrant: right, the tab is not listed using the patched version
<ScottK> pitti: Ah.  I missed that.
<ScottK> pitti: I think you're right.  Let me look into it.
<pitti> ScottK: ok, thanks a lot!
<wgrant> seb128: Great. I suspect that it'll all work when you use a newer -synaptics.
<ScottK> It needs A database, just not, I guess that one.
<pitti> ScottK: I added one question to the clamav MIR bug, spamassassin and the plethora of perl modules are ok
<pitti> ScottK: well, I guess it needs to ship a default signature db somewhere, and those files might be just that
<ScottK> That's what I need to check.
<jcristau> wgrant: there's still a bug though. the getprops request shouldn't be done if the server doesn't report a new enough XI version
<ScottK> pitti: In the short term, I don't think we're space contrained on the server CD, so I hope that won't block approval.
<ScottK> contrained/constrained
<pitti> ScottK: no, it won't, but it still looks fishy
<wgrant> jcristau: Is it not OK to just catch the error?
<MacSlow> pitti, in the log produces by "dbus-monitor --system" nothing from gdm shows up when I start gdm up. Does it matter if dbus-monitor is started as non-root user?
<wgrant> jcristau: It's xinput that's dieing, not the stuff that I wrote.
<pitti> MacSlow: no, it works fine as normal user
<pitti> MacSlow: that means that gdm does not attempt to get a CK session on its own
<ScottK> pitti: Another consideration is that jdstrand has a lightly tested apparmor profile that we should decide about adding now or waiting for Intrepid +1.
<pitti> MacSlow: you can compare the output with what you get if you do "ck-launch-session", wait a while, do ck-list-sessions within that subshell, and ctrl+d to leave the subshell (and temporary sessoin) again
<pitti> ScottK: I see nothing wrong with shipping it; if you have doubts, ship it as an example or set it to complaint mode?
<pitti> well, provided that it by and large works, of course
<ScottK> I'd be tempted to ship it now and see if anyone screams.
<ScottK> We can always drop it to complaint mode if there are problems.
<pitti> 'zactly
<jcristau> wgrant: yeah, probably an xinput bug then. but i'm not even sure the server reports xi 1.5 anyway, so..
<wgrant> jcristau: I believe that our xinput is hacked to build without the very new XI, so it's not likely to be upstream's fault.
<jcristau> wgrant: right
<seb128> re
<wgrant> seb128: Any better?
<seb128> alright, installing the new synaptic broke my laptop now
<wgrant> O_o
<seb128> no, xorg seems to be crashing, I can't get to gdm, booting in recovery mode now
<wgrant> Did you grab more X as well?
<wgrant> Lovely.
<seb128> no I didn't
<seb128> I expect depends grabbing what is required
<wgrant> As would I.
<wgrant> I was thinking that the new X might be what killed it.
<jcristau> not getting the new X is what killed it
<seb128> I expect
 * wgrant is glad to not have touched the driver.
<jcristau> tjaalton: you need to bump debian/serverminver in xorg-server, as the driver abi was changed
<wgrant> Much.
<seb128> but it should really conflict or depends on something
<seb128> great, switching to a VT doesn't work either
<soren> zul: What's the deal with the xen libraries? Which to use and which to leave for dead?
<ScottK> pitti: clamav MIR questions answered.
<zul> soren: what about them?
<soren> zul: We have both libxen3 and libxen3.1.
<soren> zul: Is that intentional? If so, which am I supposed to use?
<zul> libxen3.1 can be dropped and it should
<soren> zul: Lovely.
<lool> BenC: Hmm there's a foo branch in ubuntu-intrepid.git now
<lool>  * [new branch]      foo        -> origin/foo
<soren> zul: Could you take care of getting it removed?
<zul> soren: yep
 * soren hugs zul
<zul> thanks..
<tjaalton> jcristau: and rebuild the drivers?
<seb128> jcristau, wgrant: this synaptic thing is nasty, xorg freezes when it loads the synaptic driver and that breaks VT switching too
<tjaalton> seb128: you have dist-upgraded everything?
<seb128> tjaalton: no, I just upgraded synaptic, the package depends and conflict should allow that to work
<tjaalton> seb128: then upgrade xserver-xorg-core too
<wgrant> They should, but they don't because we don't have enough people following strange upgrade schedules :P
<seb128> tjaalton: trying to get some network back first so I can download it, connection to wireless from a VT is not trivial
<seb128> anyway xorg should not just freeze
<tjaalton> I thought every dev was running the daily intrepid :)
<seb128> tjaalton: I'm back from holidays and dist-upgrade is going to take over an hour on this box, I just wanted to test wgrant's patch to sponsor it
<tjaalton> seb128: ok, understood
<tjaalton> I guess bumping the serverminver and rebuilding synaptics is enough
<seb128> still you want to put conflicts to avoid that
<seb128> that's a pretty bad experience
<tjaalton> no-one complained so far
<seb128> I do now ;-)
<seb128> I can give you the versions I'm using if you want
<seb128> it's basically intrepid which is 2 weeks old and current synaptic
<tjaalton> no need, just rebuilding them should do
<tjaalton> erm, should fix the dependencies
<seb128> ok, dpkg -r xorg*synaptic gave me my xorg back
<seb128> now I can log-in, connect to wireless and upgrade xorg too
<tjaalton> cool
<wgrant> If you have a mouse.
<seb128> I have a mouse
<seb128> and I've also a keyboard which I can use ;-)
<seb128> ok, upgrading xserver-xorg-core worked, xorg is working when using the new synaptic now
<tjaalton> great
<wgrant> Excellent.
<tjaalton> lunch->
<seb128> wgrant: ok, your patch works now
<wgrant> Has my g-s-d patch crashed yet?
<wgrant> This is good.
<seb128> MacSlow: hey, no I didn't try running the new gdm since the distro sprint, enough other things to do
<MacSlow> pitti, for just trying ck-launch-session and ck-list-sessions I get this "Faield to get list of seats: Launch helper exited with unknown return code 0" again. The resulting log from dbus-monitor --system is even smaller
<MacSlow> seb128, ok ... was just wonder if you did ... never mind then
<jcristau> tjaalton: those using the property stuff, yes
<seb128> wgrant: g-s-d and g-c-c uploaded
<wgrant> seb128: Thanks!
<seb128> wgrant: thank you for the work on those ;-)
<kirkland> pitti: thanks for the feedback on the ecryptfs dialog...  i'll send cjwatson a patch today.  i wanted to update the verbage slightly too.
<kirkland> pitti: as for encrypted all of $HOME, that was my original proposal at UDS, but it was shot down as being too ambitious for Intrepid; the compromise was an encrypted ~/Private, and revisit encrypted $HOME for Intrepid+1
<kirkland> pitti: technically, there's a few things that would have to be done differently...  ~/.ecryptfs couldn't live there for boot strapping reasons
<kirkland> pitti: an unmounted, encrypted public ssh key would make it hard to ssh in
<kirkland> pitti: little things like that, we'd have to solve
<wgrant> seb128: I couldn't stay away from the desktop forever.
<seb128> wgrant: good to have desktop contributors ;-)
<pitti> MacSlow_: ok, then something in your d-bus packages is really seriously brkoen
<pitti> kirkland: right, good points
<kirkland> pitti: if encrypted ~/Private is deemed as "successful" by the December UDS, I'd like to extend that work with perhaps encrypted $HOME, spending some time focusing on the bootstrapping issues
<torkel> kirkland: is there any way to encrypt the entire directory (and its sub directories) instead of the individual files?
<kirkland> torkel: that's basically how it works
<kirkland> torkel: there is a mount-wide passphrase that is applied to everything below the mount point
<kirkland> torkel: if you're asking, instead, if there's a way to obsfucate the filenames, upstream is working on it
<kirkland> torkel: but that has tremendously bad performance implications
<pitti> kirkland: shouldn't be worse than with complete LUKS disk encryption, should it?
<pitti> you have to decrypt stuff with stat() and opendir() in both cases
<torkel> kirkland: sorry for asking the wrong question, but yes obsfucating the filenames (or the entire directory) so that their real names are not revealed was what I was thinking about
<kirkland> pitti: with ecryptfs, an "ls" operation does not involve decryption, and so that is very fast (dare I say as fast as non-encrypted?)
<kirkland> torkel: right, so like I said, upstream is working on it
<kirkland> torkel: pitti: the current approach the upstream kernel maintainer is taking is to use a single, symmetric key for all filename obsfucation per mount point
<kirkland> torkel: pitti: one of the neat things about ecryptfs is that each file can be encrypted using different algorithms, keys, etc. as defined in their extended ACLs
<kirkland> torkel: pitti: that's the decryption situation we'd want to avoid on doing a simple "ls"
<kirkland> torkel: let me note one nice advantage of clear text filenames....
<kirkland> torkel: it sure makes it easy to rsync backup your encrypted data to untrusted, offsite storage ;-)
<pitti> seb128: hm, why doesn't shutdown/reboot from the logout menu doesn't quit the session any more? reboot/halt in a running session is certainly very bad, since programs cannot ask "save document" questions and the WM can't save the session?
<pitti> kirkland: yep, granted
<kirkland> torkel: pitti: all that said...  i think a reasonable solution with obfuscated filenames is underway and I would like to see it as an option too
<seb128> pitti: not sure, mvo noticed that too and wrote it on http://bugzilla.gnome.org/show_bug.cgi?id=545123, seems an upstream bug to me too
<ubottu> Gnome bug 545123 in general "Please support the SmInteractStyleNone again" [Minor,Unconfirmed]
<pitti> seb128: ok, so it is a bug, not intended; good, thanks
<pitti> (wrong bug#?)
<pitti> slangasek: rock, thanks for PAMifying the consolekit package
<seb128> pitti: no, read the comments
<seb128> "That looks correct, the logout-request signal gets send, but it seems like it
<seb128> is not acted upon. Should I file a seperate bug about this?
<seb128> "
<pitti> ah, I see
<pitti> seb128: ATM I'm tempted to reinstate the upstream consolekit reboot thing, for testing and having something that works until we come up with something better
<pitti> seb128: WDYT?
<seb128> pitti: I've been arguing for that since before your holidays ;-)
<seb128> pitti: and yeah, I think it's time to get those actions fixed in intrepid, whatever is the way used
<seb128> hey tedg
<tedg> Morning seb128
<mdz> argh
<mdz> drwxr-xr-x 15 hplip lp 4096 2006-07-27 02:30 /var
<ubottu> Launchpad bug 4096 in meld "meld: merge new debian version" [Medium,Fix released] https://launchpad.net/bugs/4096
<mdz> did that happen to anyone else?  I remember older bugs where hplip was changing permissions on /
<pitti> mdz: fine here (root:root), but then again I uninstall hplip right after a fresh ubuntu install
<mdz> pitti: both times that I've seen it, I panic and chown it before I think to check the ctime
<mdz> the only thing remaining owned by hplip is /etc/ptal
<mdz> which isn't owned by any package
<mdz> and is from 2005.
 * mdz deletes
<pitti> brb
<tedg> So is there a "right way" to add icons to a package?  I know that the diff can't include binaries, so I was told I need to base64 them...  dh_?
<tedg> Anyone know a package that does this so I can steal some debian/rules code?
<ion_> tedg: Iâd use sng. Itâs in universe, though.
<tedg> ion_: Hmm, interesting -- but this package is in main.
<ion_> Then might as well use base64, presuming nobody feels like getting sng to main. :-)
<tedg> I'm thinking about base64 encoding an entire tar file, that way I only have to deal with that once.
<cjwatson> tedg: uudecode is the usual approach; look for build-dependencies on sharutils
<seb128> dholbach: can you look at bug #261017?
<ubottu> Launchpad bug 261017 in psad "Please sync psad 2.1.3-1.2 (universe) from Debian unstable (main)." [Wishlist,Incomplete] https://launchpad.net/bugs/261017
<dholbach> seb128: in a bit, in a meeting right now
<seb128> dholbach: alright
<dholbach> seb128: opened in the browser and will check it in a bit of time - thanks
<cjwatson> tedg: browser-history is an example I'm familiar with
<cjwatson> nothing magic about the make rules though, lay it out however you're comfortable with; it's just a one-liner
<cjwatson> I think it might be more conventional to have an explicit target for the generated file, but I was young and foolish when I did that
<cjwatson> tedg: grep-dctrl -nsPackage -FBuild-Depends,Build-Depends-Indep sharutils /var/lib/apt/lists/*_Sources | sort -u
<mterry> Keybuk: Can you talk to me about the current blockers for the usplash-until-desktop blueprint?  (https://blueprints.launchpad.net/ubuntu/+spec/usplash-until-desktop)
<Keybuk> mterry: kernel mode setting
<mterry> Keybuk: Sigh.  Is that available in any drivers right now?  (like, say, intel)
<Keybuk> not in any stable fashion
<Keybuk> basically until we have that, X must be started from a text console
<tedg> cjwatson: Cool, thanks I'll start looking.
<tedg> If "broken" is a mode, we have kernel mode setting 100% :)
<mterry> Keybuk: OK.  I was looking into trying to start X on a different VT, so that we could at least avoid the "brown screen" until the login screen was available
<mterry> Keybuk: But I ran into difficulties (the graphics driver wanted to take over the screen).  Do you know technical details about solving that?
<tjaalton> better to ditch usplash and start using plymouth for intrepid+1
<siretart> what's the procedure for nominating a contributer upload access for a specific package in universe? mail the technical board?
<cjwatson> siretart: I believe so
<slangasek> pitti: sure thing :)
<didrocks> BenC: around?
<BenC> didrocks: yep
<didrocks> Hi ;) I have been working on removing the multiuser tag on some packages for calling /etc/init.d scripts
<didrocks> one example is the nvidia-common-kernel package (#254264) which has been fixed in upstream
<didrocks> hum, bug #254264
<ubottu> Launchpad bug 254264 in nvidia-kernel-common "Still uses multiuser argument to dh_installinit" [Low,Confirmed] https://launchpad.net/bugs/254264
<didrocks> So, after having talked to many person, everyone telling me to talk to another person (an amazing trip), tseliot told me to get in touch with you
<didrocks> apparently, this doesn't need a FFe (from the previous discussion I had)
<didrocks> and I would like to know how to get those (6 packages) sponsored (if everything all right for you) in intrepid
<pitti> slangasek: good morning
<seb128> lool: does python-dbg -c "import gobject" work for you?
<didrocks> BenC: well, I will be away for 2 hours approximately. You can respond here when you will have time. I will backlog at my return. Thanks :)
<siekacz> is it possible, that Wall Light theme will be implented in 8.10?
<_MMA_> siekacz: No.
<_MMA_> siekacz: A better place to chat about this is #ubuntu-artwork.
<lool> seb128: Nope
<lool> seb128: I saw this yesterday during my debug session as well but forgot about it later
<seb128> lool: ok, it seems to want to import apt_pkg, which is weird
<lool> seb128: It's because of the apport hook
<seb128> lool: that breaks applications build btw
<seb128> ah
<seb128> hum
<lool> The actual error is ImportError: could not import glib (could not find _PyGLib_API object)
<seb128> alright, makes sense
<seb128> maybe worth pinging doko about it
<seb128> I've no real clue about python-dbg
<lool> seb128: Looks like we're missing a _hobject_d.so
<lool> err _gobject_d.so
<doko> seb128: did you make progress with the python-gobject build, or should I look again?
<seb128> doko: lool fixed it
<doko> ahh, ok
<lool> Fatal Python error: UNREF invalid object
<lool> zsh: abort (core dumped)  python-dbg
<lool> cough
<cjwatson> kirkland: reminder about asking for more info on bug 33649, since it seems you've tested that now
<ubottu> Launchpad bug 33649 in debian-installer "root raid installs have bad grub config" [High,Confirmed] https://launchpad.net/bugs/33649
<kirkland> cjwatson: yes, so based on my testing, i opened a bug, submitted a patch for grub, which kees sponsored last night
<cjwatson> right, I noticed that bug but it had already been merged by the time I saw it
<kirkland> cjwatson: just an fyi, he asked for a debdiff; i have a bzr branch that you might want to merge/resolve
<kirkland> cjwatson: i'd like to test a new cd image with that grub patch on it, to see if it solved the issue that I saw
<kirkland> cjwatson: once i do that, and i'm satisfied with my testing of grub/33649, i was then going to mark as "Fix Released" again, and ask for more infor
<cjwatson> kees: debdiff for something where a bzr branch existed? you could use the LP UI if you just wanted to look at it ...
<cjwatson> ok
<jawub> Hi, for school I have to do some work on a open source project (which is very cool :). I'm really interested in usability and interaction design so I'd like to do some usability testing for a ubuntu project. I'm currently thinking about testing the ubuntu website. Who do I have to contact?
<kirkland> jawub: newz2000 is the webmaster
<jawub> hmm not online on irc. Thank you
<kees> cjwatson, kirkland: I had wanted a source.changes because I'm lazy.  ;)  Also, I already merged the branch into the grub bzr tree.
<BenC> didrocks: kernel team doesn't maintain nvidia drivers anymore...
<lool> ScottK: bug #229845: python-kde3-dev still uses the wrong path here
<ubottu> Launchpad bug 229845 in python-kde3 "python-kde3-dev wrong directory structure" [Undecided,Fix released] https://launchpad.net/bugs/229845
<lool> ScottK: Hmm the fact looks reversed?
<lool> *patch
<jpds> seb128: Could you possibly sponser a package to Debian for me? (pidgin-facebookchat)
<tseliot> BenC: I have never touched nvidia-kernel-common furthermore I have no upload privileges therefore I suggested didrocks to talk to you. Can either someone from the kernel team or a core-dev have a look at didrocks' patch, please?
<seb128> jpds: no, my debian disk doesn't boot due to hdd issues so I've no current debian unstable install I can use to do builds and testing
<ScottK> lool: I'll have a look at it.
<seb128> jpds: and I've already way too much to do
<pitti> kees: ugh, it almost seems that the "set -m" "logsave fsck &" "set +m" sequence in checkroot.sh doesn't work any more; the script simply terminates after the "logsafe fsck"
<jpds> seb128: OK; I shall look for someone else.
<kees> pitti: erf.
<kees> pitti: I still think it should be possible to pass an env var around with the pid.
<pitti> kees: I added set -x and echos after every line
 * kees nods
<kees> pitti: so you were able to reproduce it, I take it?
<pitti> and there is no output any more after the fsck call; I do see the output from fsck itself
<ogra> cjwatson, bug 264048 might affect the liveCD
<ubottu> Launchpad bug 264048 in linux-lpia "`apt-get update` hangs indefinitely when run against the ubuntu-mid daily images" [Undecided,New] https://launchpad.net/bugs/264048
<pitti> kees: yes, I set up a vm with /usr, /tmp/ and /scratch on separate partition, and tune2fs -C 50'ed them
<ogra> seems aufs has a prob with mmap
<pitti> kees: VMware snapshots FTW :)
<kees> pitti: heh
<pitti> kees: checkfs.sh starts immediately afterwards, and in the end I have /usr not mounted, and logsave still running
<kees> pitti: yup, that's certainly it.
<cjwatson> ogra: oh, interesting. I'll try it
<cjwatson> funnily enough, unionfs had what sounds like a nearly identical problem some time back
<kees> pitti: I saw this post on the debian planet: http://kitenet.net/~joey/blog/entry/human_nature/ :)
<ogra> the hang i reported with ls was caused by the hanging apt-get though
<didrocks> BenC, tseliot: and there are some more in addition to #254264 (#254249,#254252,#254257,#254259). All related to removing multiuser. I am contacting a lot of persons and everytime everybody agrees with this change (as it has been first requested by james_w in server team), but it is still waiting for sponsoring (getting tired :)). Don't know to who the right person to speak with!
<BenC> tseliot: you seem to have done an upload before...do you just want to have someone sponsor it?
<cjwatson> ogra: bug 144001
<ubottu> Launchpad bug 144001 in apt "crashes with SystemError: E:Unable to write mmap - msync" [Critical,Fix released] https://launchpad.net/bugs/144001
<BenC> tseliot: I'm neck deep in some other things at the moment
<pitti> kees: heh
<cjwatson> in that case it was a failure rather than a hang
<pitti> kees: with bash it does the same; WTH...
<BenC> tseliot: if you can get it prepared, I'll sponsor it
<tseliot> BenC: ok, thanks
<ogra> cjwatson, oh, thanks ... i had seen that before but didnt make the connection :)
<ogra> cjwatson, hmm, but thats unionfs
<cjwatson> 17:04 <cjwatson> funnily enough, unionfs had what sounds like a nearly identical problem some time back
<cjwatson> I was just clarifying that
<ogra> ah
<ogra> sorry, missed that ... i'm jumping channels with -mobile atm
<lool> doko: Hey
<cjwatson> so the hang is on the rename()?
<doko> lool: here!
<lool> doko: When code does PyImport_ImportModule(), does it have to be patched to use _d instead to work with python-dbg?
<ogra> cjwatson, thats where strace gets stuck, yes
<cjwatson> lool: why do you think mmap is to blame? the thing that's being rename()d when it hangs doesn't seem to have been previously mmaped
<cjwatson> ogra: I wonder if it's reproducible with mv
<lool> cjwatson: Because the process is hung in a mmap
<ogra> well, lool was referring to something from the aufs docs where it tlaked about mmap2
<cjwatson> rename() is not very simple in a union filesystem; it has a whole C file all to itself
<cjwatson> lool: really, is strace lying?
<lool> Hmm refreshes his memory and looks at the strace again
<cjwatson> ogra: did ls /var/lib/apt/lists/ reproduce the problem *before* running apt-get update?
<cjwatson> I suspect that once you hit the problem all sorts of things will break, but that doesn't mean they would trigger it to start with
<ogra> no, only *while* it was hanging stuck
<lool> cjwatson: No, it's me not able to use Launchpad
<cjwatson> i.e. the directory is now buggered
<alex-weej> RGBA anti-aliasing has regressed in Intrepid as of a few days ago - it appears as if we've dropped the FIR patches that we picked up a couple releases ago
<cjwatson> lool: oh, you were confused by the read more...
<lool> cjwatson: Yes
<ogra> next time i'll do an attachment :)
<lool> How stupid
<persia> It's not reproducible with mv (or wasn't for me, using the same files)
<lool> I suspect I'm slightly lacking sleep
<cjwatson> a very slow and tedious approach would be to write a series of C programs to basically bisect the syscall list you get from strace
<lool> Yeah I first asked for a mmap() test case
<cjwatson> also, is there anything in the kernel log, like an oops?
<persia> Unfortunately not.
<ogra> ogra@osiris:~$ cat /var/log/kern.log|wc -l
<ogra> 19
<ogra> ERR !
 * ogra is confused
<ogra> where is my kern.log ?
<ogra> last entry from aug 31st
<ogra> nothing in dmesg at least
<Treenaks> ogra: your kernel didn't have anything to say?
<ogra> Treenaks, yeah, apparently ...
<ogra> since i updated to 2.6.27-2-generic
<ogra> -1 seems to have done logging until sunday
<ogra> but dmesg should have the oops which it doesnt
<Treenaks> ogra: are your log daemons running?
<ogra> [  105.118542] loop: module loaded
<ogra> [  105.342986] squashfs: version 3.3 (2007/10/31) Phillip Lougher
<ogra> [  105.424975] aufs test_add:375:mount[9920]: uid/gid/perm /tmp/squashfs 0/0/0755, 0/0/01777
<ogra> Treenaks,
<ogra> ogra@osiris:~$ ps ax|grep klogd
<ogra> 17156 pts/0    S+     0:00 grep klogd
<ogra> obviously not
<cjwatson> it might of course not actually be an oops
<asac> cjwatson: bug #263668 needs a punch
<ubottu> Launchpad bug 263668 in ubuntu "FFe - mobile broadband wizard and database for network-manager 0.7" [Wishlist,In progress] https://launchpad.net/bugs/263668
<asac> ;)
<ogra> hmm ... sudo /etc/init.d/sysklogd start doesnt actually give me a klogd process
<ogra> thats weird
<ogra> though i get a rinning syslogd
<ogra> *running
<ScottK> lool: Looks like I fixed it for python-kde3, but not python-kde3-dev.  Thanks.
<ogra> seb128, you are the NEW master today ?
<seb128> ogra: theorically yes, in practice I've way too much to do and will probably not clean everything which is there, anything special you need to get accepted there?
<asac> ogra: https://wiki.ubuntu.com/ArchiveAdministration ... according to that yes.
<seb128> oh reminds me I wanted to sync swfdec0.7
<ScottK> That or I messed it up completely.  I'll get it fixed up after Alpha 5 is out.
<asac> seb128: wait
<asac> seb128: there is a sponsoring bug
<ogra> seb128, i'd like to see the apps from bug 263493 going through soon (modulo netbook-remix-launcher) they all had REVU peer reviews already so should be an easy wave through thing
<ubottu> Launchpad bug 263493 in ubuntu "Please package applications from netbook-remix" [Undecided,New] https://launchpad.net/bugs/263493
<asac> seb128: and there are "diffs"
<asac> seb128: the bug is ready
<seb128> asac: I know, I asked you to look at that weeks ago
<asac> seb128: it just needs a FFe
<lool> seb128: Ok, I think I grasp the pygobject byg
<seb128> asac: but since nothing is happening I was going to sync 0.7 which is in debian experimental
<seb128> lool: cool
<ogra> seb128, but if you dont make it i see tomorrow is "Anyone" day ... so i can wait 24h
<asac> seb128: its ready. bug 254841
<ubottu> Launchpad bug 254841 in swfdec0.6 "Please sponsor swfdec0.7 0.7.4 (universe) into Intrepid" [Wishlist,New] https://launchpad.net/bugs/254841
<seb128> asac: no need, that's GNOME
<seb128> ogra: ok, will have a look later
<asac> seb128: didnt know that. then we can just upload those bit
<lool> seb128: the new libpyglib calls into the python module API and needs to be built with python-dbg; the "find debian/python-gobject-dbg ! -type d ! -name '*.so' | xargs rm -f" snippet silently removes the actual shared library built for python-dbg
<lool> Then we happily mv the .so which is just a symlink to the lib which is no more to _d.so
<seb128> asac: well, rather it's required for swfdec-gnome which is a GNOME component so about the same, just upload ;-)
<asac> seb128: ok. will do that now
<seb128> lool: ah I see
<lool> Both packages can be installed at the same time, and we load the regular lib instead of the _d one
<seb128> asac: thanks
<seb128> lool: so we would need another set of library for debug builds?
<lool> seb128: I also suspect that even if we fix this we're going to be hit by stuff being linked to this lib
<seb128> lool: hum, what do you suggest then?
<lool> I'm not sure
<seb128> doko: ^
<lool> seb128: The problem is that other things are going to be linked to that
<doko> lool, ohh sorry, did miss your message
<lool> doko: Do you have a library package in mind which uses python API and provides a shared library and is built with python-dbgN
<lool> doko: Basically new pygobject python extensions are linked to a new shared library (which upstream installs in /usr/lib, I moved to /usr/lib/pygobject/pythonX.Y)
<doko> lool: no, subversion was such a case, but it doesn't server as an example
<lool> doko: The problem is that the actual extensions have an ELF link to pyglib.so.0
<doko> lool: did you use my pygobject package, or did you start with seb128's?
<lool> doko: I started from scratch again and glanced at your packages
<doko> then why not change that ELF name?
<lool> doko: They intend to make other packages link against it too
<doko> imo, these should live in /usr/lib, or else you will have to work with rpath, won't you?
<lool> doko: The problem is that I needed a lib per python interpreter
<doko> the default name still could be a symlink to the upstream name
<doko> correct, I did rename these libs
<lool> So I've put the libs below /usr/lib/pygobject/pythonX.Y; but I proposed upstream to either do that or use /usr/lib/libpyglib-pythonX.Y.so
<lool> They seem to prefer the latter, but didn't implement anything yet
<lool> I sued my first patch which was to use /usr/lib/pygobject
<ogra> you sue your patches ?
<ogra> evil :)
<lool> I guess I could have a /usr/lib/pygobject/python2.5-dbg
<lool> Right, that would work
<lool> doko: Ok; I think I know how to defer the problem until upstream decides which they want :)
<doko> lool: yes, the latter sounds fine. then we still have the problem of building the debug library. but that should be solvable as well
<lool> Hmm what problem of building the debug library?
<asac> seb128: hmm ... i reconsidered my assumptions. please sync swfdec; the changes we need need to go into swfdec-mozilla only.
<seb128> asac: ok will do, thank you for looking at it ;-)
<asac> seb128: ill do the swfdec-mozilla merge now
<seb128> asac: thanks
 * norsetto hugs asac
<lool> doko: What problem of building the debug library?
<kirkland> cjwatson: btw, i've been meaning to thank you for doing the user-setup hooks for ecryptfs-setup-private!
<kirkland> cjwatson: thanks!
<doko> lool: if it doesn't need to be a separate build, that's ok as well
<cjwatson> kirkland: oh, no problem
<pitti> kees: gotcha!
<pitti> \o/
<kees> pitti: oooh! what was it?
<pitti> fsck -C behaves differently now
<pitti> before it would report "pass cur max"
<pitti> now it reports "pass cur max device"
<pitti> thus fsck_progress_to_percent() tried a division by something like "8 /dev/sda1"
<pitti> which was considered a division by zero and thus the set -e'ed script aborts
<pitti> I made it more robust now by using "read pass cur max tail"
<pitti> so that it works with older and newer fscks
<pitti> but the set -x output seems to lag badly
<pitti> so that you seldomly even get that far
<pitti> there goes my last milestoned bug \o/
<lool> seb128, doko: I pushed a pygobject with pyglib for python*-dbg; it fixes python-dbg -c import gobject for me
<seb128> lool: thanks
<doko> \o/
<balachmar> tkamppeter: I have a question about bug 258421 and was forwarded here. I followed the session of fixing bugs yesterday and this is one of the "low hanging fruit", but I am unsure if this patch is wanted. Partly because you are the only one in the bugreport. :)
<ubottu> Launchpad bug 258421 in gtk+2.0 "GTK apps should send PDF to CUPS when printing" [Medium,New] https://launchpad.net/bugs/258421
<lhnn> what sets -minimal, -standard, -desktop, etc., apart? As in, which packages are included in server/desktop version? And there is no -server meta package? P.S. if there is a page with this info, just link me to it instead of spending time answering >_>
<lhnn> <_< Well, even if I leave, please answer the question, I'll be back later or check the IRC logs. thx.
<persia> lhnn: The contents of the seeds.  Look up SeedManagement on the wiki.
<lhnn> 10-4
<tseliot> superm1: it looks like my patch for nvidia-settings was ignored: http://www.nvnews.net/vbulletin/showthread.php?t=118640
<siretart> evand: you might want to subscribe to the package 'usb-creator'. I just tried it, see bug #264464
<ubottu> Launchpad bug 264464 in usb-creator "fails on 1GB usb stick" [Undecided,New] https://launchpad.net/bugs/264464
<evand> siretart: thanks, will do
<kees> slangasek: agh, sorry, I uploaded debianutils just now -- I had forgotten about the freeze.
<tkamppeter> balachmar, the motivation for bug 258421 is that PDF should get the standard format foir print jobs
<ubottu> Launchpad bug 258421 in gtk+2.0 "GTK apps should send PDF to CUPS when printing" [Medium,New] https://launchpad.net/bugs/258421
<tkamppeter> balachmar, see the related blueprint.
<CSX_Lappy> hi, i've got a problem with gnoem-commander
<CSX_Lappy> at start (from console) it prints this:
<CSX_Lappy> CRITICAL **: GnomeCmdConFtp* gnome_cmd_con_ftp_new(const gchar*, const std::string&): assertion `uri != NULL' failed
<CSX_Lappy> then it work, till i try to add an ftp connection to the list ... when i click on the OK button it crashes with  "Segmentation fault"
<CSX_Lappy> again this was printet just bevore the segmentation fault: CRITICAL **: GnomeCmdConFtp* gnome_cmd_con_ftp_new(const gchar*, const std::string&): assertion `uri != NULL' failed
<CSX_Lappy> some ideas how i can fix it? reinstalling with purging and deleting of the config files didn't worked
#ubuntu-devel 2008-09-04
<emgent`nl> heya
<kirkland> slangasek: ping
<slangasek> kirkland: moo
<kirkland> slangasek: hiya, i have a small grub-installer patch that I'd really, really like to see on the next iso's...
<kirkland> slangasek: http://people.ubuntu.com/~kirkland/grub-installer/grub-installer.debdiff
<kirkland> slangasek: seeing as the freeze and all, i thought i might bump your direction
<slangasek> kirkland: well, currently the "next isos" are slated to be the ones /after/ alpha-5
<kirkland> slangasek: oh...  are we under a freeze right now?
<slangasek> kirkland: no bug number; can you explain here what's broken?
<slangasek> kirkland: yes, alpha-5 tomorrow
<kirkland> slangasek: refresh http://people.ubuntu.com/~kirkland/grub-installer/grub-installer.debdiff
<kirkland> slangasek: bug number inserted
<kirkland> slangasek: the grub install multiple MBRs to a RAID mirror is not working as designed, because my previous patch was calling findfs()
<kirkland> slangasek: that finds the filesystem, not the device
<slangasek> ah
<kirkland> slangasek: what i needed to call was mapdevfs()
<slangasek> by "filesystem", I guess you mean "mount point"?
<kirkland> slangasek: right, misread on my part by what those functions did
<slangasek> ok
<kirkland> slangasek: turns out the determination i need is actually already done further up in the code
<slangasek> if we aren't yet advertising this as a feature of alpha-5, I think it's better to hold it until after tomorrow
<kirkland> slangasek: bootfs_nodevfs=$(mapdevfs $bootfs)
<slangasek> but I'm happy to upload it then
<kirkland> slangasek: okay
<kirkland> slangasek: it will make it into the next daily iso build in that case?
<slangasek> yes
<kirkland> slangasek: I don't particularly care where it's in alphaX ...  just that i get an iso soon with the updated udeb that I can test
<slangasek> can you post the debdiff to the bug, and subscribe me?
<kirkland> slangasek: sure, i'll do the bzr branch monkey business too
<slangasek> even better :)
<kirkland> slangasek: or perhaps not...  bzr is not responding atm, something about an upgrade, perhaps
<ericholscher> when is the package freeze for 8.10?
<slangasek> ericholscher: there's no freeze that we refer to as a "package freeze"; we're currently in Feature Freeze, meaning that package changes for introducing new features, instead of for fixing bugs, need to be approved
<Spets> https://wiki.ubuntu.com/IntrepidReleaseSchedule
<ericholscher> okay
<slangasek> ericholscher: django 1.0 is on my radar, fwiw
<ericholscher> ojay ;)
<ericholscher> okay*
<ericholscher> thanks much for reading my mind :)
<slangasek> well, your channel list, but ok ;)
<slangasek> (plus, people coming into the channel within an hour of the django 1.0 release and asking about freezes makes it easy to guess, don't it?)
<lool> haha
<lool> slangasek: Heh can i get Chrome in intrepid?
<jcristau> slangasek: pfft. you mean within an hour of the xserver 1.5 release.
<slangasek> lool: twitch
<slangasek> jcristau: is there anyone I don't know by name who would be asking for an xserver 1.5 freeze exception? :
<slangasek> )
<jcristau> slangasek: ok, probably not
<ScottK> slangasek: There's already a bug open asking motu-release for an FFe for django 1.0.  My response up until now has been wait until it's released.
<slangasek> ScottK: yep, saw it :)
<slangasek> ScottK: a python-django freeze exception has already been requested for lenny, on the Debian side, so it should be available pretty soon...
<ScottK> slangasek: Trunk in the DPMT svn has already been at least partially updated.
 * NCommander needs to request a freeze exception for swfdec so we can get a new upstream version in
<RAOF> NCommander: Did'nt I see 0.7.4 in intrepid-changes this morning?
<NCommander> Oh, it might have just gotten updated
<NCommander> I didn't check yet
<NCommander> (I just noted that there was a new upstream out, I didn't see if it was packaged yet)
<wgrant> Hmmm. Did something change with font antialiasing over the past 24 hours or so.
<RAOF> I think it might have, yes.  And for the worse.
<philwyett> wgrant: Text in dialog boxes, specifically file text?
<wgrant> philwyett: Specifically every bit of text.
<philwyett> wgrant: Not got that many issues text issues.
<wgrant> Firefox and Thunderbird are almost painful to look at.
<philwyett> nvidia driver and display configuration is broken. However I am going to do an Alpha 5 install before reporting up to 20 bugs. :-/
<RAOF> I think this might be different between the nouveau/nvidia cases.
<philwyett> I am on nv and have one set of issues. Installing nvidia 177 driver an doing 2 reboots to get it to activate, I then have a whole set of new issues. :-D
<philwyett> Installing the nvidia driver on one box this morning did not call for reboot as it should :-/
<RAOF> Why should it call for a reboot?
<philwyett> Install requires requires a a reload of X and it is done via reboot thrugh the restricted drivers desktop app. Or always has done before now. :-)
<philwyett> -requires
<RAOF> Just logging out is sufficient ;)
<philwyett> I know this.
<RAOF> Or, at least, should be now.
<philwyett> But the app doesn't even tell you that!
<philwyett> Doing the updates this morning. After I decided quick reboot as two X components had been updated (just be cautious). Going for a reboot just restarted X the first time. This is why I am waiting for Alpha 5 and do a fresh install and look at the cases I have collected before reporting things and creating bugmail.
<pitti> Good morning
<_Genius_> quiero colaborar con el proyecto ubuntu
<_Genius_> programo en C/C++
<_Genius_> help
<_Genius_> :(
<lifeless> _Genius_: check the topic:
<lifeless>  Development of Ubuntu (not support, not application development on Ubuntu)
<dholbach> good morning
<persia> _Genius_: Also, you may find that https://wiki.ubuntu.com/ContributeToUbuntu answers most of your questions, and that the rest are better asked in English in #ubuntu-motu
<NCommander> persia, as an aside, did the TB (or was it MC) determine if the AGPL is free or non-free?
<persia> NCommander: Generally license freeness falls to the archive-admins, although it might be escalated to the TB in questionable cases.
<persia> I've not heard of any determination in one way or the other for AGPL
<NCommander> persia, I heard it went to the TB, obviously they can't come to a conclusion
<persia> NCommander: I wouldn't come to that conclusion, but rather that if it went to the TB, it has yet to appear on the agenda for a TB meeting, and so may be in queue for deliberation.
<NCommander> ah
 * NCommander decides to blog
<slangasek> is that last sentence in some way connected to the preceding ones?
<cjwatson> I believe somebody did ask the TB before bothering to wait for a determination from ubuntu-archive, yes
<mdke> fwiw, Mark and mdz have both expressed the view that it is free
<persia> Raw foolishness and impatience.  Best to wait until there is an AGPL package uploaded, and see in which component it ends up in as the result of NEW.
<mdke> the CC and TB were approached after the individual apparently discussed the issue with MOTU but couldn't get to a conclusion. He was obviously not told about that potential procedure
<cjwatson> in the last shallow analysis I did, it looked like it was probably free but that there were some practical concerns and wording problems with the licence
<mdke> or if he was, he skipped it :)
<cjwatson> but that's not an Official Statement
<mdke> well, Mark and mdz form a majority of the TB, so I suspect that's enough to decide the issue. But if people have concerns about the licence that are enough to warrant potential exclusion from main, then it's worth bringing them to the TB's attention
<NCommander> cjwatson, so how are you doing tonight?
<cjwatson> undercaffeinated
<NCommander> cjwatson, sounds about right. I'm currently rebootstrapping Ubuntu from scratch
<NCommander> (at some point, the insanity of it all will kick in)
<pitti> ScottK: can you please seed clamav and spamassassin, so that they don't generate a lot of noise in component-mismatches? TIA
<soren> pitti: Wow, they've been promoted already? Neat.
<pitti> just finished the review, yes
<pitti> it's really s/ScottK/server team/, so whoever feels like it, please go ahead
<gnomefreak> anyone know if we added/removed support for "intex rtl8139D" nic from kernel?
<mdke> cjwatson: I've copied ubuntu-archive into that agpl thread, so if you push my email through the moderation queue, they can chip in on it
<cjwatson> meh, wonder why bug 264337 is happening
<ubottu> Launchpad bug 264337 in oem-config "OEM Installation - oem-config-prepare icon not the desktop" [Undecided,New] https://launchpad.net/bugs/264337
<cjwatson> mdke: ok
<pitti> bryce: please add screen-resolution-extra to the ubuntu desktop seed
<pitti> bryce: or make it a dependency of something adequate, whatever is more suitable
<bryce> pitti, I don't actually know how to add stuff to a seed, but I can add it as a dependency
<pitti> bryce: well, I can help yuo with the seeding; but let's first discuss which is better
<pitti> bryce: which package shuold depend on it?
<bryce> gnome-control-center.
<pitti> I guess it isn't called from the menus, but from the xrandr capplet?
<pitti> right
<pitti> that makes sense then
<bryce> correct; I've already uploaded the patch that calls the s-r-e script if it exists
<soren> cjwatson: Would I be abusing germinate's blacklisting functionality if I just want to add all the binaries from a single source package bar a single one? "%clamav + !clamav-milter" looks a lot nicer than listing the 9 "good" packages from clamav.
<slangasek> soren: I immediately have to wonder why blacklisting anything is required, instead of just seeding clamav-milter
<pitti> soren: you certainly shouldn't explicitly seed its dependencies
<pitti> soren: i. e. you should never seed something like libclam4
<slangasek> oh, that's to blacklist clamav-milter?
 * slangasek stands on his head
<seb128> pitti: hum, apport is buggy apparently, it doesn't tag crasher for retracing
 * NCommander takes pictures of slangasek on his head
<NCommander> good morning slangasek
<pitti> soren: seeding clamav will pull in libclamav, clamav-freshclam, etc.
<NCommander> how goes it?
<seb128> pitti: see bug #264301 bug #264360 bug #264362
<pitti> seb128: ugh
<ubottu> Launchpad bug 264301 in update-manager "update-manager crashed with SIGSEGV in gtk_scrolled_window_unset_placement@plt()" [Undecided,New] https://launchpad.net/bugs/264301
<ubottu> Launchpad bug 264360 in apport "apport-gtk crashed with SIGSEGV in gtk_scrolled_window_unset_placement@plt()" [Undecided,New] https://launchpad.net/bugs/264360
<ubottu> Launchpad bug 264362 in gui-ufw "gufw.py crashed with SIGSEGV in gtk_scrolled_window_unset_placement@plt()" [Undecided,New] https://launchpad.net/bugs/264362
<slangasek> NCommander: well enough, though I'm led to suspect that you're deliberately using timezone-inappropriate greetings
<seb128> pitti: they are nowhere in the retracer logs so I think they didn't get tagged at all
<seb128> hey NCommander
<NCommander> slangasek, I just don't support i18n natively yet
<NCommander> hola seb128
<seb128> pitti: should I manually tag those or do you want to have a look first?
<pitti> seb128: I have a look first
<pitti> seb128: it does have apport-crash, so in general tagging seems to work
<NCommander> seb128, so how goes your $TIME_OF_DAY
<seb128> NCommander: good, waking up and having coffee
<seb128> pitti: that's worth noting that those are crashes in python applications, not sure if that makes a difference
<NCommander> seb128, nice, I need to get some sleep, I've been rebuilding Ubuntu's base packages manually so I'm starting to loose my mind
<seb128> lol
<seb128> NCommander: 'night ;-)
<seb128> NCommander: btw how is the gtkmm 2.13 update going? ;-)
<NCommander> seb128, not yet, I still need to wait for my statically linked GCC to finish
<NCommander> seb128, still waiting on pangomm ;-)
<pitti> seb128: improbable, but possible, of course
<seb128> NCommander: did you open the upstream bug about the license? and you have pangomm locally so nothing prevent you to work on the update so it can be uploaded when pangomm is accepted
<NCommander> seb128, I have it locally, and let me file the bug first
<NCommander> seb128, I've discovered the absolute "joy" of bootstrapping Ubuntu from scratch
<pitti> seb128: oh, crap, I got it
<pitti> PackageArchitecture: all
<pitti> seb128: you were right
<seb128> ah ;-)
<seb128> pitti: I retag those and let you fix apport then, thanks ;-)
<cjwatson> soren: err. just bear in mind that that means that *no* other seeds in the same collection will be allowed to include clamav-milter
<pitti>         a = report.get('PackageArchitecture', report.get('Architecture'))
<pitti>         if 'CoreDump' in report and a:
<cjwatson> it's a very big hammer
<pitti>             if a != 'all':
<soren> pitti: *facepalm* Of course. You're absolutely right.
<NCommander> seb128, I can't find the pangomm module in their bugzilla
<seb128> pitti: any reason you special cased arch all there?
<pitti> soren: however, what's so evil about -milter that you want to blacklist it?
<pitti> seb128: bzr blame'ing
<seb128> NCommander: http://bugzilla.gnome.org/enter_bug.cgi?product=pangomm, you already opened bugs on it
<soren> pitti: ISTR ScottK saying something about leaving it out of main for some reason.
<pitti>   * apport/crashdb_impl/launchpad.py: Check PackageArchitecture for 'all', to
<pitti>     not set a retracer tag 'need-all-retrace'.
<soren> pitti: Perhaps I should just leave this all to him.
<pitti> seb128: ^
<seb128> ah
<pitti> soren: right, it shouldn't be in main, but that doesn't mean we have to blacklist it
<seb128> pitti: should I open a bug so you can keep track of the issue?
<pitti> soren: if we just seed clamav, the binary, then only the transitive dependencies will be pulled in
<pitti> seb128: if you wish, but I'm fixing it right now
<seb128> ok so no need
<soren> pitti: That was sort of the question I was asking :) I wasn't sure of the severity of the blacklisting, but if we only just add clamav, everything should be fine.
<NCommander> seb128, I can't find the file that's GPL specific
<seb128> NCommander: look to your debian/copyright, you noted it
<NCommander> I feel like I'm loosing my own mind :-)
<seb128> NCommander: something tell me you are making no effort tonight ;-)
<NCommander> seb128, No, plenty of effort, I'm pioneering a PIE aspect of Ubuntu
<seb128> NCommander: too much effort maybe then ;-)
<NCommander> seb128, http://bugzilla.gnome.org/show_bug.cgi?id=550789
<ubottu> Gnome bug 550789 in general "Missing GPL license text" [Normal,Unconfirmed]
<seb128> NCommander: thanks
<NCommander> seb128, no problem. kees has wanted to -fPIE the architecture for ages, but it requires a hell of a lot of work to be done, to the point that I felt rebootstrapping from scratch was the "easiest" way to go
<NCommander> ^amd64
<NCommander> seb128, now that its noted, can you approve pangomm through NEW on ubuntu :-)
<seb128> NCommander: I'll sponsor the upload and ask somebody else to have a look, it's bad taste to approve it's own uploads ;-)
<NCommander> I thought it was already uploaded O_o;
<pitti> seb128: testing the fix now; please go ahead and retag
<seb128> pitti: ok, thanks
<seb128> NCommander: no this GPL thing stopped me
<NCommander> seb128, so now that upstream been pinged, and the copyright file is good, no issues?
<seb128> NCommander: it should be alright, I'll upload
<NCommander> Sweet, my maintained packages count goes up :-)
<slangasek> cody-somerville: do you know whether anyone's testing the xubuntu candidate images for alpha-5 yet?
<directhex> pitti, thanks for sorting #262719
<pitti> directhex: thanks for writing the MIR
<cody-somerville> slangasek, I've poked in #xubuntu-devel
<cody-somerville> I'll download and burn right now
<slangasek> cool
<pitti> seb128: yay, bug 264626
<ubottu> Bug 264626 on http://launchpad.net/bugs/264626 is private
<seb128> pitti: don't have access
<pitti> seb128: ^ argh, sorry; well, it got the tag now
<seb128> good ;-)
<directhex> pitti, better news: i've been chatting with upstream and debian, and mono itself should be able to drop ubuntu patching post-intrepid
<pitti> seb128: oh, the i386 screen has an open chroot login; were you going to work in it?
<seb128> pitti: yes, I'm updating the i386 retracer and I'm looking on the amd64 why those retracing give broken stacktraces
<pitti> seb128: the amd64 one, too (wget CoreDump.gz
<pitti> seb128: ok, thanks, I won't mess with it then
<NCommander> directhex, SCORE
<pitti> directhex: rock
 * NCommander hugs directhex 
<RAOF> directhex: No more crazy evolution-sharp-build-breaking livecd patches?  Woo!
<directhex> RAOF, apparently that's already turned off in current intrepid packages
<RAOF> I thought NCommander reworked it so that it wasn't so break-my-build crazy.
<directhex> the only current diffs between what's in pkg-mono svn and ubuntu are the arg_max bug (changed upstream, or debian will need to worry about it when new libc lands post-lenny, whichever is sooner) and gda2 dependency hacking (which upstream has promised to port to gda3 asap)
<seb128> pitti: the i386 retracer is available, should I restart it or do you want to test something?
<NCommander> RAOF, the patch is still needed until unionfs is completely dead, so I rewrote the patch as not to be stupid and have a stack exploit.
<pitti> seb128: no, please go ahead and restart
<seb128> pitti: done
<directhex> RAOF, he did! except now apparently aufs doesn't need it
<NCommander> directhex, at the time, the livecd was still unionfs :-)
<RAOF> Hm, which reminds me.  There's an easy to fix gtk-sharp memory leak that I should get debdifing.
<cjwatson> we have at least one critical problem with aufs, so don't count your chickens
<NCommander> s/was/still is/g
<directhex> cjwatson, well the patch is still there if need be, it's just off in 00list
<RAOF> ...which would go faster if my ISP didn't think 50 bytes/sec was blazing fast!
<NCommander> RAOF, what, you have AOL?
<directhex> right, i have a minibus to catch
<StevenK> RAOF: For an Australian ISP, that's too fast
 * cody-somerville is downloading at 1.4mb/s :-)
<tseliot> mvo: have a look at my reply here: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/247376
<ubottu> Launchpad bug 247376 in ubuntu-release-notes "undefined symbols when trying to load fglrx" [Undecided,Confirmed]
<tseliot> mvo: I'll be glad to help
 * RAOF is usually able to download at ~1Mb/sec
<RAOF> Urgh.  Does anyone else feel like doing what should be a simple cherry pick from upstream svn for this gtk-sharp memory leak?
<mvo> tseliot: thanks, that sounds reasonable, I will look into it later today
<tseliot> mvo: ok
<NCommander> RAOF, sorry, already have my own lack of sanity "issues"
<seb128> oh, mvo is back
 * seb128 hugs mvo
<mvo> hello seb!
 * mvo hugs seb128
<RAOF> NCommander: Bah!  Do my bidding!  Oh, well.  I'll go and do some washing up then.  Presumably gtk-sharp2 will have finished checking out by then.
 * pitti hugs mvo, hey mate!
<NCommander> RAOF, lol
<cody-somerville> slangasek, fail. I ran out of disk space :P
 * mvo hugs pitti
<dholbach> hey mvo!
<dholbach> hey seb128!
<seb128> hello dholbach
<mvo> hey dholbach!
<directhex> oh, the other one that should make people happy is the planned changes to mono packaging that should yield a large disk space reduction (no precise figures yet, but we're talking the region of 40% smaller install size for f-spot/tomboy with dependencies)
<pitti> directhex: wannahavewannahave!
<directhex> pitti, not until post-intrepid. sorry.
<pitti> directhex: sure, but it's great to hear; what will change?
<directhex> pitti, in short, 2 main things: .NET 2.0 apps like tomboy will no longer require any .NET 1.1 components to install (libmono-*1.0-cil things), and libmono{1,2}.0-cil will be split into its constituent components, as there's no reason to pull in things like sqlite dependencies because you want to use Mono.Posix for i18n
<directhex> oh, and i forgot the third one: stop depending on libmono0, it's totally not needed by anything except libuno-cil
<mcasadevall_> directhex, what depends on libmono0?
 * mcasadevall_ has gotten creative w.r.t. to cross-bootstrapping gcc
<directhex> mcasadevall_, currently? lots of things. libmono-system*-cil for one (System is the main namespace, and mandatory, so libmono0 is currently always pulled in). also mono-utils and libmono{1,2}.0-cil (useful Mono-originated libraries)
<mcasadevall_> explicately or via dpkg-shlibs?
<directhex> via a flaw in ${cli:Depends} i think.
<pitti> mpt: so I did a mockup of the jockey UI changes we talked about; do you have a minute to have a look at it? I'm not quite sure how to improve the layout, especially where to put the "Install" button
<mdz> cjwatson: I just had a poke at the current daily desktop ISO, and the F4 menu in gfxboot doesn't allow me to navigate with up/down arrow keys in KVM.  Do you know if it works outside of KVM?
<pitti> mpt: http://people.ubuntu.com/~pitti/tmp/main.glade is the glade
<cjwatson> mdz: WFM in kvm with -k en-us
<mdz> cjwatson: me too, with -k en-us
<cjwatson> mdz: usual kvm bug, then. gfxboot itself is working fine
<mdz> cjwatson: ok, thanks
<mdz> cjwatson: I wonder what will happen when I try to use the alpha keys with -k en-us
<mdz> when X is using us(dvorak)
<cjwatson> IME changing the console keymap after that sort of works a bit but not quite. The KVM bug definitely needs to be fixed
<pitti> mpt: http://people.ubuntu.com/~pitti/tmp/jockey-new.png is a corresponding screen shot
<pitti> mpt: the install button is new and a response to your suggestion that clicking on an item in the driver list should not enable the driver, just update the info
<Company> pitti: i like that screenshot
<Company> pitti: it's a nice dialog that says "your hardware sucks, no matter what you chose"
<Treenaks> Company: The German buttons help with that as well ;)
<Treenaks> "Wait.. why are those German? Something must be wrong with my graphics card"
<Company> Treenaks: i know glade too well to still be bothered by those buttons
<Company> my hacking makes me miss out on all the fun
<Treenaks> ;)
<MortenB> How many hours until alpha 5 is out?
<cjwatson> MortenB: we can't give you an answer to questions of that form, because milestones are not scheduled to the hour; it depends on how well testing goes
<MortenB> ok
<cjwatson> wow, yes, something *has* put fonts into ugly mode
<ogra> just make braile the defult output ... solves all font probs
<ogra> *braille
<pitti> cjwatson: me too
<ogra> cjwatson, fyi the cheese/gstreamer fix on the cmpc works ... but only if i apply both of them
<ogra> which means two SRUs :(
<ScottK> pitti: Thanks for all the Spamassassin/Clamav MIR getting done so quickly.  Personally, I not doing anything with seeds until after Alpha 5 releases ..
<ScottK> pitti and soren: The rationale for not promoting the milter is that it's not needed for the use case we wanted to support and it's not (AFAICT) much used in Ubuntu so it'd be hard to get it well tested.
<pitti> ScottK: you're welcome
<verwilst> euh, the flashplugin-nonfree in hardy-backports
<verwilst> 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2
<ScottK> Of course this means I can't approve the FFe for clamav 0.94 anymore, so I need to get to work.
<verwilst> seems to be 9.0 still?
<ScottK> verwilst: Yes.  Tried 10.0 and it didn't go so well.
<ScottK> Had to revert it.
<verwilst> oh
<verwilst> what went wrong?
<verwilst> 9 still crashes like crazy :)
<verwilst> damned proprietary c**p
<verwilst> :)
<ScottK> At the time, 10 was substantially worse on Hardy.
<verwilst> the rc was a lot better though
<ScottK> There's a bug open in hardy-backports if you really care for the details.
<verwilst> 10.0.0.569 is the latest
<ScottK> The bug in hardy-backports is the place to have the conversation if you're interested.
<verwilst> euh which of the 167 bugs is it? :)
<verwilst> 162 sorry
<ScottK> verwilst: Bug 235135
<ubottu> Launchpad bug 235135 in flashplugin-nonfree "[MASTER] Please backport flashplugin-nonfree version 10 beta and asound-plugins from Intrepid so we can drop libflashsupport and the crashes it causes" [Undecided,Invalid] https://launchpad.net/bugs/235135
<ScottK> If you want to start the process of testing the newer version feel free to make it not invalid and document your work.
<kelemengabor> hi mvo
<mvo> hi kelemengabor
<kelemengabor> would you please comment on this bug: https://bugs.launchpad.net/ubuntu/+source/app-install-data-ubuntu/+bug/254628
<ubottu> Launchpad bug 254628 in app-install-data-ubuntu "Make it possible to translate eg. codec name/description strings" [Undecided,New]
<mvo> kelemengabor: yes, I will do that after lunch
<kelemengabor> thanks :)
<mvo> kelemengabor: thanks a lot for your initial version of the script!
<verwilst> ScottK: https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/257403 looks promising
<ubottu> Launchpad bug 257403 in flashplugin-nonfree "Update Flash plugin 10 to the new RC" [Wishlist,New]
<ogra> asac, i cant upload attachments to LP anymore ... FF only offers me dirs, not files ?
<ogra> (intrepid)
<ScottK> verwilst: Yes, that'd have to be done first.  Then a backport.
<asac> ogra: when started?
<ogra> well, its a while ago that i uploaded my last patch via the web ui
<ogra> just noticed it now
<ogra> there are no files in the fileselector at all
<ogra> only dirs
<ogra> system was updated yesterday last
<verwilst>     File name: npwrapper.libflashplayer.so    Shockwave Flash 10.0.0 d569, installed here ;
<verwilst> let's see if it works as great as i think it will ;)
<verwilst> ( from his ppa )
<asac> verwilst: remember that nspluginwrapper istn really at its best atm ;)
<verwilst> asac: what do you mean?
<asac> verwilst: nspluginwrapper 1.1.0
<asac> is hot crack ;)
<verwilst> asac: is that a good or a bad thing? :)
<verwilst> what's improved since the 0.9 thing that hardy has?
<asac> verwilst: are you on i386?
<verwilst> yip
<asac> verwilst: 1st. its available on i386
<asac> (which wasnt the case in hardy)
<cjwatson> is bugs.edge.launchpad.net refusing to take bug comments for anyone else?
<verwilst> euh?
<asac> 2nd. it supports windowless plugins
<verwilst> 0.9 doesnt?
<asac> e.g. flash 10 supports windowless mode now ... so nspluginwrapper had to follow
<verwilst> so nspluginwrapper became the de facto standard of flash-containment? :)
<asac> verwilst: thats the idea.
<asac> verwilst: let me know what your experiences are with that wrapper
<directhex> nspluginwrapper was completely farked in hardy
<directhex> as in "just plain dies every few seconds if you use compiz"
<asac> directhex: you sure that wasnt flash?
<directhex> in the end i gave up & switched to a binary 32-bit firefox in /opt
<directhex> asac, yes, sure
<verwilst> asac: so i should install it too
<verwilst> or is it in backports?
<asac> directhex: you could try to move /usr/lib32/libflashsupport.so away
<asac> verwilst: are you on hardy?
<verwilst> yeah
<verwilst> i took the deb from https://launchpad.net/~psyke83/+archive
<asac> ok ... then you dont have 1.1.0 anyway
<verwilst> ( for flash )
<verwilst> ah ok :)
<verwilst> flash was hell for my girlfriend :)
<verwilst> switched her to ubuntu from windows
<verwilst> and during first thing she did, she had a firefox crash
<verwilst> around 10-15/day
<directhex> flash is hell generally
<verwilst> it was pretty embarrassing
<verwilst> after a few weeks, i did the nspluginwrapper stuffs
<directhex> of course, i wonder how many people will beat me with a pole if i suggest silverlight instead
<verwilst> which made it pretty under control
<verwilst> silverlight _is_ open sourced..
<verwilst> which is its only advantage though..
<directhex> moonlight is. silverlight isn't
<verwilst> oh yeah sorry
<verwilst> i was talking about moonlight
<directhex> any objections to a moon package?
<asac> verwilst: so are you using nspluginwrapper for i386 from mozillateam ppa or something homebrew?
<asac> ogra: try to downgrade xulrunner-1.9 please
<asac> to 1.9.0.1+* (you probably have 1.9.0.2+build3)
<asac> Note: i dont see that problem :(
<directhex> oh, that was something i was gonna ask. will xul-dev 1.8 and 1.9 ever be installable side by side? it makes a difference to moonlight packaging
<ogra> persia, any objections if we dont update denemo in intrepid ?
<asac> directhex: the -dev packages conflict intentionally
<persia> ogra: None at all, as long as you push it to universe.
<ogra> that way we can just get a MIR for libaubio and are done with it for now (indeed postponing the change/decision to intrepid+1)
<ogra> persia, no need for that
 * persia looks at libaubio rdepends
<directhex> ooh, actually, i can get around it by using firefox-2-dev
<persia> ogra: Are you planning on pulling all the libaubio2 dependencies as well?  I know rexbron was looking at freebob, but as far as I know no MIR exists yet.
<ogra> persia, or dropping aubio
<persia> And it's just freebob that I thought might be an issue.
<ogra> from denemo
<persia> ogra: Could do that I suppose.
 * persia looks at denemo again
<ogra> i'd like to go with the easiest option ...
<persia> Wouldn't the easiest just be to drop denemo from the seed?
<verwilst> flash will be open too sooner or later as well ;)
<persia> All the feedback in the thread about it seemed to indicate that nobody used it, but I don't know how widely the mailing list is subscribed.
<ogra> well, that would be a regression imho
<persia> Yeah.  I'm just wondering if people are going to expect denemo to be able to render audio.  They could be pointed to mscore, but the results don't look as good when printed.
<asac> james_w: when i want to use a specific build-dir and stuff like that for a certain tree on my system, how do i best configure that in builddeb.conf?
<persia> Also, what about lilypond?  Are you expecting anyone to be able to render sheet music to a printer from denemo?
<asac> james_w: could i say something like: path/to/intrepid/trees -> result-dir=/path/to/intrepid/results/
<asac> ?
<siretart> asac: what's the use-case of that? how many such branches do you have?
<asac> siretart: i have a bunch of branches
<asac> siretart: i have a bunch that is debian ... another that is intrepid ... another that is hardy
<asac> and i dont want the results to end up in the same directory
<asac> also i would like to use distinct build-areas
<james_w> asac: ideally you could use locations.conf for that, but locations.conf isn't checked for builddeb's settings
<james_w> asac: or perhaps it is now, let me have a look
<asac> james_w: that would be cool ;)
 * siretart has specified that on the command line up to now, but I agree that this is a bit cumbersome
<asac> me too ... and i regularly forget it ;)
<asac> my bzr bd line is already long enough ;)
<james_w> asac, siretart: you can use local.conf, but it's a pain to set it for all branches if you have lots
<siretart> asac: oh, try aliases
<asac> siretart: i tried to ... but i always forget :)
<siretart> asac: I often define ad hoc aliases in my interactive shell for such purposes
<asac> siretart: thats a last resort. i just hoped that i can configure it magically so i dont need to think at all ;)
<siretart> asac: even with locations.conf, you still have to configure them all one-by-one initially
<asac> siretart: not if it does match patterns. ;) ... i usually have *.head branches (which track latest development)
<asac> and .hardy ... for hardy
<james_w> siretart: you can use policies to avoid that in some cases
<siretart> asac: oh, does locations.conf indeed use patterns? that would indeed be helpful here
<siretart> james_w: what is a 'policy' here?
<asac> on top env could specify a different locations.conf
<asac> so when i schroot -csid
<asac> i can build my .head branches but those go to "sid" results then
<james_w> siretart: you can specify a build-dir for /home/whoever/wherever/ and then a policy to recurse, so it is the same for all branches under that location
<asac> james_w: how hard would it be to make that a pattern?
<james_w> asac: no idea
<asac> i usually want all my branches in the same directory
<siretart> james_w: I see. well, I need to read the documentation about that then :)
<james_w> asac: defining what wins is much harder though
<asac> james_w: what wins? as usual: first match wins ;)
<asac> or last match
<asac> i dont mind :-D
<asac> i think its the responsibility of the user to not have disambiguities
<ramvi> [CUSTOMIZING LIVECD] I experienced some problems upgrading something when customizing the livecd. It's fixed now, the bug reports are saved somewhere though and is the first thing that greets a new user. Where are the bug reports saved? How can I stop them from appearing?
<ramvi> nevermind, found it: /var/crash/
<persia> ogra: To get back to the discussion, I think that denemo without any of libaubio, csound, or lilypond is a little crippled.  For my interests, lilypond is sufficient, but I wonder which goal you expect to solve.  Just screen entry of notes?
<ogra> well, i dont know what you got last from me
<ogra> i seem to fail to find jordans original mail
<ogra> and the eudbuntu list only had a single reply
<asac> ogra: would appreciate if you could do a quick downgrade test
<ogra> from y user who said he uses ubuntustudio and is happy with it
<ogra> *s/y/a/
<asac> you are basically running the xulrunner 1.9 security upgrade so any regression is important to track
<asac> ;)
<ogra> which is not really helpful
<cjwatson> asac: bug 262152 bites me on every reboot; I think we should do something about it for intrepid
<ubottu> Launchpad bug 262152 in network-manager "brings up both wired and wireless interfaces; hard to pick just one through the UI" [Undecided,New] https://launchpad.net/bugs/262152
<ogra> persia, i would consider it a regression to drop denemo
<ogra> but then, if its not used there is indeed no reason to keep it
<ogra> asac, will do so as soon as i have a hand free
<asac> cjwatson: lets milestone it then (though i still have that in my head ;))
<cjwatson> thanks
<ogra> could i ask an archive admin to give me a hint why my cheese upload to hardy-proposed is rejected ?
<persia> ogra: I understand that dropping it without cause is a regression: I'm just curious which use case it's there for: without lilypond, it can't render sheets for printing, and without either libaubio or csound, it can't render audio.
<ogra> the drescher mail talks about a md5 mistmatch ... but i definately pulled the source from the archive
 * ogra wonders if he found a bug 
<ogra> c5f767bd9a55d2a515fd8960ec3523c0 1650728 gnome optional cheese_2.22.3.orig.tar.gz is definately the right md5 for whats in proposed
<cjwatson> ogra: there's already a cheese 2.22.3-0ubuntu2 in the archive
<ogra> not on -changes and i dont get it from apt-get source
<cjwatson> it's not the .orig.tar.gz it's complaining about. (The unhelpful message from Launchpad has been fixed for the next rollout.)
<cjwatson>     cheese | 2.22.3-0ubuntu2 | intrepid/universe | source, amd64, hppa, i386, ia64, lpia, powerpc, sparc
<cjwatson> use 2.22.3-0ubuntu1.1
<ogra> intrepid
<ogra> sigh ... i didnt think about looking at intrepid ...
<cjwatson> yes. it's still in the archive; you can't have different things called cheese_2.22.3-0ubuntu2 in hardy and intrepid
 * ogra curses ... doing the same mistake again
<cjwatson> of course, I had the benefit of locate(1) :-)
<ogra> yeah, i had that with a former upload
<ogra> isnt 1.1 for security only ...
<cjwatson> no
<ogra> that gets confusing over time i bet
<ogra> ok
<cjwatson> I've used that scheme for updates plenty of times
<ogra> i always thought .n was limited to security ... assumptions assumptions :)
 * ogra fixes the upload
<persia> The wiki at one point indicated that all SRUs should use the same versioning as for security updates.  I'm not sure if that's the case today.
<cjwatson> SRUs should simply use non-clashing version numbers. This means two things: firstly, don't clash with something that already exists; secondly, don't clash with something that might reasonably be expected to exist later (e.g. if you have 1.0-1 in hardy and Debian doesn't have a newer version for merging into intrepid, don't use 1.0-2)
<cjwatson> beyond that, and especially if the next release along is already a known version, it really doesn't matter
<ogra> yeah
<cjwatson> (also, don't clash with something that *has* existed in the past, of course)
<ogra> heh, indeed
<pitti> persia: it was just a proposal of a scheme which is reasonably clash-free, but not a requirement
<persia> pitti: Indeed.  I think the wiki has been fixed since, but at one point it indicated it was a requirement.
<persia> I suspect it was the result of an overzealous editor, rather than being an official policy.
<ogra> persia, ok, denemo dropped (though i'd still like to find that original mail of joardan)
<persia> ogra: https://lists.ubuntu.com/archives/edubuntu-users/2008-August/004331.html : You could pull from the mbox archive if you need a local copy.
<persia> ogra: Also, although we do Recommends-by-default, please don't remove the Recommends: on lilypond and csound, as for universe use, those are somewhat important for denemo to behave as expected.
 * ogra doesnt get it
<ogra> i'm the listadmin for edubuntu-users
<ogra> why the heck dont i have that mail at all
<persia> ogra: It was also sent to edubuntu-devel, if that helps you find it.
<ogra> o match
<ogra> *no
 * ogra wonders if its time to drop evo ... :(
<mpt> pitti, hi
<pitti> hey mpt
<mpt> pitti, buttons should always use Title Case
<mpt> (unless you're programming for Windows Vista, which you're not)
<pitti> argh no :)
<mpt> pitti, good work removing the column headers
<pitti> mpt: Show License button fixed
<didrocks> hi
<pitti> mpt: column headers?
<pitti> mpt: this is just a glade mockup, so I cannot actually put demo contents into the driver list
<mpt> pitti, yes, "Component", "Enabled", and "Status"
<soren> When do we expect to lift the alpha freeze?
<pitti> mpt: I didn't remove them, it's just the glade; if they shuold go, I can do that in the code
<mpt> ah
<didrocks> is there someone more or less in charge of the lm-sensors package?
<mpt> pitti, why do the list and the description talk about "enable" and "disabled" while the button reads "Install..."?
<mpt> What are we doing here, exactly?
<pitti> mpt: the Install button will actually read "Enable" or "Disable", depending on whether the driver is currently enabled
<pitti> mpt: and the Show License.. button will only appear for non-free drivers
<mpt> pitti, do you need to do anything else to see the license, other than clicking that button?
<pitti> mpt: main.glade updated to p.u.c.
<pitti> mpt: I envisioned that clicking the button will produce a second dialog with a large scrollable text area and a close button
<pitti> (unless you have a better ide)
<mpt> pitti, in that case, you won't need to do anything else to see the license, other than clicking that button
<mpt> Therefore, the button should not have an ellipsis
<pitti> ok, done
<asac> mpt: http://people.ubuntu.com/~asac/screenshots/plugin.alt.png ... can you tell me if its good enough just to have the radio buttons next to the plugin icon on top? or do i need to prefix it with "manage" or "Filter" or something?
<asac> (the dialog would be called "Manage Content Plugins" or something i guess)
<mpt> pitti, the driver description is missing its border -- it should have exactly the same border as the list does
<mpt> asac, window titles should always use Title Case
<asac> mpt: read what i wrote two lines above ;)
<mpt> ah :-)
<asac> mpt: i am mostly interested in the heading above the list ... just the plugin icon and then the radio thing?
<mpt> asac, what's the icon for?
<asac> or keep the word "Manage" or Filter or something
<asac> mpt: thats the official "plugin" icon used in firefox
<mpt> asac, yes, but what does it do in this window?
<asac> mpt: nothing. its just an eye candy
<mpt> asac, I suggest removing it then
<pitti> mpt: hm, the normal TextView widget doesn't seem to have one
<asac> mpt: atm i just want to know wehther the radio alone is enough ;)
<mpt> pitti, I think that's because it's sometimes used for the entire contents of a window, in which case it shouldn't have a border beyond what the window manager already provides
<pitti> mpt: maybe I shuold replace it with a GtkScrolledWindow container
<mpt> pitti, but as a result, GTK programmers very often forget to add the border when it's *not* the entire contents of a window
<mpt> It's quite unfortunate
<amitk> what would it take to get kerneloops into the default install?
<mpt> asac, I suggest "Show:", and putting that label to the left of the radio buttons rather than above them.
<asac> okay
<mpt> asac, also, radio button labels should always use sentence case. :-)
<mpt> (e.g. "Plug-ins in use", not "Plug-ins in Use")
<asac> and "All plugins" ?
<mpt> right
<asac> for me that always looks funny
<asac> but well :)
<pitti> mpt: main.glade updated on p.u.c.
<pitti> mpt: I removed the ellipsis from Enable... too, for the same reason
<asac> mpt: ok. and such a dialog would get a "Close" button ... not "Ok", right?
<mpt> pitti, well done :-)
<asac> (the changes apply instantly when you change the selection)
<mpt> asac, what dialog?
<asac> mpt: the dialog we are talking about?
<pitti> mpt: btw, in the actual code, the Enable button will get the usual icon (just like in current jockey), and Show License shuold get the info symbol; unfortunately that's not possible in glade-3
<pitti> mpt: do you think the enable button is too 'hidden'? shuold it be in the bottom button bar (where help and close is)?
<mpt> asac, this isn't a dialog. It's an ordinary window, like Firefox's Add-ons and Bookmarks/History windows.
<mpt> asac, so my next suggestion was going to be, remove all the padding between the edge of the list and the right, bottom, and left edges of the window. Like in a Nautilus window.
<asac> mpt: preferences -> Close button ... addons -> no button
<mpt> pitti, does that mean all the buttons will become the same height?
<asac> mpt: yes thats on my list
<asac> (padding)
<pitti> mpt: yes (if not through the icon, I'll make sure it happens in the code, but I suppose setting an icon will fix it already)
<pitti> I wish glade-3 would allow me to set a button icon with arbitrary text..
<mpt> asac, so the part at the top with the radio buttons in it should have padding, but the rest should not. Like Nautilus's Trash window.
 * asac never uses nautilus :-P
<asac> let me look
<asac> mpt: yes. i agree
<asac> mpt: the other thing i wondera bout is whether the rows should get a title?
<mpt> asac, however, because each item in the list can potentially contain an option menu, each item should have the normal padding.
<asac> like "Content type" "Plugin"
<mpt> Which means the rows will be quite a bit taller than they are now.
<mpt> asac, good question, I was wondering about that
<mpt> I'm not sure
<asac> mpt: i dont understand the "normal" padding for the items
<asac> you say that i should add an extra padding for the items?
<asac> like 0.25em?
<pitti> mpt: updated again, I fixed the expand/fill attributes, so that resizing the dialog DTRT
<mpt> asac, as in 0.5em between the edges of the option menu and the edges of the cell that it's inside.
<asac> ok ill try. what i ll do is ensrue that every element has a proper class so we can tweak all this through CSS
<mpt> pitti, this is looking much better
<asac> thanks for your input so far
<pitti> mpt: so clicking on Enable would immediately start installation, instead of giving you the confirmation dialog with the detailled description
<mpt> asac, I think column headers might well help some people understand which is the plug-in and which is the media type
<asac> mpt: oh. still: close or no button to close? (preferences window has a button, while addons doesnt have one)
<mpt> asac, especially since being a window devoted to plug-ins, people might expect that to be the first textual column
<asac> mpt: right.
<mpt> asac, no extra button, like the Add-ons window
<asac> ok
 * mpt starts to wish Glade had a "Revert" menu item
<asac> mpt: are you using glade 3?
<mpt> yep
<pitti> mpt: there's undo in glade-3?
<mpt> pitti, I mean to reload the file after I've downloaded each new revision of yours :-)
<mpt> pitti, when you click "Enable", do you need to do anything else to enable the driver?
<pitti> mpt: so if you are generally satisfied with which kind of information is displayed and the new installation workflow, I can change the code accordingly (moving buttons around is cheap afterwards, changing workflow less so)
<pitti> mpt: no, that's why I removed the ellipsis
<mpt> ah, so you did
<pitti> mpt: well... it is conceivable that in the future particular handlers ask for more information, but I try to avoid that as much as possible
<mpt> ok
<pitti> mpt: and in that case I can still dynamically add the elipsis to the button
<pitti> but in general you'll immediately get the progress window and install starts
<mpt> nice
<mpt> pitti, so yes, the interaction looks fine, though there are still a few things to fix in the layout
<mpt> and the text
<pitti> should the two label values be left-aligned?
<mpt> How easy is it to change the text for each driver?
<pitti> i.e . support status and license value
<pitti> mpt: it's a matter of changing it in the particular handler .py file, or in the online driver db
<mpt> thanks asac
<pitti> but since it gets i18n'ed, the cost is not negligible, since it would break translations
<mpt> true, that's always a problem
<pitti> but all the nvidia specifics in that glade are just random examples, they won't be in the glade, of course
<pitti> but having them there makes reviewing easier, I thought
<mpt> pitti, I'm not sure about the alignment, that partly depends on the rest of the layout.
<pitti> ATM the bottom half layout is pretty messy
<mpt> yes
<pitti> seems I really lack the talent to come up with something that looks friendly and standardized
<mpt> afaict there are three issues remaining: (1) uses the word "enable" (an easy wording fix), (2) the "Enable" button looks very closely related to the support status when it isn't, and (3) there are three different button widths in quick succession.
<pitti> mpt: what would you recommend instead of "Enable"? It's not install/uninstall, as you can have drivers which are installed, but disabled (i. e. not used)
<mpt> Tentatively, "Use This Driver" and "Stop Using This Driver"
<mpt> the latter's a little long
<pitti> even the former is very long if I consider the German translation
<mpt> so use whatever's the German for "Enable" instead then :-P
<pitti> heh, yes, of course translators could do that :)
<mpt> pitti, when would be the best time to tackle the layout? Now, or sometime later?
<pitti> mpt: (3) I could fix the top two buttons by placing them into a vbox and using fill/expand, I suppose; but that wouldn't apply to the "close" button which is part of the standard dialog button bar
<asac> German for Enable ... ist "enablen" ;)
<pitti> asac: *cough*
<pitti> asac: gedowngeloadet :)
<asac> oh ... better "enaebeln" ;)
<asac> hmmm
<asac> "eneibeln" ;)
<pitti> mpt: whenever you have time, I'm good with "now" (well, meeting in 20)
<asac> pitti: we should finally stop being so picky about translations :)
<pitti> asac: I have "Aktivieren"
<mpt> pitti, yeah, I need to send in my activity report. ;-) How about after the meeting?
<pitti> mpt: great; since it's only layout, I can start coding already
<asac> pitti: which means: "activate" ;)
<pitti> en_STARTREK: "Engage!"
<mpt> Make it .so
<ogra> asac, "enaebeln" is so not german ... Ã¤nÃ¤bln is ...
<pitti> I don't know you guys
<ogra> it has the right umlauts at least
<asac> ogra: i feel like an outsider in germany ... i refuse to type umlauts
 * ogra giggles evlish
<ogra> me too usually :)
<asac> good
<cjwatson> asac: so is libmbca dynamically loaded by network-manager?
<cjwatson> I was trying to work out how a UI could be a shared library
<pitti> asac: I think "Uuuuuuuuuund... ACTION!" is cool, too
<asac> cjwatson: its a wizard library
<asac> cjwatson: nm-applet will be patched to use that
<cjwatson> right, ok
<asac> (but i cant until we have that lib)
<cjwatson> I've accepted it and the database; they should build shortly
<asac> thanks
<asac> pitti: "gib Gas!"
<asac> ;)
<asac> or "Ab dafÃ¼r!"
<mok0> I am building Google's new browser Chromium. Anyone wants to join in the fun of building a package?
<cpufreak> gnarly
<mpt> mok0, does it do anything more than run the test suite?
<mok0> mpt: don't know yet
<mpt> (or crash)
<asac_> reconect
<mok0> mpt: this is no ordinary run-of-the mill build. The tarball is 438 Mb
<mok0> mpt: alone the debian/copyright will be ~1Mb I expect :-P
<asac_> jcastro: would you mind to setup a "chromium" project as a top level project where googlechrome and V8 and other components live in?
<mpt> mok0, wow, deja vu
<mpt> "The Mozilla source runs 40 megabytes and 1 million-plus lines of intermingled C and C++ covering Windows and Mac and nearly every flavor of Unix, so diving into it is not an undertaking for those with weak hearts or slow computers. To build and use the free Mozilla source code for the free Mozilla browser, you will probably need to invest several thousand dollars in a new computer." -- Salon, 1998
<asac_> jcastro: as subproject? e.g. we need more syncs (like for V8 et al)
<mok0> Unfortunately, there is another package called "chromium" -- it's a game of some sorts
<asac_> mok0: well. i want a launchpad project "chromium" ... not sure if that package already has a project ;)
<mpt> mok0, exactly the same issue as epiphany vs. epiphany-browser
<mok0> asac: Yeah good idea
<dholbach> asac_: https://launchpad.net/googlechrome
<asac_> dholbach: thast just the "chrome" subproject
<_MMA_> mok0: Just a note: "ï»¿ajmitch: 'Although many Chromium submodules build under Linux and a few unit tests pass, all that runs is a command-line "all tests pass" executable.'"
<dholbach> ah ok
<siretart> hey, chromium is a really fun game :)
<mok0> Well Googles page on building it is scarce of info
<ogra> seb128, my evo lost mails ... :(  (just found that by searching for one today)
<seb128> how?
<ogra> no idea
<seb128> there was a mbox corruption briefly during the 2.23.90 time
<seb128> is that new mails?
<ogra> https://lists.ubuntu.com/archives/edubuntu-users/2008-August/004331.html
<ogra> that one is missing
<ogra> i know i read it when it came in
<ogra> and today searchiv for it only revealed the one reply it had
<ogra> *searching
<seb128> probably got hit during the 1 day where the buggy version was available
<ogra> not sure if there were more lost, but i'm sure i had that one
<pwnguin> mok0: most of the chrome tarball is binary data
<mok0> pwnguin: yikes
<pwnguin> theres like two builds in there, and a ton of test data
<ogra> seb128, well, i'll keep an eye on it ... cant fix or change it anyway i guess
<asac_> pwnguin: they ship all .dlls they need
<pwnguin> asac_: if you ship your own .dlls, are they really shared?
<asac_> pwnguin: most likely not. but i think thats a common thing on windows
<asac_> i heard about "dll-hell" ;)
<pwnguin> dll hell was a versioning thing
<pwnguin> (is?)
<asac_> but isnt that the reason why everyone ships duplicate .dlls?
<mok0> Hmm. Got ld error
<pwnguin> mok0: chrome's source management tools kept crashing on me =(
<mok0> pwnguin: Seemed to work for me
<mok0> pwnguin: but the build doesn't like the default libnss3.so
<asac_> mok0: default == the copy they are shipping or the intrepid one?
<pwnguin> i wound up just building the tarball without updating
<mok0> asac: In fact... the hardy one
<asac> mok0: doesnt chromium ship their "own" nss copy?
<ogra> asac, which version of xulrunner shall i test ?
<asac> mok0: maybe its a versioning mismatch there?
<ogra> 1.9.0.2+build3+nobinonly-0ubuntu1 is installed
<asac> ogra: the last 1.9.0.1+build available
<ogra> ok
<asac> mok0: do you used the "repo_tools" ... or did you just get a full checkout of the chromium sources?
<mok0> I did a full checkout
<asac> mok0: so how is it failing?
<mok0> http://pastebin.com/f480b3e30
<asac> mok0: you dont have the build depends installed as it seems
<asac> mok0: install libnss3-dev
<asac> hmm incompatible
<ogra> asac, _1.9.0.1+build1+nobinonly-0ubuntu0.8.04.3 ??
<mok0> asac: I have it
<ogra> (8.04.3 seems a bit strange)
<asac> mok0: what is getting linked there?
<asac> ogra: yes
<ogra> ok
<asac> ogra: what is strange about that? its the third respin of 0ubuntu8.04.*
<asac> err 0.8.04.* ;)
 * ogra is running 8.10 :P
<mok0> asac: Ydrk can't say my damn terminator session just crashed :-(
<soren> 7win 19
<soren> Garh...
<asac> ogra: hmm. are you sure you are looking at intrepid?
<asac> ogra: there should be a 1.9.0.1 build for intrepid
<ogra> i'm looking at archive.ubuntu.com
<ogra> there is no other 1.9.0.1
<asac> ogra: nah. look at launchpad :)
<asac> ogra: only launchpad has history ;)
<ogra> oh, right
<asac> ogra: https://edge.launchpad.net/ubuntu/+source/xulrunner-1.9/1.9.0.1+build1+nobinonly-0ubuntu1
<asac> for your convenience
<ogra> thanks
<asac> ogra: most likely you need xulrunner-1.9 and xulrunner-1.9-gnome-support binaries
<mok0> asac: trying again...
<mok0> asac: but it seems there are special libnss3 packages for firefox and thunderbird
<asac> mok0: that was long ago
<asac> like in feisty
<mok0> This is where it fails: Linking Hammer/base/base_unittests ...
<asac> mok0: that doesnt tell me "what" pieces it tries to link together
<pwnguin> mok0: check the bottom of the build manual page
<mok0> pwnguin: you mean the bison stuff?
<pwnguin> i thought it sounded similar, but i guess not
<ogra> asac, yep, that fixes it
<ogra> the file type selector shows "all files" in the bottom right dropdown now ... it didnt show anything with the newer version and listed only dirs
<mok0> pwnguin: What is strange is that they say: "On Ubuntu 8, you can fetch all of the above as follows: ...... apt-get install .... libnss3-dev"
<pwnguin> mok0: you might ask in #chromium-linux
<mok0> pwnguin: good idea
<pwnguin> knock some sense into 'em ;)
<mok0> heh
<pwnguin> ubuntu 8
<pwnguin> wtf
<mok0> pwnguin: well that can't be used for packages
<mterry> mvo: Is there a way to 'queue up' a package installation (not an update) so that next time the user is online, update-manager would prompt to install?
<tkamppeter> seb128, do you know balachmar? He wants to work on bug 258421?
<ubottu> Launchpad bug 258421 in gtk+2.0 "GTK apps should send PDF to CUPS when printing" [Medium,New] https://launchpad.net/bugs/258421
<seb128> no I don't know him and dunno
<persia> tkamppeter: He's new: just got excited by this developerweek.
<tkamppeter> seb128, did you already have a look at bug 258421?
<seb128> yes quickly before my holidays
<seb128> but it's not obvious why you commented code to me
<tkamppeter> persia, thank you, he talked to me yesterday here on IRC, but when I saw it he had already left.
<persia> mterry: Not realy.  One could mark something to be installed by apt, so next time the user performed an upgrade it would install.
<mterry> persia: But only if they did it from command line?
<mterry> persia: How evil would it be to create some fake package with a version 0?  7th circle or merely 2nd?
<persia> mterry: No.  You can do about anything you want with python-apt: just don't actually perform the install.
<tkamppeter> seb128, what do you mean with "commented code to me"?
<persia> mterry: Well, version 0 actually works, but it tends to break the archive tools: my experience with 0.0~foo is that the archive-admins won't touch the package, making it non-ideal.
<tkamppeter> seb128, do you mean that I commented out some code? This code does not make sense with PDF.
<mterry> persia: I'm not sure I follow.  I can mark something to be installed by apt.  OK.  How does user see that?  Does update-manager prompt?
<mterry> persia: Re: version 0, I'm not talking about in a repo, but locally create/install a version 0 deb on the fly, so when update-manager runs, it prompts to download
<seb128> tkamppeter: I just looked at the patch, will need to look at the code to have some context
<persia> mterry: You *really* don't want to do that.
<mterry> persia: (this is for if a user picks a language that isn't available at install time.  I'd like update-manager to prompt to download language packs)
 * persia digs up the python-apt docs, having filed the information in deep storage
<mrxmike> why is there no package for winexe in the repos!? > http://eol.ovh.org/winexe/
<mrxmike> its a really handy tool!!
<persia> mterry: I think what you want is to call markedInstall = true for a given package, but not commit.  From my understanding this should cause the apt-cache to update and indicate the package is to be installed.  Next time there is a commit of the apt-cache, it would install the package (for instance, in update-manager).  You'd want to test to see what that means for UI though.
<persia> If you know you have access to a repo, you can commit immediately, and perform the install.
<mterry> persia: OK.  Thanks for the pointer!  I'll dig/test
<mvo> mterry: sorry, there is currently no way to make this kind of persistant marks for install in plain apt
<jcastro> asac: what about chromium-browser for the big group? same solution people do for epiphany.
<mvo> mterry: you can do stuff with "dpkg --set-selections" and then "apt-get dselect-upgrade"
<persia> mvo: Marking for install won't carry over?
 * ogra wonders if a simple dpkg --set-selections couldnt do that
<mvo> persia: no, its not permanent
<persia> ogra: It can, but that wouldn't be Python :)
<ogra> ah, beats me
<asac> jcastro: i dont see that we need to choose a different name unless chromium is already registered
<persia> mvo: Why not?
<mterry> mvo: It would be nice for above use case (prompt to download something that wasn't available at install time).  I tried -set-selections, but update-manager doesn't seem to care
<jcastro> asac: ah ok, fair enough, I'm on it. :D
<asac> jcastro: and its not really said that thats all "-browser" in the future. maybe chromium-project if we need a new name
<mvo> mterry: we could teach update-manager to do something similar as dselect-upgrade, that would actually be useful for more things
<mrxmike> anyon?
<ogra> mterry, you need the dselect-upgrade call as well
<mterry> ogra: Ah, I probably missed that
<asac> jcastro: cool. and register its subprojects too :) ... like V8, breakpad ;)
<mvo> mterry: right, let me check the code to see how much added work it is/will be
 * ogra gives up ... mvo is to speedy :P
<jcastro> asac: it is already (the game), so I'm going to go with -browser
<jcastro> asac: right
<asac> jcastro: please use -project
<mvo> persia: good question :) it was never implemented in libapt I guess
<jcastro> ok
<asac> chrome is the browser
<mvo> it would be cool if it would show up as "Previsously suggested installs" or something like that
<mrxmike> i feel ignored :(
<persia> mterry: You've found an enhancement bug :)  libapt ought set selections permanently, as with dpkg --set-selection.s.
<asac> mvo: is it a bug that when you run apt-get upgrade the recommends get marked as seen? e.g. a subsequent dist-upgrade wont install them?
<persia> mrxmike: I'm looking up a wiki page for you, but haven't found it yet.
<jcastro> asac: should we have a new team for all this or just use mozilla team?
<mrxmike> persia: ok, im patient ;)
<ogra> mrxmike, https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<persia> Yes.  That's it :)
<ogra> :)
<asac> jcastro: i dont mind. i would certainly hand over the ownership when such a team is founded
<mrxmike> ok im after it, thanks guys
<asac> jcastro: so we can go like we did for googlechrome for now
<mvo> asac: yes, that sounds like one, but its not trivial to fix :/
<ogra> mrxmike, btw #ubuntu-motu is better for such stuff
<asac> mvo: ok. thanks for confirming. so in the end recommends should be more strong about enforcing installs
 * mok0 wonders if chromium could be built with our ubuntu version of Webkit
<pwnguin> mok0: given that they appear to want to track webkit head, probably
<pwnguin> it'd be a divergence from upstream though
<mok0> pwnguin: agree
<asac> wow. scons python part is _really_ CPU hungry
<mok0> So, what's the status while I've been away, has a LP project been set up for GC??
<asac> mok0: jcastro is on it. the imports will take a while for sure
<mok0> asac: great!
<broonie> asoc: There are some options you can twiddle if it's an issue
<asac> broonie: which option?
<asac> i am just running scons Hammer ;)
<mok0> https://edge.launchpad.net/googlechrome
<asac> mok0: yes. thats just "chrome" tthough
<broonie> asac: Decider() in SConscript is one of them.
<asac> mok0: we need more
<mok0> Actually, it's not called Google Chrome, but Google Chromium
<pwnguin> you sure?
<asac> mok0: we create a chromium project now
<asac> mok0: which hosts the several pieces: chrome, V8, ...
<mok0> ah ok
<asac> mok0: the project is called "chromium" ... the browser "chrome"
<asac> thats my understanding at least
<asac> (guessing from how the svn is structured)
<pwnguin> so if i were to rebrand firefox as "chrome"
<Darklock> ah, so that is why the debian games team wants to change chromium to chromium-bsu :->
<asac> they want?
<asac> broonie: since you probably know scons a bit ... how can i tell scons to show me the command line the is run for compiling, linking and such`
<asac> ?
<broonie> asac: I don't remember off the top of my head, sorry. Setting CC or LD to echo would work :/
<mok0> Could it be built with ubuntu's scons instead of the local version?
<asac> mok0: for me it works
<asac> mok0: at least i end in the same nss error that you ;)
<mok0> asac hehe
<mok0> I filed bug 264713
<ubottu> Launchpad bug 264713 in ia32-libs "Please add libnss3" [Wishlist,New] https://launchpad.net/bugs/264713
<pwnguin> these build instructions from google are a bit depressing
<mok0> pwnguin: you mean the 64 bit stuff?
<pwnguin> i mean the part where they have a version of scons in revision control?
<mok0> pwnguin: yeah, that's not the way we like it
<mok0> pwnguin: apparently, building with ubuntu's scons works
<pwnguin> psh
<mok0> pwnguin: we should find out which parts to pull out that are relevant for linux, and repackage that in the orig.tar.gz
<pwnguin> i keep seeing references to cygwin on the windows side, and thus far ive tried to ignore whatever insanity that way lies
<mvo> mterry: please give http://people.ubuntu.com/~mvo/tmp/update-manager-set-selections.diff a try
<mterry> mvo: Will do, you speed demon, you
<asac> mok0: are you on 64bit?
<ScottK> If there's an archive-admin in the house, I'd really appreciate it if they would accept the subversion 1.5 backport in Hardy Backports.  I lot of people are wanting it due to archive format changes.
<ScottK> It's Bug #247514
<ubottu> Launchpad bug 247514 in hardy-backports "Please backport subversion subversion_1.5.1dfsg1-1ubuntu2 from intrepid" [Wishlist,In progress] https://launchpad.net/bugs/247514
<mterry> mvo: It shows up, but isn't checked by default.
<Hobbsee> ScottK: looks done already.
<mvo> mterry: ok, that is (for now) intentional
<mok0> asac: yes
<asac> mok0: thats the problem then
<asac> mok0: try 32-bit
<asac> mok0: everything is explicitly built with -m32 ... so the link against nss will fail
<asac> and from what i can see the V8 engine isnt ready yet for 64-bit
<mok0> asac: I am trying the guide on: http://groups.google.com/group/chromium-dev/browse_thread/thread/eeb1b3343b4cea6b?fwc=1
<mterry> mvo: Oh.  Why?
<asac> mok0: you can do that yes.
<asac> mok0: but its hackish
<mok0> asac: sure is. I filed bug 264713
<ubottu> Launchpad bug 264713 in ia32-libs "Please add libnss3" [Wishlist,New] https://launchpad.net/bugs/264713
<asac> we probably need to include nss and nspr in ia32-libs and then add kind of -dev package for 32bits
<mok0> :-)
<asac> mok0: right. but you also need a new -dev, or am i wrong?
<mok0> asac: yeah you do; in the guide you just make the symlinks manually
<asac> or a pkg-config nss3-32 ;)
<mvo> mterry: just to see if it works, if it gets stuff wrong, I don't wanted to mark it for install by default (as it may be wrong)
<asac> mok0: let me know how far the build gets with those changes
<mok0> asac: right
<mterry> mvo: Fair.  Seems to work on my end.  If you end up satisfied with the result, please send me the final patch.  It would be useful for UNR (and eventually normal Ubuntu installer)
<mvo> mterry: UNR?
<mterry> mvo: Ubuntu Netbook Remix
<mvo> aha, cool
<mpt> pitti, what are the possible values of "Support status"?
<mok0> asac: there's another issue with the missing symlink /usr/lib32/libstdc++.so
<pwnguin> mok0: at some point, if everything you link to is 32bit, you're just building a 32bit binary
<mok0> pwnguin: I know
<mok0> pwnguin: wonder if it would build w/o the -m32 switch
<pwnguin> you've got a round hole but chrome is the square peg
<mok0> pwnguin: It's beginning to look like it...
<mok0> I now have had a couple of issues that are not in the posting
<pwnguin> even if it did all work and build, what then?
<mok0>    /usr/bin/ld: cannot find -lgcc
<mok0> pwnguin: then I get to run some unit tests :-D
<pwnguin> ok, as long as you know where you're going ;)
<mok0> pwnguin: it is still useful to get all the difficulties mapped out at this time
<mok0> it would be great if the browser could appear in time for ii
<pwnguin> what, you didn't like their listing?
<pwnguin> ii
<mok0> Intrepid Ibex...
<pwnguin> if i were you, I'd shoot for ubuntu+2
<mok0> Hah
<pwnguin> as an optimistic goal
<mok0> I am probably getting all psyked up here
<seb128> mdz: hum, debian/patches/15_usplash.patch is still in the current gdm package I've here
<mpt> mok0, your enthusiasm is appreciated, having more browsers is a good thing
<mpt> but on Linux at least, Chromium isn't a browser yet :-)
<mok0> pwnguin: I guess the problem is that ubuntu doesn't really have a 32 dev environment for x86_64...
<mdz> seb128: oh! I accidentally downloaded 2.20.7-3 source when I wanted 2.20.7-0ubuntu5
<pwnguin> ive willfully neglected x86_64
<seb128> mdz: ah ;-)
<mdz> seb128: there must be something else wrong then, it still doesn't start usplash on shutdown
<pwnguin> mok0: does multiarch work yet?
<mok0> pwnguin: multiarch?
<pwnguin> sounds like no
<mok0> pwnguin: don't know what it is
<seb128> mdz: right, I noticed that too but I'm not sure what is wrong and if that's due to gdm or usplash
<mdz> seb128: does it work for you?
<seb128> mdz: no
<mdz> seb128: sorry for the confusion
<seb128> no problem
<mdz> seb128: I think at least some of these bugs are dupes but it is hard to tell
<seb128> right, it would require some investigation
<seb128> too many bugs to look at everything in details
<mdz> seb128: I have a fresh intrepid kvm, I'll have a look
<mok0> mpt: I think GC is going to work great on Linux, given the multiprocess design
<seb128> mdz: maybe try to install the hardy gdm and see if that makes a difference
<pwnguin> mok0: im not sold on multiprocess
<mok0> mpt: and with multicore machines it will really rock
<mok0> pwnguin: why?
<pwnguin> if threads are also called light weight processes, this means regular processes are "heavy"
<mok0> pwnguin: I'm not really sold on threads :-)
<mdz> seb128: I'll also try to find out why usplash pulsates on bot
<mdz> boot
<cjwatson> it might be better to examine the actual implementation rather than the name
<mdz> it needs some love
<mpt> pitti?
<mok0> pwnguin: Linux is really quick at creating processes
<mterry> mvo: With your patch, after I did an update (but didn't install the "Previous Selected" package), further runs of update-manager don't show the package anymore
<mok0> pwnguin: especially after 2.6
<mpt> ah, he's out
<mterry> mvo: It prints it on the command line, but not in the UI
<mvo> mterry: oh, interessting. let me check
<pwnguin> mok0: there's cache considerations as well, and memory mapping costs
<mok0> Hmm. Any suggestions for the missing -lgcc?? I have the feeling it's the last one needed
<mok0> pwnguin: If you created 1000's of processes, it might be noticable, but not with something O(10) like a browser
<mok0> pwnguin: In my winxp virtual machine, tab creating is instantaneous
<mok0> pwnguin: ... and linux is faster at creating a process than winxp
<pwnguin> exactly how many tabs do you open, and how often?
<cjwatson> the "lightweight processes" name comes from OSes where creating processes has not been so ridiculously optimised
<mok0> pwnguin: once a minute?
<cjwatson> pwnguin: you're the one who brought up processes being heavyweight ...
<jdstrand> pitti: hi!
<pwnguin> theres more to life than being born. similarly, theres more to processes than creation
<seb128> kees: $ find . -name *.build | xargs grep "warning: format not" | wc -l
<seb128> 916
<seb128> kees: that's my packaging directory
<mok0> Threads make sense if you have a different type of process going on that you want to escape from, say a download window.
<jdstrand> pitti: I recently saw that clamav was promoted to main, but was hoping that an enforcing apparmor would be a prerequisite for its inclusion
<pwnguin> mok0: actually, processes make sense there, to me
<pwnguin> the benefit of threads is shared address space
<mok0> For GC, the processes for each tab are identical; then there's a process that manages it all
<cjwatson> pwnguin: I think (a) you should hold off on serious comment until you've benchmarked, otherwise it's just blowing smoke (b) you may well find that the other benefits of memory separation between tabs outweigh some minor performance disadvantages
<jdstrand> pitti: I talked with ScottK about it some, but this didn't happen before promotion.
<mok0> cjwatson: easy, we are having a friendly chat here...
<cjwatson> I don't think it's unfriendly to say that serious discussion of performance should be based on genuine data
<cjwatson> that's an axiom of performance engineering
<mok0> kk
<jdstrand> pitti: my plan is to provide a debdiff for it, then ScottK will check it with amavis-new, and then a FFe for it
<mok0> Anyway, I am impressed with GC
<jdstrand> pitti: I think it's really important considering its history and the nature of what it does
<mok0> But I need to get the -lgcc problem solved
<pwnguin> cjwatson: before benchmarking, you should decide what's important to measure.
<cjwatson> pwnguin: sure, but when faced with a case where somebody apparently has done the benchmarking, it makes sense to find out more about what they did rather than ignoring it
<mok0> cjwatson: interestingly, when looking at the gossip of the Internet, people come to wildly different results comparing GC to IE8
<pwnguin> has someone done the benchmarking?
<cjwatson> Google, internally
<cjwatson> (that much is fairly clear)
<mok0> pwnguin: I've seen several referenced at digg
<pwnguin> i didnt get that impression
<pwnguin> ive seen some benchmarks of v8
<mok0> pwnguin: I think Google wants to do STUFF with javascript...
<iamfuzz> slangasek, ping
<mok0> pwnguin: so they need a really fast engine
<jdstrand> pitti: also, it was brought to my attention that dbgsym packages are not created when going through -security in dak. has asac mentioned this to you? (this was noticed with the recent ff et al updates)
<iamfuzz> pitti, or ping
<pwnguin> mok0: and if they test v8 standalone, how does that reflect on the thread versus process choice?
<mok0> pwnguin: don't knpw
<cjwatson> of course, the other major axiom of performance engineering is that correctness is more importance than performance
<pwnguin> i tell students that, but deep down i know it's not true
<cjwatson> Google may well simply have decided that correctness is unlikely to be achievable with threads when other people's code is concerned; I don't know many people who've read the POSIX threads spec who'd disagree :)
<mok0> cjwatson: apparently, they've set up an automatic rendering system based on their cache of the internet
<mok0> cjwatson: Given IE8 is also process based, it seems MS has come to the same conclusion
<pwnguin> theres tons of research on bounding optimization problems while still terminating in our lifetimes
<mvo> mterry: hm, strnage. that seems to work for me, what is the output of "apt-cache policy pkgname" for that pkgname you put into --set-selections?
 * mok0 brain panic... rebooting
<pwnguin> from what i can tell, google's decided that flash tanking a tab rather than a browser is worth the penalties in both CPU and RAM
<pwnguin> I'm inclined to agree
<cjwatson> they also included a bunch of stuff about fragmentation in their announcement though; I don't think the RAM penalties are as obvious as they seem in a naive analysis
<pwnguin> that fragmentation stuff was bogus
<ion_> pwnguin: AFAIU, the tab is actually a separate process from the plugins running in it.
<mok0> What is libgcc_s ??
<mok0> ls
<mterry> mvo: http://pastebin.ubuntu.com/43371/
<cjwatson> pwnguin: that's a very bold declaration given that mozilla developers have attributed memory problems at least partially to the same cause
<kees> seb128: yup, there are a lot of warnings to dig through -- not all are security issues, but they're all bugs.
<kees> seb128: and in many ways, there's a reason I only set that to a warning.  :P
<seb128> kees: right, just giving you some datas before you consider settings that as an error ;-)
<pwnguin> cjwatson: external fragmentation is a misfeature of conservative GC, but from what I've read, none of the major browsers use it for javascript
<mok0> cjwatson: you mean, that the apparent memory leaks was in fact resulting from fragmentation (in mozilla)?
<cjwatson> pwnguin: I don't think I mentioned JavaScript
<cjwatson> http://blog.pavlov.net/2007/11/10/memory-fragmentation/ for example
<kees> seb128: agreed :)
<seb128> good ;-)
<seb128> I've to go, see you later
<pwnguin> cjwatson: i'm pretty sure the comic mentioned how their javascript engine was fast because of incremental gc
<mok0> pwnguin: I don't think it was only that
<cjwatson> pwnguin: javascript issues are separate from the benefits of separate processes for avoiding fragmentation
<mok0> pwnguin: it is also using a JIT compilation
<pwnguin> arg
<pwnguin> how's this for ironic? http://www.google.com/googlebooks/chrome/ doesn't work right in chrome
<mok0> ha
 * mok0 boots up his winxp VM to test this assertion :-)
<asac> the mozilla JS engine also gets JIT this round
<asac> i think its not yet enabled by default in the latest 3.1 alpha, but you can enable it using a build flag afair
<pwnguin> ok, well on rereading that fragmentation thing, it's kind of a bad argument that I misread. i thought it was talking about javascript, but it's about the general C++ problem
<pwnguin> personally, i think processes is a bad solution, but if you need them anyways to isolate failure, i guess it's a neat win
<mdz> cjwatson: bug 255008 seems to have regressed :-(
<ubottu> Launchpad bug 255008 in xorg-server "Up arrow key mapped to Print [screen]" [High,Fix released] https://launchpad.net/bugs/255008
<mok0> pwnguin: I don't see anything wrong with that comic...
<mdz> slangasek: ^^
<mpt> hi pitti
<pitti> hi mpt
<mpt> pitti, what are the possible values for "Support status"?
<pitti> mpt: ATM I have
<pitti> Tested by the %s developers
<pitti> Third party driver, not tested by %s developers
<pitti> Third party driver, tested by %s developers
<ScottK> Hobbsee: I'd just uploaded it then, it may not have been there yet.  I have waiting for approval, but no indication it was accepted.
<pitti> (wording improvements appreciated)
<pitti> mpt: I want to differ between Ubuntu supplied drivers, ubuntu certified third-party drivers, and community drivers without any stamp on them
<cjwatson> mdz: in kvm, or outside?
<mpt> pitti, ok, next question: What are the possible values for "License"?
<cjwatson> pwnguin: it's hardly a C++ problem
<mdz> cjwatson: I tested in kvm, but a submitter of a dupe doesn't mention it being in kvm
<pitti> mpt: "Free" and "Proprietary"; for the latter I enable the License button if the driver has a license text associated with it (as for e. g. the ones in openprinting.org)
<mpt> pitti, I didn't know Free drivers showed up in this window at all
<pitti> mpt: they are supposed to, yes
<pwnguin> cjwatson: sure. the same problem can happen with malloc as it can with new ;)
<mdz> cjwatson: and only when I forget the -k switch, argh
<pitti> mpt: and in fact, with the recent addition of looking for drivers on openprinting.org, that actually works, too
<mpt> neat
<mpt> pitti, when a third-party driver has not been tested by the %s developers, is it always because it's proprietary? Or are there other reasons?
<pitti> mpt: it's not tied to the license
<pitti> mpt: if we have a driver in the ubuntu repo, it is the first case
<pitti> mpt: if the driver is from openprinting.org, it is the third
<mpt> ahhhh
<pitti> mpt: erm, second case, I mean
<mpt> So an openprinting.org driver might be Free, but not reviewed
<pitti> mpt: and if our QA tests and blesses it, we can put a stamp on it and set it to the third case
<pitti> mpt: exactly
<pitti> mpt: we don't have a vehicle to bless drivers from openprinting.org, BTW, but we will with the upcoming online distro driver db
<pitti> (nothing to worry about for intrepid, so we just have the first two strings for now)
<mpt> I'm thinking of putting the review status into the description pane, similar to the maintenance status in Add/Remove Programs and Synaptic
<pitti> mpt: it could also be a driver which a community member ships in a PPA
<mpt> and wondering whether it would be appropriate to put the license info in there too
<mpt> that would make it less visible
<mpt> so more awkward for someone who really wants to have only Free drivers
<pitti> mpt: entirely doable, of course, but I'd like to put an emphasis on at least the support status
<pitti> mpt: btw, jockey has a mode to only present restricted or only free drivers
<pitti> but not switchable in the UI yet, just a CLI argument
<mpt> hm
<pitti> mpt: they could become the first two lines in the description panel, but that wouldn't save a lot of space and might be more difficult to read?
<mpt> pitti, I was thinking at the end, like with the maintenance status
<pitti> mpt: hm, it might get scrolled off the visible text part
<mpt> exactly
<mpt> so if it's important stuff, it shouldn't be at the bottom like that
<dholbach> Ubuntu Developer Week Sessions start now: #ubuntu-classroom
<mpt> the question is how important it is
<mpt> pitti, where a driver has been reviewed by Ubuntu developers, why would someone care whether it's an Ubuntu driver or a third-party one?
<pitti> mpt: they probably wouldn't, right
<pitti> mpt: so maybe we could drop the "Third party driver" part
 * pitti is dragged to dinner, bbl
<pitti> mpt: I'll catch up here later
<mpt> ok, thanks for your answers :-)
<pitti> mpt: thanks muchly for your input
<IntuitiveNipple> I've just added sys file-system support to qemu/kvm, but to make it accessible to users it will need a udev group ownership set on /dev/bus/usb/* devices. I was wondering if "plugdev" would be an appropriate group, or create a new one? I don't think kvm/qemu should have to run as root to access USB devices.
<anilg> is this the right place for an aptitude package question
<anilg> a build issue.
<LaserJock> what package(s) would be responsible for resume/suspend?
<azeem> uh-oh :)
<mpt> LaserJock, my almost-entirely-uninformed guess would be acpi-support
<LaserJock> suspend/resume stopped working for me (requires hard reboot)
<IntuitiveNipple> LaserJock: pm-utils ?
<LaserJock> initially I thought maybe it was .26 -> .27 kernel issue but I reboot with with .26 and got the same thing
<IntuitiveNipple> Laserjock: Do you have the uvcvideo module set to be unloaded on suspend? That's a well-known culprit :)
<cjwatson> pitti: tested by the %s developers> you know that may be a translation problem?
<LaserJock> IntuitiveNipple: how would I know?
<LaserJock> the screen goes blank and the keyboard no longer responds, but it seems like it's still running (I see occasional hard drive LED flashes)
<IntuitiveNipple> LaserJock: check /etc/default/acpi-support for  MODULES="uvcvideo" and similar
<LaserJock> IntuitiveNipple: MODULES is empty
<IntuitiveNipple> I've also found recently one of the USB drivers hangs things, so I add that too (commentary says USB drivers are unloaded, but they aren't any longer)
<cjwatson> pitti: in French, something like "par les developpers d'Ubuntu" (or whatever the word for developers is) vs. "par les developpers de Fedora" ... at least potentially, not sure if French translators would actually translate it that way
<IntuitiveNipple> LaserJock: does the PC have uvcvideo loaded ? If so, add it to that setting and it'll be unloaded on suspend
<cjwatson> pitti: you'll also need to take into account cases where the word "Ubuntu" is translated
<LaserJock> IntuitiveNipple: lsmod says ucvideo is loaded, I'll give it a try
<IntuitiveNipple> Do we have a 'recommended' group for giving VMs access to system services?
<LaserJock> IntuitiveNipple: yeah, that didn't help :)
<IntuitiveNipple> LaserJock: Possibly the USB module I mentioned... let me dig out which one it is
<IntuitiveNipple> LaserJock: I *think* it was "ehci_hcd" or "hci_usb", but I'd have to trawl to find it.
<jdong> those hurt a lot more to unload :)
<IntuitiveNipple> I only noticed it recently with a Hardy issue.
<ogra> LaserJock, /etc/default/acpi-support isnt used since hardy anymore
<LaserJock> don't tell me I have to edit some HAL .fdi file :-)
<ogra> LaserJock, you want /etc/pm/config.d ... create a file in there (i.e. "default") and put in: SUSPEND_MODULES="uvcvideo"
<ogra> that would unload uvcvideo on suspend and reload it on resume
<IntuitiveNipple> ogra: Some systems do have it, especially those that upgraded. Best thing is to check if the /etc/rc2.d/S99acpi-support symlink is there
<ogra> that would be a massive bug then
<ogra> there should have been a transition from acpi-support to pm-utils
<IntuitiveNipple> Laserjock indicated that the /etc/default/acpi-support file was present so the package appears to be installed
<ogra> (but i dont maintain powermanagement stuff anymore luckily ... so i dont know if the transition went properly)
<ogra> sure
<ogra> but that doesnt mean its used
<IntuitiveNipple> indeed, hence the rc2.d question. Thinking about it, he didn't say what release he's using :)
<LaserJock> hmm, same
<LaserJock> ogra: do you have to restart anything after making a file in /etc/pm/config.d/ ?
<kees> dholbach: thank you again for harvest.  made finding fedora's un-upstreamed patches for dvd+rw-tools a snap.  :)
<IntuitiveNipple> I have the pm-utils settings, with /etc/pm/config.d/modules_unloads with the contents SUSPEND_MODULES="iwl3945 r5u870 uvcvideo ehci_hcd"
<dholbach> kees: gracias :)
<dholbach> kees: or.... "thanks for the flowers"
<ogra> LaserJock, no, pm-suspend will just use it
<pitti> cjwatson: tricky indeed; we have a similar case in the dialog title, too; thanks for pointing out
<pitti> jdong: known to me, and I mailed infinity about it the other day
<pitti> iamfuzz: hi
<kees> dholbach: hehe, you're welcome.  :)   actually, if I click on "mark reviewed", harvest falls over
<kees> dholbach: i.e. I'm here: http://daniel.holba.ch/harvest/handler.py?pkg=dvd+rw-tools  and I'm clicking the wctomb patch
<dholbach> kees: can you send a patch? .... bug report? :-)
<dholbach> kees: I'll dive into it probably tomorrow or next week, quite busy
<NCommander> kees, so I discovered a rather interesting pain in building a PIEd compiler due to circular dependencies on glibc, libgmp, and libgcc :-)
<kees> dholbach: sure
<dholbach> thanks kees
<kees> NCommander: heh
<NCommander> kees, I did make the right call though, GCC can't be built PIEd with your wrapper because of its bootstrapping methodology, you need to manually set the CFLAGS
<mdz> does anyone know if there's a bug filed about the intermittent usplash pulsating during boot?
<LaserJock> IntuitiveNipple: SUSPEND_MODULES="iwl3945 uvcvideo ehci_hcd" didn't work either
<kees> mdz: I thought that was an intentional change by pitti during the fsck
<IntuitiveNipple> LaserJock: There might be other modules responsible (check lsmod and guess!) or it might be that something else entirely is the cause. Might need to enable ACPI debugging
<mdz> kees: was it?  it doesn't look right
<mdz> and it happens even when no fsck is required
<LaserJock> IntuitiveNipple: darn, I was hoping for an easy fix
<mdz> pitti: is it true?
<IntuitiveNipple> LaserJock: suspend/resume is rarely easy!
<kees> mdz: I cannot confirm it was intentional, or that is is the fsck and it goes by very quickly, but that is what I suspect.
<IntuitiveNipple> mdz: do you have a moment to give some guidance on LP bug #156085 (sys fs for kvm/qemu etc.) ?
<ubottu> Launchpad bug 156085 in kvm "Could not open /proc/bus/usb/devices" [Medium,Confirmed] https://launchpad.net/bugs/156085
<mdz> IntuitiveNipple: how can I help?
<mdz> kees: confirmed, it calls splash_start_indefinite before fsck
<kees> mdz: okay, cool.
<IntuitiveNipple> mdz: In the bug you pointed to a patch at Novell, and I've taken that as a basis and added sys fs support on top of existing /proc/ and dev/ support. I just need some guidance on group ownership for the usb devices which are currently root:root since otherwise kvm/qemu will have to run as root. I looked at plugdev, but wondered about a new one for all VMs, maybe "vm" or "virtualmachines"
<mdz> IntuitiveNipple: pitti is the person to talk to about that; it's recently changed quite a bit
<IntuitiveNipple> mdz: Ok, thanks.
<IntuitiveNipple> pitti: over to you when you're free :)
<ogra> IntuitiveNipple, there is also a patch on bug 159189
<ubottu> Launchpad bug 159189 in usbutils "lsusb : Fix or remove -t option" [Low,Fix released] https://launchpad.net/bugs/159189
<ogra> that might give some hints
<IntuitiveNipple> ogra: Can't see anything about permissions in there.
<pitti> mdz, IntuitiveNipple: linux foundation conf call, can we talk later?
<pitti> IntuitiveNipple: in short, /dev/kvm uses the 'kvm' group; we didn't change that, kvm isn't PolicyKitified ATM
<ogra> IntuitiveNipple, no, but about switching from usbfs to sysfs
<pitti> IntuitiveNipple: anyway, will read backlog later
<IntuitiveNipple> pitti: thanks, yeah, shout me when you're free
<IntuitiveNipple> ogra: The support for sys fs is done, its just a case of correct permissions to allow non-root access to the USB devices in /dev/bus/usb/*/*
<ogra> ah, k
<IntuitiveNipple> ogra: I was just thinking whilst I'm at it, adopt a generic group that can be used for all VMs such as kvm, qemu, vbox, etc/
 * ogra doesnt ude vbox with usb support ... so i cant judge that ... 
<IntuitiveNipple> The biggest gripe currently is lack of decent USB support, and now it's coming through from upstream it would be good to support it as painlessly as possible
<ogra> and i only use vbox usually, so i cant judge the others ... soren would be the right person for general virtualization discussions i think
<IntuitiveNipple> yeah, good point. I'll email him
<slangasek> mdz: 255008> yes, I see that Jan Rathmann has appeared now - good, he had linked this bug from his ISO testing but I couldn't find him
<mdz> slangasek: my reproduction of it seems to have been bogus; it is actually the kvm/evdev issue I stumbled on
<mdz> slangasek: it's working OK for me on real hardware atm
<slangasek> iamfuzz: pong
<iamfuzz> sladen, got cprov helping me, thx
<slangasek> mdz: ok, thanks for the info
<Cycom> are bugfixes still taking place for 8.04?
<mdz> slangasek: I filed bug 264696 and bug 264767 as visual issues which should nonetheless be fixed before final
<ubottu> Launchpad bug 264696 in gnome-session "usplash is not started on shutdown/reboot" [Medium,Confirmed] https://launchpad.net/bugs/264696
<ubottu> Launchpad bug 264767 in sysvinit "usplash pulsates intermittently during boot" [Low,Confirmed] https://launchpad.net/bugs/264767
<mdz> Cycom: yes, but selectively (only high-impact / low-risk backports)
<Cycom> mdz: I ask because there is a bug, possibly in evdev, possibly in kernel, for 8.04  that was closed as 'fix released' because the bug doesn't appear in 8.10.
<Cycom> Basically, when you click and hold your mouse, instead of a mousedown event, hold, mouseup, it sends a stream of mousedown events.  This prevents you from doing things like click and drag, etc. Is that high impact enough to reopen?
<kees> dholbach: say, can you replace the universe-contributors icon with this one, which has transparency: http://outflux.net/wrench_emblem-trans.png
<dholbach> kees: can you ask in #ubuntu-motu - in UDW session right now
<tormod> where is udev maintained? the bzr branches on launchpad are all very old
<kees> dholbach: ah, sure, thanks.
<RainCT> mvo: ping
<mpt> pitti, I've e-mailed you my sketches -- the bottom is what I think it probably should look like
<mpt> pitti, let me know if that should be on the wiki anywhere
<pitti> mpt: thanks
<pitti> IntuitiveNipple: re
<pitti> IntuitiveNipple: so, what's your Q?
<IntuitiveNipple> pitti: emailed :)
<pitti> IntuitiveNipple: I saw the response to bug 156085, if you mean that
<ubottu> Launchpad bug 156085 in kvm "Could not open /proc/bus/usb/devices" [Medium,Confirmed] https://launchpad.net/bugs/156085
<slangasek> cody-somerville: looks like more coverage is still needed for xubuntu amd64?
<IntuitiveNipple> pitti: I emailed you and Soren a few minutes ago
<slangasek> _MMA_: ping, now that we have a kernel, is UbuntuStudio looking good for alpha-5?
<IntuitiveNipple> pitti: your ubuntu.com address
<slangasek> _MMA_: and if so, is someone working on ISO testing?
<pitti> IntuitiveNipple: ok, will reply soon, thanks
<mdz> Cycom: generally speaking, we make most bugfixes available through our new releases
<_MMA_> slangasek: I am as much as I can atm. Im starting a new job today and am a bit busy with preppin' for that. Ill make sure someone is on it.
<mdz> Cycom: we only backport bugfixes to an existing release in certain cases where it's justified
<slangasek> _MMA_: ok - when you have someone on it, can you put them in touch with me, so I know where we are in the test cycle?
<_MMA_> SUre.
<unstable> Is there a dbus event for detecting whether or not a cable is plugged into my ubuntu machine?
<unstable> I don't run gnome, I have some custom scripts that run, and I want to be alerted when a cable plugs into my ubuntu machine, anyone that can help/advise me on the best way to be alerted?
<pitti> unstable: ITYM an ethernet cable? :-)
<unstable> yea, ethernet cable
<mdz> slangasek: I didn't reopen 255008 because I'm not sure what to do with it
<mdz> slangasek: I think maybe my original impulse of directing him to his own bug and un-duping was perhaps the right course
<pitti> unstable: network-manager reacts to this, I'm fairly sure it just listens to a hal event
<pitti> unstable: I don't know it off the back of my hand, but try running "dbus-monitor --system" and plug in the cable, and see what happens
<pitti> mpt: it looks nice and clean; the only thing I don't really like is putting the license and status into the bottom part of the text field, since it scrolls off
<pitti> mpt: so you entirely want to get rid of the enabled/disabled colums in the tree view?
<slangasek> mdz: right; I don't see any clearly better options
<calc> slangasek: when will the archive be safe to upload again, any idea?
<calc> i'm planning on doing an OOo upload right after the cds are done
<pitti> mpt: s/license and status/license and support status/
<slangasek> calc: we still have a number of outstanding tests, I think it would be best if you assumed "tomorrow"
<pitti> mpt: also, I think it is at least currently not feasible to entirely merge enabling and "in use"
<calc> slangasek: ok thats fine :
<calc> :)
<calc> slangasek: i assume its safe to do when the email announcement goes out as well?
<slangasek> yes
<calc> ok
<calc> if i happen to see it before then i will upload at that time
<mpt> pitti, I think it would be useful to have an icon-only in-use column, using (smaller versions of) the same icons as the explicit in-use-or-not text underneath
<mpt> pitti, I'm sorry, I've forgotten what the difference is between "enabled" and "in use"
<pitti> mpt: enabled -> install this driver and allow it to be used
<pitti> 'in use' -> driver is used by some hardware right now
<pitti> mpt: e. g. install the nvidia driver -> enabled, but not in use
<mpt> ah
<pitti> restart X -> enabled an in use
<mpt> hm
<pitti> have a broadcom wifi
<mpt> pitti, do you always need to restart the computer for a driver to become in use?
<mpt> or to become enabled?
<pitti> mpt: no, most kernel modules "just work"
<mpt> ok...
<pitti> e. g. the b43 firmware, too
<pitti> mpt: however, you always need a computer restart to disable a driver
<knix> You need to start X for a new graphics driver
<mpt> pitti, so whether a driver is in use is interesting information for deciding whether it should be enabled
<pitti> e. g. uninstall nvidia -> disabled, but still in use
<pitti> reboot -> disabled and not in use
<mpt> oh, I see
<mvo> RainCT: pong
<mpt> hmmmmm
<mpt> The problem is that whether something is "enabled" usually isn't something humans are interested in
<pitti> mpt: I hate this very technical distinction as well, but we are kind oof stuck with it
<mpt> Usually it can be reworded in a way that humans are interested in
<mpt> But in this case, I'm not sure
<mpt> What is the effect of a driver that is enabled but never used?
<pitti> mpt: people might disable nonfree drivers because they don't like them, or so
<pitti> mpt: it just won't work, and just sit there
<mpt> Does it make the computer slower?
<pitti> no, it won't,just takes disk space
<pitti> and of course could create political issues
<mpt> sure
<pitti> having the nvidia proprietary driver isntalled and not in use is already bad in some cases
<mpt> What effects does that have?
<pitti> well, you get infested with non-free software :)
<pitti> (which is why we don't install those by default)
<mpt> but just to be clear here
<mpt> This Hardware Drivers window doesn't actually install and uninstall drivers, does it?
<pitti> it does
<mpt> It does?
<mpt> oh.
<pitti> sure, it installs the packages, configures xorg.conf for nvidia, etc.
<pitti> or, if you disable a driver, it uninstalls packages again
<pitti> or, e. g. for the broadcom case, it instlals/removes the firmware
<pitti> (the kernel module is shipped by default, nothing is installed there)
<mpt> So a driver can be * not installed at all, * installed but blocked from ever being used, * installed but not used right at the moment, * installed and used right now.
<mpt> Is that accurate?
<mpt> Or is the second option impossible in the package management scheme?
<tseliot1> mpt: if you blacklist a kernel module then yes
<tseliot1> it is possible
<mpt> ok
<mpt> So, my design is mostly wrong
<tseliot1> mpt: the "In use" label covered this case too
<slangasek> it's possible that someone can blacklist a kernel module, but is that something that's meant to be handled through this interface?
<emgent`nl> good evening
<mpt> I guess the correct design will occasionally feature the sentence "This driver is turned on but not currently being used."
 * mpt needs to think about this more :-)
<tseliot1> slangasek: this is exactly what I was about to ask. AFAIK you can't do that in Jockey (yet) but I don't see why you couldn't. It wouldn't be difficult to implement.
<LaserJock> ogra: hmm, it turns out my laptop also acts funny when the screensaver is activated
<tseliot1> emgent`nl: good evening
<slangasek> tseliot1: I'm not sure why it's desirable to implement; adding to the list of available states complicates the UI, if nothing else
<emgent`nl> heya tseliot1 :)
<LaserJock> so does suspend,hibernate, and the screensaver all get tied together somewhere? gnome-power-manager perhaps?
<slangasek> LaserJock: yes, g-p-m touches all of the above
<LaserJock> slangasek: ok, interesting
<tseliot1> slangasek: I said that I didn't see the reason why you couldn't, not the reason why you shouldn't ;)
<LaserJock> for a while g-p-m was crashing a lot
<LaserJock> after updates it's not crashing, but I get a unusable computer ;-)
<slangasek> tseliot1, superm1: do you think either of you could give me a release-noteable blurb about why DKMS is good for users?
<superm1> slangasek, yeah i suppose i could.  how soon do you need it?
<slangasek> superm1: if you have it for me today it goes in the alpha-5 technical overview, if you don't, it doesn't :)
<superm1> slangasek, okay i'll try to write a short snippet this afternoon
<ScottK> slangasek: Would you have a moment to accept the subversion backport in hardy-backports?  Due to archive incompatibilities I think it's important to get it out the door.  It's Bug #247514
<ubottu> Launchpad bug 247514 in hardy-backports "Please backport subversion subversion_1.5.1dfsg1-1ubuntu2 from intrepid" [Wishlist,In progress] https://launchpad.net/bugs/247514
<pitti> mpt: re
<pitti> mpt: right, 2 can happen as well; also, if you have a driver isntalled which does not match any installed hardware
<slangasek> ScottK: done
<ScottK> slangasek: Thanks.
<superm1> slangasek, how's this: http://paste.ubuntu.com/43439/
<tseliot1> +1 to superm1's description
<jdstrand> pitti: hi! did you see my earlier queston re: dbgsym and dak?
<pitti> hey jdstrand
<pitti> yes, I thuoght I answered?
<jdstrand> oh, I must have missed it :)
<pitti> jdstrand: oh, about clamav and apparmor? sorry, I missed that
<jdstrand> pitti: the apparmor/clamav was more of a commentary/plan
<pitti> jdstrand: argh, completion error; [18:43]     pitti| jdong: known to me, and I mailed infinity about it the other day
<pitti> sorry, jdong
<jdong> no worries :)
<jdstrand> pitti: ok cool. thanks!
<jdstrand> asac: ^
<balachmar> tkamppeter: So it is fine if I would use the patch to fix the bug 258421? Just wanted to make sure. (BTW I will read the logs to find out your answer :) ) Then I will make that my first attempt to fixing a bug.
<ubottu> Launchpad bug 258421 in gtk+2.0 "GTK apps should send PDF to CUPS when printing" [Medium,New] https://launchpad.net/bugs/258421
<pitti> mpt: hm, so shall I take your proposal with retaining the enabled/in use columns in the treeview for now?
<mpt> pitti, I have the wording wrong and might be missing some elements
<mpt> because I was confused about enabled vs. in use
<mpt> pitti, do you want to get this finished quickly, or can it wait till tomorrow?
<pitti> mpt: oh, it can definitively wait some days
<pitti> mpt: I'm hacking in the code, and the thing I'm working on is not blocked on this
<pitti> also, I'm about to go to bed soon anyway
<mpt> ok
<pitti> mpt: thanks a lot!
<Cycom> mdz: I got home and saw your comments from earlier.  While I understand that the new releases are the primary vehicle for bugfixes, the new release isn't out yet, or even BETA yet.  To write off a bug as FIXED in an existing release, especially a LTS release, seems worriesome.
<blisto1> hey, anyone know why the gnome file browser no longer gives an option for authentication info for samba shares?
<blisto1> This is killing our 300 users.
<blisto1> Worked up until a few weeks ago.
<pitti> good night everyone
<cody-somerville> slangasek, I have some folks who say they're working on it
<slangasek> superm1: thanks, I think I'll try to find a way to say the same thing in fewer words, but that's a good starting point :)
<superm1> slangasek, that was actually already a reduction from what i wrote :)
<slangasek> :-)
<sebner> seb128: ahoi! I was looking for you :D
<seb128> hi sebner
<sebner> seb128: I just saw your gdm update
<seb128> which one?
<seb128> the new version in intrepid?
<sebner> seb128: yep
<seb128> any issue there?
<sebner> seb128: it's a stable new upstream. I thought gdm rewrite is finished with gnome 2.24 and I was wondering why you don't update to latest developement release 2.23.90 (too dangerous) ?
<seb128> sebner: read the discussions on the upstream mailing list, I posted a summary of the issues the new version has in my opinion there some weeks ago, also note that GNOME didn't decide to use the new version either
<seb128> sebner: one issue is that the new version has no graphical configuration tool, so either you use gconf to change option or you don't
<sebner> seb128: so new target is 2.26?
<seb128> it also has no xdmcp, no graphical themes, etc
<seb128> sebner: GNOME is discussing it at the moment
<seb128> read the upstream lists for details
<sebner> seb128: so the rewrite seems not really finished =)
<seb128> sebner: do you think we should update?
<seb128> well, it's working, but it's less flexible than the previous version
<seb128> since there is no strong advantage in the new code I don't see a reason to hurry in something which is less flexible and tested
<sebner> seb128: well shouldn't a rewrite (started with 2.20 I think) be *better* than the old one? ^^
<seb128> sebner: the code is better and it's getting there for sure, I just think it's not there yet
<seb128> maybe next cycle
<sebner> seb128: kk, just wanted to know that. thx for the infos :)
<seb128> you're welcome
<RainCT> it's a bit off-topic but, does someone know how I can align the text in a GtkLabel to the right?
<IntuitiveNipple> RainCT: How about gtk_misc_set_alignment() ?
<RainCT> IntuitiveNipple: that's it. Thanks!
<IntuitiveNipple> cool
<doko> ubuntu-archive: please could you reject libppl from the NEW queue? I'd like to reupload with the different debian .orig.tar.gz
<slangasek> doko: done
<seb128> slangasek: is main still supposed to be frozen?
<slangasek> seb128: yes... :)
<slangasek> seb128: the risk of us having to do a re-roll is low, but yes, we're still frozen
<seb128> slangasek: alright, I've some slightly disruptive change I would like to upload tomorrow morning (lib soname change which some rdepends), maybe it'll be unfrozen by then though ;-)
<seb128> there is a new GNOME again on monday coming, yeah for an another updates sprint ;-)
<slangasek> yes, by tomorrow morning if it's not unfrozen, then I'm having a bad day
<seb128> kees: are you around?
<seb128> kees: is there any easy way to see if those warnings are a security issue or not?
<stefanlsd_> seb128: I made the diff.gz for pidgin if you would like to take a look - https://bugs.launchpad.net/bugs/263612
<ubottu> Launchpad bug 263612 in pidgin "[needs-upgrade] Pidgin 2.5.1" [Wishlist,In progress]
<seb128> stefanlsd_: intrepid is frozen and it's late so tomorrow
<stefanlsd_> seb128: np
<kees> seb128: basically, if the string being printed contains anything from outside the program.
<kees> .
<seb128> kees: or, so if you can pass random datas there
<kees> seb128: most of the false alarms I've seen are printing out localized msgs
<slangasek> _MMA_: heno reported a debootstrap failure with UbuntuStudio alpha5, bug #264804; is anyone else seeing this?
<kees> seb128: right.
<ubottu> Launchpad bug 264804 in debian-installer "[intrepid alpha 5] ubuntu studio i386 install fails at debboostrap" [Undecided,New] https://launchpad.net/bugs/264804
<tkamppeter> hi balachmar
<seb128> kees: thanks
<kees> seb128: most of the time coders just forget to add the "%s" before what they're adding to a function that eventually uses sprintf.
<kees> seb128: sure, let me know if you see any that are iffy or weird.
<seb128> right, that's those I usually
<seb128> kees: most of those are
<seb128> gchat *text;
<seb128> text = g_strdup("some text");
<seb128> gtk_message_dialog (...., text)
<seb128> where it should be ... "%s", text
<tkamppeter> persia. seb128, can someone of you give me the e-mail address of balachmar? I need yo contact him, he visits the IRC only for some minutes when I am not here.
<kees> yeah, or   if (something) { text = _("Some error"); } else { text = _("Another error"); }
<kees> seb128: most of the "real" problems have been when e.g. a filename or URI is included in the message.
<seb128> tkamppeter: I don't know his email
<jdstrand> kees: how often have you seen these false positives?
<seb128> kees: I see, thanks, I'll start patching those when I do updates
<kees> seb128: great, thanks muchly.
<seb128> jdstrand: as I was saying before, that's my build directory
<seb128> $ find . -name *.build | xargs grep "warning: format not" | wc -l
<seb128> 916
<seb128> jdstrand: so there is lot of those in GNOME
<jdstrand> seb128: right, I saw that-- I was just curious cause kees did an archive rebuild at one point
<kees> jdstrand: I haven't done a huge analysis yet, but on a rough guess, I'd say about 1/5th of the packages that throw the error are vulnerable.
<seb128> utch
<kees> but that's just a wild guess
<jdstrand> sure
<seb128> good idea to clean those then ;-)
<seb128> some have already annoyed me
<jdstrand> but that is a high false positive rate, even if you are off by a bunch
<seb128> GNOME tends to use -Werror in svn so builds break in intrepid
<kees> and for a vulnerable one, there are 15 warnings and only 1 is an issue.
<seb128> it seems those don't trigger warning on other distros though
<seb128> so upstream didn't notice
<kees> seb128: yeah, I knew these compiler defaults were going to cause a lot of pain (which is why I've been trying really hard to document them and fix ones I see)
<kees> seb128: additionally, I didn't want to do build-bumps just to get things recompiled -- we've got enough pain.  :)
<seb128> right
<kees> my hope is to get the bulk of the archive rebuilt with hardening before the next LTS
<jdstrand> I think that should be doable
<NCommander> kees, well, I had a setback, but I'm on the right path now, I had to redo the Linux from Scratch chroot
<kees> NCommander: heh, cool
<kees> well, cool that you worked it out, not that you hit glitches.
<NCommander> The big issue is that I screwed up the linker
<kees> :)
<NCommander> and I tried to use Ubuntu sources
<NCommander> I'm going to work from baseline known to build sources, then rebuild larger with the Ubuntu source code
<ScottK> NCommander: You're indi fix looks good.  I'm just waiting for slangasek to announce Main is open for business to upload it.
<NCommander> \o/
 * NCommander is a porter
<NCommander> weee
<NCommander> Kinda a weird concept on ubuntu since no one realizes our ports exist
<slangasek> this is better than being a stout
<seb128> kees: so for example gedit has:
<seb128> 	message = g_strdup_printf (_("The file \"%s\" is read-only."),
<seb128> 				   name_for_display);
<NCommander> sladen, stout?
<seb128> dialog = gtk_message_dialog_new (....message);
<NCommander> er, slangasek ^
<ScottK> NCommander: Beer reference.
<seb128> kees: that could be leading to a crash or something
<NCommander> ah, me and my lack of /dev/alchocalism strikes again
<kees> seb128: correct.  that is potentially exploitable, but very hard to trigger.  ("user-assisted" as we call it.)
<seb128> kees: alright, I'll not bother too much I think, just clean those on the way and send patches upstream
<seb128> kees: I'm not sure what made the yelp one a security issue though
<NCommander> ScottK, as an side, was I right about the kde4bindings issue w.r.t. to mono on lpia?
<kees> seb128: it was that firefox uses yelp as a handler for man:// and info://, and doesn't show the URL when asking the user to open yelp
<ScottK> NCommander: I haven't got to that one yet.  I checked indi first.
<NCommander> Ah
<kees> so, clicking a link on a page could lead to a format attack without much user interaction.  it was still considered "low" priority.
<seb128> kees: still that should be nothing exploitable, yelp is a local application so that could only lead to crash it no?
<Riddell> NCommander: did you manage to look at koffice?
<NCommander> Riddell, I've built it, did some research, I can kick out a fix for it when main unfreezes
<Riddell> great, thanks NCommander
<seb128> NCommander: so you work on ubuntu, kubuntu and xubuntu now?
<NCommander> Pretty much
<NCommander> Give me time, I'll do work on Studio too
<jdstrand> ScottK: what is the recommended way of integrating amavis-new with clamav in intrepid? (a wiki link or whatever is fine)
<NCommander> And Mythbuntu getting installed on something when I find cheap hardware
<seb128> NCommander: ;-)
<seb128> NCommander: I've uploaded pangomm today btw, I'll get pitti to review it tomorrow
<kees> seb128: it would be very hard to exploit, but it could still lead to arbitrary code execution.
<seb128> kees: alright, I think that was enough question for today, thanks for reply to those!
<kees> seb128: using %n and other carefully selected items, an attack can target specific areas of memory, and gain control of the execution flow.
<kees> seb128: heh, no problem, I'm happy to answer them.
<NCommander> seb128, I consider myself a jack of all trades. All derievates on all architectures I can access
<NCommander> Or in other words, if its broke, I can fix it, or I know the guy who can fix it :-)
<seb128> :-)
<NCommander> (the sole exception ATM is gcl. I don't touch packages who's patch files are 5 times the size of the 15MB source package)
<ScottK> jdstrand: I just looked and my notes are not at all where I thought they were.  So working from memory, you have to do some config file editing.   The most common one I see people use is http://www200.pair.com/mecham/spam/
<seb128> NCommander: so you would touch openoffice? ;-)
<NCommander> seb128, built it from source once or twice
<slangasek> dear God, why
<NCommander> slangasek, same reason I want Ubuntu on Alpha
<jdstrand> ScottK: ok-- I was going to try it out to give it at least a shot at working out of the box :)
<NCommander> I like pain, or a challenge
<slangasek> you hate the planet?
<slangasek> oh
<ScottK> Great.
<NCommander> That being said, I'm not going to be coding new features for it :-P
<NCommander> But I'll fix build failures
<NCommander> slangasek, no, just driving you insane with an alpha port ;-).
<slangasek> no reason it would bother me
<NCommander> argh
<NCommander> bah, so much for driving people crazy
<NCommander> seb128, given my recent work on bootstrapping and fixing nutty FTBFS, I'm keeping a blog about it
<NCommander> seb128, you can watch my descent into true insanity in real time
<slangasek> NCommander: I can think of more noble hobbies than trying to drive people crazy...
<seb128> NCommander: you should become an ubuntu member and be on planet ubuntu ;-)
<NCommander> seb128, I plan to apply after two months have passed
<seb128> NCommander: btw pangomm will probably be accepted tomorrow, is gtkmm 2.13 ready? ;-)
<NCommander> slangasek, I'm just multitasking. I drive myself crazy already, but I have enough free time to make someone else loose their mind too
<NCommander> slangasek, ;-)
<NCommander> BTW, there are people nuttier then I am
<NCommander> Someone modified aptitude to solve suduko puzzles
<jdstrand> ScottK: unless I am looking at the wrong thing, that page is a) from 2006 and b) completely ignores the Debian packaging
<jdstrand> I seem to remember something in the wiki...
<ScottK> May be.  As I said I can't find my notes.
<ScottK> http://www200.pair.com/mecham/spam/clamav-amavisd-new.html is a little more specific.
<ScottK> You may have to grep a bit for which config file stuff is in, but it should be generally accurate.
<jdstrand> yeah, I was just looking at that...
<jdstrand> ScottK: what about https://wiki.ubuntu.com/MOTU/Clamav/TestingProcedures ?
<ScottK> I totally forgot about that.
<ScottK> I think it misses the step where you activate clamav.
<ScottK> Grep for clamav in the the conffile directory and you'll find that.
<jdstrand> ok
<slangasek> superm1|away: how does http://paste.ubuntu.com/43476/ look to you?
<asac> ogra: mozilla bug 453704
<ubottu> Mozilla bug 453704 in General "Extreme slowness, "Firefox is already running" error for >3 users launching Firefox in LTSP environment" [Critical,Unconfirmed] http://bugzilla.mozilla.org/show_bug.cgi?id=453704
<asac> ogra: any hint? that user appears to have issues with ubuntu ltsp like above
<calc> all java in main is supposed to be using default-jre right?
<calc> or whatever it is called?
<calc> doko: ?
 * calc is going to convert over OOo 2.4.1 to using it if so
<calc> ah i found the email
<jdstrand> ScottK: amavis[16255]: (16255-01) Blocked INFECTED (Eicar-Test-Signature), LOCAL [127.0.0.1] [127.0.0.1] <jamie@localhost> -> ...
<jdstrand> ScottK: so I updated the wiki page accordingly
<jdstrand> ScottK: *and* the profile didn't block amavisd-new :)
<ScottK> jdstrand: Great.
<doko> calc: yes. are there any outstanding problems with this?
<ScottK> jdstrand: I've got a variety of gui front ends on my laptop for testing.  I'll make sure those are OK too.
<jdstrand> ScottK: excellent. I'll upload the debdiff today/tonight
<cjwatson> Cycom: as far as bug statuses go, "fix released" is the correct state for the bug if it's fixed in intrepid, but you can use the "target to release" link to nominate the bug to be fixed in hardy as well; if that nomination's accepted by the release team, the bug then grows an extra independent state for hardy
<Cycom> cjwatson: wouldn't it make more sense to have a seperate state for a bug that won't be fixed in a release?  It's confusing for people examining the bug who still have the bug in the current release.
<Cycom> cjwatson: 'Well, clearly I need to file a new bugreport!' kind of thing.
<Cycom> it would make more sense to have a 'fixed in new version'.  Also, Intrepid is still alpha.  It's not supposed to be used by general users yet.
<cjwatson> no, because the default state for the vast majority of bugs is that they get fixed in the current development release and we move on. In terms of raw bug count, it's relatively rare for fixes to need to be backported to stable releases, and so it wouldn't make sense to optimise for that.
<Cycom> cjwatson: how bout just marking it 'won't fix' then?
<cjwatson> no. the state of the bug is fix-released. when intrepid is released ordinary users will be able to get hold of that fix. From your description, it might well make sense to nominate it for hardy too
<cjwatson> We're not going to reoptimise bug workflow for the uncommon case, but we do have ways to handle it which I've described to you
<Cycom> if the fix isn't available, then it's not released...
<cjwatson> this is how we use the bug states. please respect that
<ScottK> Cycom: You aren't the first to suggest this approach and it really has been considered.
<Cycom> is there a page to explain this to users?
<Cycom> if so, I have no gripe.
<Cycom> if not, it should be made.
 * calc thinks he redid the java bits in 2.4.1 properly to build both with openjdk and gcj
<calc> doko: i think it should be fine now that i have the patch to workaround the rhino issue
<doko> ok
<calc> doko: before it was failing due to the bug wrt rhino, there is already a bug filed in launchpad about it as you are probably aware :)
<cjwatson> Cycom: I agree that something should be written and put somewhere prominent. At the moment I can't find such a page
<cjwatson> (which is not necessarily to say it doesn't exist, I'm not a docteam kind of guy ...)
<cjwatson> https://wiki.ubuntu.com/Bugs/Status defines our use of Fix Released
<cjwatson> although it's aimed more at bug triagers than bug reporters
<Cycom> cjwatson: Won't Fix: It is most often used for bugs with a release target that will not be fixed in that particular release but may be fixed later.
<Cycom> vs. Fix Released: a release tarball was announced and is publicly available, or a fix was uploaded to an official Ubuntu repo.
<cjwatson> yes, that's *if* somebody nominates a bug for a release and then it's later decided to be inappropriate for that release
<cjwatson> that hasn't happened here
<cjwatson> I've added a line to the description of Fix Released to describe the case at hand
<Cycom> cjwatson: I was just about to suggest that :)
<cjwatson> Won't Fix is only right if you think it *shouldn't* be fixed in hardy; which seems unlikely given your general manner :)
<Cycom> cjwatson: so that now begs the question, where IS the target to release link?
<cjwatson> right now, the state is that no decision has been taken regarding that bug and hardy
<cjwatson> Cycom: should be just below the "Affects" box, but it may be that you only see it if you have permission to use it
<Cycom> 'Nominate for release'?
<cjwatson> oh, it's called "Target to release" on edge.launchpad.net. Sure, that sounds right
<Cycom> cjwatson: broken link :/
<cjwatson> (that's the beta testing site)
<cjwatson> get somebody in #ubuntu-bugs to do it for you
<Cycom> cjwatson: great! thanks.
<cjwatson> I could do it myself, but I'd rather not since I'm in the release team and if I do it it'll automatically accept the nomination
<Cycom> cjwatson: yeah, I understand :)
<cjwatson> which is a bit more than I'd prefer at 11:30 at night
 * cjwatson -> bed
<Cycom> later dude. thanks again.
 * calc bbl
<cjwatson> oh, another way to look at the whole thing (might as well mention it since I thought about it) is that ultimately users benefit if we can make developers' processes for bug handling as efficient as possible. Developers are more efficient if they don't have to keep on looking at the bugs they've already fixed; therefore it makes sense to mark them fixed in the default view once the development release is fixed, and only ...
<cjwatson> ... have developers have to look at them if they're using a non-default view (like launchpad.net/ubuntu/hardy/+bugs)
<lifeless> yah
<lifeless> this is why bzr marks bugs as fix released when they hit mainline
<cjwatson> there are definitely smarter ways to do it (theoretically speaking) but this is what we have for now)
<jdstrand> ScottK: uploaded debdiff for bug #264817
<ubottu> Launchpad bug 264817 in clamav "clamav should ship apparmor profiles" [Medium,In progress] https://launchpad.net/bugs/264817
<jdstrand> ScottK: keep in mind that it will be in complain mode on certain upgrades (see ApparmorProfileMigration), but new installs will be enforcing
<jdstrand> ScottK: ping me when satisfied, and I'll apply for FFe
<leszek> where can I find or change the translated menu in the isolinux bootloader from the livecd ? the *.tr file seems not to be the place
#ubuntu-devel 2008-09-05
<kees> fta, asac: is is possible to build thunderbird with FORTIFY now?
<asac> kees: most likely lacks the patch
<asac> kees: is this blocking something?
<kees> asac: nope, just noticed it is all.
<kees> asac: should I re-open the bug?
<asac> kees: i am too tired right now, but maybe we should add a tracker bug for all mozilla apps :)
<kees> asac: okay, I'll ping you about it tomorrow.  thanks!
<NCommander> Wooooo, MIPS based laptop
 * NCommander figured out how to order one and port Ubuntu to it
<NCommander> http://mobile.slashdot.org/article.pl?sid=08/09/04/2232225
<NCommander> kees, poke
<kees> NCommander: yo
<NCommander> kees, what options do you want me to embed into GCC
<NCommander> I want to deprieate harden-wrapper on amd64 if possible by simply having GCC have those options ON by default
<NCommander> *hardening
<NCommander> I can add any flag that GCC recongizes as well as FORTIFY_SOURCE
<kees> NCommander: there's already all in there: https://wiki.ubuntu.com/CompilerFlags
<NCommander> HLFS recommends: -fstack-protector -fstack-protector-all fPIE -pie -Wl,-z,relro -Wl,-z,now -Wl,-z,combreloc
<kees> -z now by default is a bad idea.
<NCommander> With the behavior turning off on -D_KERNEL_
<NCommander> Ok
<kees> haven't seen combreloc before
<NCommander> (fortify source will also be set on by default)
<kees> see that wiki page
<NCommander> Yes my lord and master
 * NCommander will have patchs for doko that will make him scream
<kees> NCommander: I feel like you're not hearing me: I have already patched gcc for all those options.
<NCommander> I thought hardening-wrapper did it
<NCommander> Oh
<NCommander> Sweet :-)
<NCommander> That just means I need to add the PIE flags to the spec file, and we're in business
<kees> I have implemented these options in about 3 ways now.  :)
<kees> hardening-wrapper _also_ does it.
<NCommander> I guess some confusion on my end is understandable
<NCommander> I didn't know that
<kees> note that there isn't technically a "spec" file.
<NCommander> spec strings
<NCommander> Fine :-P
<kees> check out my existing patches in gcc-4.3 for some hints on the insanity needed.  :)
<NCommander> You have to modify the linux64.h if you just want it 64-bit specific. Linux.h affects both i386 and amd64, right
<NCommander> ^?
<kees> NCommander: sounds right, but I don't know for sure.  this is a doko area.  :)
 * NCommander turns on the doko-light
<NCommander> he's going to eventually read this backlog, and a high pitched scream is going to deafen us all
<bryce> pitti: ping
<bryce> pitti: anyway, I've got the debdiff for g-c-c at http://bryceharrington.org/ubuntu/gnome-control-center_2.23.90-0ubuntu5.debdiff
<bryce> pitti: anyway, I've got the debdiff for g-c-c at http://bryceharrington.org/ubuntu/gnome-control-center_2.23.90-0ubuntu5.debdiff
<ion_> echo... echo... echo...
<bryce> ion_: sorry, xchat is not displaying anything
<bryce> pitti: I'll plan on uploading that post-alpha-5 unless you or seb128 wish to see it included for alpha-5 (in which case feel free to upload it yourselves)
<NCommander> ScottK, you floating around?
<NCommander> Riddell, you around?
<NCommander> Hobbsee, you around?
<ScottK> NCommander: Here now.
<GomoX> Hey
<GomoX> The wifi toggle key on my laptop doesn't work (i get the setkeycode message on dmesg), how do i go about indicating the right keycode to somehow get it fixed in the next release?
<GomoX> Also i'm not sure how it works on other laptops but i guess it should toggle NetworkManager.getWirelessEnabled via DBUS
<NCommander> GomoX, this is for Ubuntu development, not Ubuntu debugging, please try #ubuntu
<NCommander> (or support)
<GomoX> Well technically this should be interesting to the corresponding developer
<GomoX> I can get it working with a script, the question is how does one go about telling the corresponding dev about it
<NCommander> GomoX, file a bug on Launchpad
<android6011> is there an alpha 5 install iso yet?
<philwyett> Not yet going by cdimage.ubuntu.com
<android6011> so its been delayed then?
 * NCommander waits on the passage of time.
<Hobbsee> NCommander: contentless ping.
<NCommander> Hobbsee, interesting in commenting on my UDC application?
<Hobbsee> hmmm....
<NCommander> Riddell, I got koffice2 fixed, waiting on a confirmation build
<pitti> Good morning
<NCommander> morning pitti
<Hobbsee> pitti!
<NCommander> pitti, mind if I pick your mind on an archive question?
<pitti> NCommander: not at all
<pitti> Hello Hobbsee, hey NCommander
<pitti> bryce: post-alpha 5 is ok, thank yuo
<NCommander> pitti, ok, have you been following the PIE experiment?
<pitti> NCommander: not too closely, the uploads were done during my holidays
<NCommander> pitti, well, -fPIE wasn't enabled because it causes FTBFS because to make it work, every static library and static built binary needs to be rebuilt in the archive
<NCommander> pitti, if something non-PIE remains, builds would explode in a shower of sparks
<NCommander> pitti, right now, with kees's assistance, I'm doing a full manual bootstrap of Ubuntu amd64 with PIE enabled. Now the ABI will remain unchanged, but every library needs to be rebuilt, and I felt that trying to mix PIE and non-PIE libraries was a disaster waiting to happen
<NCommander> pitti, talking to kees, if it proves that the archive can reasonably be converted to -fPIE/PIC, he's going to push hard to make the change
<NCommander> pitti, so here comes the archive part
<dholbach> gooood morning
<pitti> hey dholbach
<dholbach> hiya pitti
<NCommander> pitti, there will be a transitional period where we will have to pretty much remove the existing binaries and rebuild things from scratch. What I think though might be an easier solution however is treat it as a new architecture, amd64-pie
<pitti> NCommander: I expect that there will be some fallout, i. e. a lot of packages which won't build with -fPIE right away; but ICBW, of course (and hope I am :-) )
<NCommander> pitti, when transitional time comes, its just a matter of changing every deb from amd64-pie to amd64
<NCommander> pitti, the other choice is keep it in a different distribution such as intrepid-pie, intrepid+1-pie, etc.
<pitti> NCommander: well, this wouldn't be a thing we'd keep indefinitively, it's an one-time transition, right?
<NCommander> pitti, once per architecture
<NCommander> (once AMD64 goes, powerpc will go, and so forth expect lpia/x86)
<NCommander> Roughly speaking, having it as an architecture allows us to seperately manage those buildds without disrupting amd64's normal port until the very end of the transition
<pitti> NCommander: I would assume that having an amd64-pie arch would be feasible (except for the mirror costs maybe), but a mass-renaming of amd64-pie .debs to amd64 sounds hackish and wrong
<NCommander> pitti, well, we could just do a rebuild, but we need the archive tracking with PIE
<pitti> NCommander: TBH I'm not quite sure how to do that transition smoothly; of course the first test build should be entirely separate, but then we more or less need to rebuild the entire archive on soyuz anyway, so we might just as well do it for the right architecture
<NCommander> pitti, I'm going to be using ubuntuwire and rebuildd to track, but its still not that great since it means only ubuntuwire admins can control the rebuildd daemon, and no bug control intergration, etc.
<pitti> that should happen at the opening of a cycle, when it doesn't matter so much to have a mostly broken archive
<NCommander> pitti, extactly. I suspect pie will hit AMD64 intrepid+2
<NCommander> (we can probably add amd64-pie to Launchpad towards the end of intrepid+1)
<pitti> NCommander: will still be quite tricky, I expect, since yuo have to rebuild everything in a particular order (upwards the dependency chain), right?
<pitti> or can you build PIE programs against non-PIE libs?
<NCommander> pitti, correct. It would be the equivent of rebootstrapping amd64 from scratch
<NCommander> pitti, no, the linker explodes
<pitti> well, hang on, aren't libs PIE already anyway?
<NCommander> Only shared
<pitti> or was that just "PIC"?
<NCommander> Static libs need to be rebuilt
<pitti> NCommander: right, but who cares about static libs? there should be very few cases actually
<NCommander> You'd be suprised
<wgrant> How many static libs are there?
<NCommander> wgrant, enough
<wgrant> Can't they just be rebuilt?
<pitti> NCommander: in fact, that would be a good opportunity to get rid of them altogether
<wgrant> Grr.
<NCommander> pitti, every executable still needs a rebuild, and the shared libraries still need -fPIE AFAIK
<NCommander> (I haven't tried mixing and matching flags just yet :-))
<slangasek> no, the shared libs shouldn't need -fPIE
<NCommander> There is a good Gentoo page
<pitti> NCommander: IIRC it is Debian Policy to build shlibs with PIE
<NCommander> But let me put it like this
<slangasek> they should already be position-independent if built with -fPIC; and if that's not sufficient for any reason, that's a bug in the implementation
<NCommander> dpkg is compiled against a static libselinux
<pitti> sorry, -fPIC
<NCommander> That's a core package, and I bet there are loads more all over the place
<slangasek> there should certainly not be /loads/ more
<pitti> NCommander: dpkg is also quite a special case
<slangasek> there should be a few dozen at most
<pitti> NCommander: dpkg must not link against a lot of shlibs, because it almost always have to work
<NCommander> slangasek, 15% of main alone FTBFS due to PIE/non-PIE linkages
<slangasek> erm
<pitti> NCommander: there's things like bash-static, but I really thing we shuoldn't have more than a handful of static linkages
<NCommander> (kees has been experimenting with this more)
<NCommander> Well, the experiment to see quite how bad the situation is
<NCommander> If we want to look towards removing or (in my opinion, a better solution would be adding them as a -static-dev package) doing whatever with static libs
<NCommander> This is the best time to do it
<NCommander> I expect getting main to be PIE (with a few exceptions) should be relatively straightfoward. I'm more worried about universe
<pitti> seriously, do we really need to waste so much archive space for building static libs all the time
<pitti> especially since I expect that 95% of them are not policy compliant anyway?
<slangasek> hrm?  policy for a static lib is pretty easy
<NCommander> pitti, how do you suggest we remove them?
<pitti> (static libs must not be built with -fPIC, but I seldomly see a package which actually builds twice)
<slangasek> pitti: anything that uses libtool builds twice
<NCommander> pitti, that's only completely true for x86. amd64 and other architectures can have static libs as PIC safely with some benefits
<slangasek> and I'm not sure that's a 'must'; consulting the policy
<slangasek> ah, it is a must, with exceptions
<NCommander> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3 - the Gentoo packaging page
<NCommander> Which explains the usual PIE related FTBFS
<slangasek> I don't see any explanations of PIE failures on that page
<NCommander> Go straight down to the bottom
<NCommander> The four problems with PIE and how to correct
<slangasek> those all say "PIC"
<NCommander> PIE is just a PIC executable
<slangasek> I think I know better than you what PIE is, if you're trying to claim that all shared libs need to be rebuilt with an extra option to be compatible with it
 * NCommander runs regression testing on his PIE compiler
<NCommander> slangasek, no, I'm not saying that. The static libraries either must be rebuilt or removed
<NCommander> Or any resulting binaries that links statically will fail once PIE is default
<slangasek> ok, but things aren't supposed to be linking to static libs /anyway/ aside from exceptional cases.
<NCommander> slangasek, at least you confirmed for me the -fPIE issues weren't quite so bad as kees made them sound to be
<NCommander> or should I say clarified
<pitti> at least I don't think we need a particular order in rebuilding the archive, which makes things much easier
<pitti> at least not for shlibs
<slangasek> well, I don't know what this 15% figure is based on
<slangasek> but if 15% of main is linking to libs statically, something's wrong, and we should fix that instead of papering over it :)
<NCommander> slangasek, that was simply the percent of packages that failed
<NCommander> slangasek, well, yes. I'll have to ask kees when he floats online
<NCommander> (its quite possible there were other FTBFS issues related to PIE)
<pitti> I see the usefulness in static linking for dpkg, bash-static, busybox-static, zsh-static, dar-static, and binutils-static, but that's about it
<NCommander> I figure if killing static libraries as best as possible is desirable, might as will kill two birds with one stone
<NCommander> The question is how to do it
<pitti> even things like cdebootstrap-static are not warranted IMHO
<slangasek> pitti: there are some libs that get linked statically because they don't have stable ABIs
<slangasek> (libbfd)
<pitti> (well, at least to me the entire idea of cdebootstrap is hilarious, but *shrug*)
 * NCommander has never gotten it to work
<pitti> slangasek: right, those too
<pitti> slangasek: ffmpeg or something similar was such a case
<NCommander> so there are enough static libs that rebuilding the archive is justified
<slangasek> well, ffmpeg's case isn't all that similar :)
<NCommander> (and probably not a bad idea to make sure everything got built with the new hardening flags from intrepid)
<wgrant> Rebuilding the entire archive would be a nightmare.
<slangasek> NCommander: no, it's not at all justified; just identify and rebuild the packages providing static libs that are linked against by packages
<NCommander> slangasek, every executable still needs to be rebuilt with -fPIE
<slangasek> "needs" - that's not a strong argument for an archive event, IMHO
<wgrant> Not immediately.
<wgrant> We haven't had an archive event for a while now.
<NCommander> this is why I'd like to do the staging work as amd64-pie, which make sure everything is going to work, and then can be simply killed once amd64 is fully migrated
<NCommander> slangasek, thinking it over, the best solution is to rebuild the base system by hand due to the static libraries with PIE with this rebuild being a new architecture (amd64-pie), and then do a test rebuild with a deb line for the archive and (amd64) added similar to lpia, which would simulate the situation we'll see on the buildds, and catch what packages will need to be touched to properly complete the transition
<NCommander> slangasek, would you agree?
<pitti> do we actually need that new arch in soyuz? that's a quite expensive operation; wouldn't a local archive do as well?
<NCommander> No it won't
<pitti> (for the test rebuild)
<NCommander> No, I wasn't doing the rebuild on SOyuz ;-)
<NCommander> ubuntuwire already has the infrastructer doing it
<NCommander> It just means the chroot on every buildd will need to be manually updated due to the bootstrapping issue (you can't (easily) build the PIE base system from a non-PIE chroot; its extremely difficult to do)
<NCommander> THe binaries of course shouldn't break anything
<NCommander> Roughly speaking, it basically becomes the base system needs to be bootstrapped PIE, the buildds need that chroot installed, and then just rebuild the base packages which require static
<slangasek> it shouldn't be that difficult, the static libs that need to be built should be identifiable by visual inspection
<NCommander> slangasek, once the build system is rebuilt, the FTBFS will find the rest
<slangasek> then everything else should be rebuildable without fiddling
<NCommander> s/build/base
<NCommander> then its just a matter of making sure the important packages get retouched
<NCommander> slangasek, I'm glad your experienced in such matters, you saved me quite a bit of work in testing this ;-)
<nemesis> hi, when will alpha 5 be released?
<amitk> pitti: cjwatson: what would convince you to move kerneloops package to the default install?
<pitti> amitk: hm, don't we have the kernel crash dump infrastructure for that now?
<pitti> amitk: apport picks up the dump, and offers the user to send it to LP as a bug report
<amitk> pitti: kerneloops is unrelated
<pitti> right, I know
<pitti> we shoudn't have two different systems for the same purpose
<amitk> pitti: it sends the bug reports the kerneloops.org so that upstream sees what bugs are most frequently encountered
<amitk> pitti: in case of the kernel, it would help to push bugs upstreams sooner, than waiting for kernel QA to manually link them upstream through LP
<pitti> amitk: can we discuss that on ubuntu-devel@ first?
<amitk> pitti: sure. I will send email.
<pitti> amitk: would they actually appreciate getting reports from a heavily ubuntu-modified kernel?
<pitti> amitk: what kind of GUI does it offer, BTW? it depends on gtk, but how does it integrate into the desktop?
<pitti> amitk: so, depending on how it looks and what it does exactly, we could have it similar to apport (enable in the development release, disable in the final release)
<pitti> such things aren't appropriate to enable on production systems, in stable releases, but very useful for devlopment releases indeed
<amitk> pitti: there is a kerneloops-applet that pops up when it notices an oops. It seems well intregrated into gtk/gnome.
<nemesis> are there any information online about what you talk right now? so a user can use this? :)
<NCommander> pitti & slangasek, roughly speaking, who is in charge of the buildd chroot and upgrades? (I just want to compare notes with them)
<amitk> pitti: 'apt-cache depends kerneloops' shows dbus, glib, gtk, libnotify
<pitti> NCommander: infinity and lamont
<pitti> amitk: ok, thanks; let's discuss this on the ML to get some more input, shall we?
<amitk> pitti: ack
<pitti> soren: EBW == evil, bad, and wrong
<soren> pitti: Heh :) Ok.
<tseliot> pitti: will I have to modify the detection and representation of the recommended driver in Jockey for the new interface mpt and you are working on?
<pitti> tseliot: no, that should be fine
<tseliot> pitti: ok
<\sh> pitti: moins....any update on the MIRs?
<pitti> \sh: I processed almost all of them yesterday, but was sidetracked with doing some high-urgency stuff
<pitti> \sh: oh, right, your's is tslib, right?
<\sh> pitti: not mine, but I'm waiting for it, because of refresh+update on ia32-libs
<mdz> asac: eek, firefox won't start anymore on my current Intrepid system ("Error launching browser window:no XBL binding for browser")  is there a known issue?
<mdz> I would check myself but my browser doesn't work ;-)
<\sh> mdz: I have since yesterday some strange "firefox just crashing randomly without leaving any trace"
<mdz> \sh: sounds different
<asac> mdz: no ... i didnt hear about that. also there wasnt an upload the last days.
<\sh> asac: http://paste.ubuntu.com/43585/ <- can you have a look and tell me if it's known to you?
<\sh> asac: sidenote: it's not on all websides with flash...this is happening e.g. on technorati for me...I wonder why
<asac> \sh: i guess you are on 32-bit?
<\sh> asac: no ;)
<\sh> afaik I don't have any i386 anymore in use
<asac> mdz: i think a first start would be to stare at strace -f -eopen firefox ... and see if there are any write permission issues or some files not found
<asac> \sh: what does: dpkg -S libflashplayer.so
<asac> give you ?
<asac> \sh: obviously your libflashplayer.so is installed in a wrong fashion
<asac> but afaik our package doesnt do that
<mdz> pitti: I tried to override the browser for apport-cli with $BROWSER but it still launches firefox
<\sh> asac: hmm..dpkg -S libflashplayer.so doesn't give me anything, dpkg -l|grep flashplugin-nonfree gives me 1.0.1.128+10.0.0.525ubuntu1
<pitti> mdz: it first checks your preferred browser in System -> Preferences -> Applications
<pitti> (might be "Preferred applications" or so)
<lucky711x> wow everyone quits as soon as I ask a question :)
<lucky711x> wow everyone joins at the same time
<cjwatson> lucky711x: http://wiki.ubuntu.com/ContributeToUbuntu may help you get started
<mdz> asac: I don't see anything particularly scary in there
<asac> \sh: think for a minute why you have /usr/lib/firefox-addons/plugins/libflashplayer.so
<asac> \sh: if you dont find an explanation, just remove that file
<lucky711x> cjwatson, yeah Ive read through almost everything on the wiki
<asac> \sh: maybe look at what uplaods were done for the flashplugin-nonfree package . i dont want to rule out that there was yet another broken upload
<lifeless> 19:07 < lifeless> mdz: try removing your extensions
<lifeless> 19:08 < lifeless> mdz: apparently the 'chrome' folder should contain them, they might be per-user or packaged
<lucky711x> cjwatson, I guess what I mean is that what can I apply my Java experience to?  Or what would be the best area of development?
<lifeless> 19:10 < lifeless> mdz: also try passing --safe-mode
<lifeless> 19:10 < lifeless> e.g. firefox --safe-mode
<cjwatson> lucky711x: quits/joins> those were a netsplit, when two IRC servers in the network forget how to talk to each other for a bit. The better clients know how to filter them all down to one line
<lucky711x> ahh
<\sh> asac: will reinstall the package (remove --purge + --reinstall install )
<dholbach> kees: I fixed the harvest problem you ran into
<mdz> asac,lifeless: aha, there is still a firefox process running but no windows
<asac> mdz: yeah
<asac> mdz: that explains it.
<mdz> asac: it seemed to shut down cleanly
<cjwatson> lucky711x: we don't have a lot of Java applications installed by default or anything, but we are generally in need of more people to help maintain Java library packages; https://wiki.ubuntu.com/JavaTeam have weekly meetings and you could start by looking over their records
<lucky711x> cjwatson, ok cool thanks
<\sh> asac: that was it
<asac> \sh: i am a bit scared why the plugin is in that directory. did you run adobes installer?
<cjwatson> lucky711x: also, a good way to get started is often to visit the bug tracker for packages you're interested in (https://bugs.launchpad.net/ubuntu/+source/INSERTSOURCEPACKAGENAMEHERE/+bugs) and start proposing patches
<\sh> asac: some time ago...but thought I got rid of all cruft of that
<lucky711x> cjwatson, thanks alot Im really excited to help out with Ubuntu
<NCommander> cjwatson, I think you need to stop me right now
<NCommander> cjwatson, I'm looking at SGI MIPS machines. If I get one, an Ubuntu port may be born after my current rebuild project
<asac> hmm ... is alpha5 stuck?
<cjwatson> the only problem I heard of was the Edubuntu add-on CD one
<cjwatson> _MMA_: oops, I just noticed that I arranged for ubuntustudio-desktop to be installed by default, but forgot to roll out that debian-cd change to antimony. Sorry about that; should be fixed after alpha-5
<cjwatson> slangasek: anything other than Edubuntu holding things up?
<pitti> ogra: ltsp-client-core is the only thing still needing discover1, and it has been obsoleted by discover and removed in Debian; do you eventually plan to get rid of it?
<ogra> pitti, i think i can drop it
<pitti> ogra: want a bug report?
<ogra> though ltsp has the oportunity to use xdebconfigurator
<ogra> and given that Xorg --configure which we used until now hardlicks the system thats probably the only opportunity to get a sed'able xorg.conf
<ogra> *hardlocks
<ogra> pitti, i have to think about that, ltsp relies on xorg.conf for the custom setups ...
<pitti> ogra: ok, thanks
<ogra> if bryce can make Xorg -configure work as it used to (and as its documented) i can get around that though and discover can go
<ogra> but i'm note sure the current design of Xorg even remotely offers that
<slangasek> cjwatson: if I see some progress on UbuntuStudio testing I might delay the push to let that finish; otherwise, not AFAIK
<stefanlsd> aah. these look cool - think im gonna put off my eee pc purchase - http://www.dell.com/content/products/productdetails.aspx/laptop-inspiron-9?cs=19&s=dhs&ref=homepg
<cjwatson> slangasek: I couldn't reproduce the bug that got filed about debootstrap failing
<cjwatson> (bug 264804)
<ubottu> Launchpad bug 264804 in debian-installer "[intrepid alpha 5] ubuntu studio i386 install fails at debboostrap" [Undecided,Incomplete] https://launchpad.net/bugs/264804
<mdz> asac: killing that process fixed it, but I can't say what went wrong
<slangasek> cjwatson: does that mean you have a complete successful test, then?  that would seem to be the first reported for US alpha-5, if so
<asac> mdz: most likely xulrunner upgrade underneath a running firefox ... after alpha-5 the new ubufox will hopefully fix this by presenting users with a "restart" button in firefox after upgrade
<asac> which then might have a better chance to completely tear down the old firefox
<slangasek> updated edubuntu CDs posted now; syncing the amd64 one here
<tseliot> ogra: why do you need a a sed'able xorg.conf?
<ogra> tseliot, to adjust a ton of values ...
<cjwatson> slangasek: hmm, no (I stopped after failing to reproduce the bug, foolishly), but I could get there in not too long
<ogra> ltsp is often used with HW thats really ancient
<tseliot> ogra:  you can use X-Kit to do it
<tseliot> ogra: it only depends on python
<ogra> tseliot, is that supported by fedora, gentoo and debian ?
<tseliot> ogra: not yet but it would be trivial to install it there
<ogra> note that ltsp tries to work distro independent, its maintained in a consortium ... all distro specifics i add for ubuntu have to be maintained separately
<ogra> note also that ltsp in 80% of the cases runs on HW that is to old to be properly detected
<tseliot> ogra: ok I see. Maybe when X-Kit is supported by those distributions then
<cjwatson> slangasek: I'm jigdoing it back down now
<ogra> i.e no DCC info from monitors and people ending up with 640x480
<tseliot> ogra: with X-Kit you decide what you want to change. It's just a parser/writer and a validator
<ogra> s3virge cards from 1996 ... for which you hardly find a supported driver but which can got working with a special set of options
<ogra> ltsp has scripts for that since yeras but these only work on a basic xorg.conf
<tseliot> ogra: I feel that the use case is good for X-Kit (which is only 2 files, BTW). Can't you include it in the ltsp packages?
<ogra> oh, and forget about python on a 48M thin client
<tseliot> ogra: ouch
<ogra> running the interpreter is already to heavy there (we used to have the display manager in python, tha forced a min req. of 128M on us ... which was the reason to rewrite everything in plain C)
<ogra> compcache mght help there, but i dont have enough time to even do all the ltsp packaging
<ogra> so changing big chunks of the X detection mechnanism is something i wont manage before release
<mdz> asac: neat
<ogra> getting hl-input proper there for the default set without xorg.conf was hard enough
<ogra> *hal
<ogra> and it still has its rough edges
<ogra> and is fedora/ubuntu only as of now ... which isnt really great
<tseliot> ogra: maybe we can talk about this at the next UDS then
<ogra> yeah, happy to
<ogra> for now i just dont want to tell users with very old HW that they are screwed
<tseliot> yes, I understand ;)
<ogra> for these parsing a generic xorg.conf is the only solution
<NCommander> ogra, trying to resolve the old vsync issue?
<NCommander> hsync/vsync
<ogra> NCommander, yeah, that and unsupported old cards
 * NCommander notes that anyone who has a laptop with a VIA card has been absolutely raped on that bug
<ogra> or "barely/badly" supported
<NCommander> Like my old thinkpad
<NCommander> er, Toshiba
<NCommander> the thinkpad just didn't like X period
<ogra> we even have still users with serial mice that run the input through gpm
<NCommander> I know people who still use XT keyboards
<NCommander> Hell, I have a real old AT Dvorak I keep around
<NCommander> ogra, the problem is even the newer VIA cards lie about their capabilities
<ogra> now these are the ones i have to tell to say goodbye to their moce, i doubt thats even remotely possible with the new input model
<ogra> *mice
<NCommander> I had to handwrite at least 20 lines of xorg to get my laptop to at least SYNC to the right resolution
<NCommander> and this was an '05
<NCommander> ogra, BTW, has anyone worked at implementing the GNOME exit box?
<ogra> hsync/vrefresh is a DCC value coming from the monitor
<ogra> *DDC
<ogra> ?
<ogra> hmm
<NCommander> I did it for Xfce 4.6
<ogra> well, a monitor value ...
<ogra> most old tube monitors dont report that properly
<NCommander> ogra, most VIA laptops just report the card, with no monitor P&P
<NCommander> ogra, this is an LCD :-)
<ogra> thast the biggest prob we have in ltsp ... which is often used in countries where a tube monitor from 1999 is the latest you can get
<NCommander> And if you screw up
<NCommander> Those old monitor burn up nice
<NCommander> What I would kill for is a program that could get the right ranges out of the windows drivers
<wgrant> Didn't displayconfig-gtk do that?
<NCommander> Nope
<NCommander> displayconfig-gtk won't give me the right sync ranges
<kelemengabor> mvo: ping
<kelemengabor> any progress on bug 254628 ?
<NCommander> er, refresh
<ubottu> Launchpad bug 254628 in app-install-data-ubuntu "Make it possible to translate eg. codec name/description strings" [Undecided,New] https://launchpad.net/bugs/254628
<NCommander> (I needed a refresh of 60, resolution of 1024x768, and some insanely high vsync)
<NCommander> bed time for me
<NCommander> I sleep beyond the reachs of time itself ;-)
<wgrant> NCommander: You sleep?
<ogra> heh
<NCommander> wgrant, 6-12 hours a night
<NCommander> Makes you wonder when I do Ubuntu magic
 * NCommander takes the 50 spot on the stats
<NCommander> w00
<NCommander> bed now
<mvo> kelemengabor: not yet, but the archive is still in (soft) freeze, so I can not upload
<cjwatson> slangasek: does an uninstallable virt-manager on the server CDs justify rerolling those?
<slangasek> cjwatson: is that in one of the tasks?
<slangasek> cjwatson: if the testing can get done in the next few hours, then I'm ok with rerolling if there's a fix fr virt-manager; if it can't, and virt-manager doesn't generally break the server install, I'd rather not re-roll since that would push the current candidate images off the server unless we fiddled first
<tkamppeter> persia, can you give me the e-mail address of balachmar? I need to contact him, he visits the IRC only for some minutes when I am not here.
<cjwatson> slangasek: it's not in one of the tasks AFAICS
<lemming> Hi!
<lemming> I have a small question
<lemming> Over make repository with gpg
<slangasek> cjwatson: ok; then I think everything's set to push the alpha out tomorrow morning, if someone can test edubuntu/i386 and (optionally) UbuntuStudio amd64 in the meantime
<slangasek> so I'm going to go get a bit of sleep
<persia> tkamppeter: I don't have such an email address.
<doko> sleep well
<cjwatson> lemming: I'm not sure I can figure out what your question is
<lemming> cjwatson, i'm making an oficial repository for Galician packages
<lemming> i'm using reprepro for this, but i don't know if this is the better option
<lemming> because i want do that one valid user upload a package in a specific folder this package go "automagically" to unstable repository
<lemming> but to do this i have to make a gpg key without password
<cjwatson> yes, you do
<cjwatson> archive keys usually need to be usable in an unattended fashion; you just have to keep the key material as secure as you can
<cjwatson> I'd recommend not allowing particularly widespread shell access to the machine in question
<lemming> ok
<lemming> i suposed it
<lemming> ;)
<liw> cjwatson, in the hardy ubiquity installer, when I go back from the final overview page to the partitioner, it forgets what I had told it (I'm having to use manual partitioning for this re-installation); is that known/intentional?
<cjwatson> liw: no, I think there's a bug for that
<liw> cjwatson, ack, then I won't file a new one
<lore20> hi
<lore20> does latest intrepid updates fix #233787 bug?
<lamont> pitti: infinity is in charge of the buildd chroots, not me.
 * liw sees the hardy installer still sets the tty flag to convert everything to upper case, heh
<cjwatson> that's not the installer, it's something random in some random unknown package
<liw> er, yeah, I knew that
<liw> syslog is shouting at me
<liw> but that's ok, it will work anyway
<cjwatson> you could be the one to figure out what's at fault! :)
<liw> cjwatson, I could, once I have a wokring machine again, and some time
<liw> t+5 hours 45 minutes until my UDW session, which I need to prepare, and that would greatly benefit from a working machine to run a VM on
<Mithrandir> liw: if it's t+, you're a bit late for preparing.  ITYM t-5:45. :-)
<liw> Mithrandir, t as in "now" :)
 * liw is confused, and therefore confusing
<cjwatson> liw: partitioner> bug 89093
<ubottu> Launchpad bug 89093 in ubiquity "Pressing [Back] loses all previously configured partitions" [Undecided,Confirmed] https://launchpad.net/bugs/89093
<liw> cjwatson, ack
<pitti> seb128: seahorse-plugins will get a reverse dependency by something (seahorse?) or should it get seeded?
<pitti> seb128: binary NEWed
<kwwii> pitti: I have package to fix the human theme bug...
<kwwii> http://sinecera.de/human-theme_0.23.dsc
<kwwii> http://sinecera.de/human-theme_0.23_source.build
<kwwii> http://sinecera.de/human-theme_0.23_source.changes
<kwwii> http://sinecera.de/human-theme_0.23.tar.gz
<kwwii> http://sinecera.de/ubuntu-artwork_44.dsc
<kwwii> http://sinecera.de/ubuntu-artwork_44_source.build
<kwwii> http://sinecera.de/ubuntu-artwork_44_source.changes
<pitti> kwwii: nice! thanks, will sponsor them
<pitti> kwwii: hm, ubuntu-artwork is already at 44 in intrepid
<pitti> kwwii: did you actually change something in there? If so, you probably need to reapply them to the existing 44 and reupload as 45
<fta> seb128, i just opened bug 265029 against gdm, not sure about the package, could be xorg or evdev
<ubottu> Launchpad bug 265029 in gdm "no mouse/keyboard when using evdev and autologin in gdm" [Undecided,New] https://launchpad.net/bugs/265029
<pitti> kwwii: human-theme change doesn't mention an LP #, doesn't it fix that milestoned bug?
<seb128> fta: I doubt it's gdm or will get a reply there but thanks
<pitti> kwwii: oh, BTW, human-theme-0.23/Human/gtk-2.0/gtkrc: "# Kenneth Wimar <kwwii@ubuntu.com>" -> you might want to fix your name :-)
<seb128> fta: you might have a better chance reassigning it to xorg
<seb128> pitti: thanks
<fta> seb128, the thing is it's just with autologin, so i started from there
<seb128> that's weird
<fta> seb128, it means when i reboot, i see my desktop fully loaded but i can't use it
<BenC> This is obviously off-topic, but is there a way to push a line back into a file stream in perl?
<kwwii> pitti: freaky, I wonder how that came about
<kwwii> thanks for noticing it :-)
<Treenaks> BenC: there's ungetc in IO::Handle objects.. but not much else
<kwwii> pitti: human-theme itself doesn't fix the bug, the ubuntu-artwork package fixes the bug
<superm1> slangasek, if the intent is just to describe DKMS and not how it's used for 8.10, then good
<cjwatson> there's an Unread method in the PerlIO C API, but I'm not sure if it's exposed at the Perl layer
<kwwii> pitti: although I guess it is how you look at it, because without the changes to human-theme the -artwork package wouldn't fix the bug either
<cjwatson> personally I think I might be inclined to use PerlIO::via
<pitti> kwwii: ok, as long as it is mentioned in either changelog, all is well
<pitti> kwwii: so you are prep'ing version 45?
<cjwatson> (unread does seem to be exposed in perlio::via)
<kwwii> pitti: it seems that my local copy was old...I can make a new source package with the correct version number, one second
<kwwii> pitti: in fact, I will fix the spelling error in human-theme and then give you new urls for both
<pitti> kwwii: alright :)
<kwwii> pitti: I'll send you an email to avoid posting more crap here
<pitti> kwwii: replied, u-artwork is still wrong
<BenC> Treenaks: looks like redo does what I want
<Treenaks> BenC: that restarts a loop block, it doesn't to things with filehandles
<BenC> Treenaks: while (<STDIN>) { ...; redo if foo }
<Treenaks> oh like that, yeah, that would work
<seb128> kees: could you look at bug #264229? the libtiff 7.10 security update has an issue apparently
<ubottu> Launchpad bug 264229 in tiff "libtiff4_3.8.2-7ubuntu3.1_i386 hoses Gnome panel" [Undecided,New] https://launchpad.net/bugs/264229
<seb128> oh, that one is hardy
<seb128> #264875 is a similar issue on gutsy
<kwwii> pitti: no worries, i just noticed that it won't build because of po problems
<kwwii> :-(
<kwwii> I have absolutely no idea how to do the PO stuff
<kwwii> boah, I take that back...sometimes I hate packaging
<RAOF_> pitti: Yay!  No more Xgl!  Thanks :)
<wgrant> It has finally died?
<RAOF_> It's no longer in Intrepid, at least.
<seb128> going to close all the bugs now? ;-)
<RAOF_> Hm. Should I?
<ogra> RAOF_, i thought you were so unhappy about that ?
<seb128> would be nice to close all those bugs yes, maybe ask on #launchpad if they can do that
<RAOF_> ogra: No?  Not really.  I was unhappy about the work needed to make it build again, but it's not really useful anymore.
<ogra> yeah
<RAOF_> (I would have had to bundle an old snapshot of the mesa source into the tarball, among other things.  Not pretty)
<RAOF_> But all that's solved by merely not trying to build it at all! :)
<pitti> kwwii: replied
<pitti> seb128: wow, new *blows the dust off* esound?
<seb128> pitti: yeah ;-)
<seb128> pitti: oh, forgot to reply to your question, nothing depends on seahorse-plugins, but maybe seahorse should Recommends it?
<pitti> seb128: yes, that's what I figured
<pitti> seb128: btw, for the spellcheckers, new lang-support packages are up; what was the tbird problem again?
<seb128> pitti: hunspell-* conflicts on thunderbird
<pitti> seb128: for -en-us only? others have a versioned conflicts thunderbird (<< 2.0.0.1+0dfsg-0)
 * pitti -> lunch
<seb128> pitti: hunspell-fr has the issue too, didn't look at all the variants
<seb128> pitti: enjoy
<seb128> hum, I've to run for a bit too, see you later
<seb128> dholbach: how busy are you? ;-) could you sponsor the gnome-themes and gcalctool updates? I've cleaned everything else on my sponsoring list but I've to run for a bit and I've other things to finish today and there is a new GNOME on monday, will try to do those later otherwise
<dholbach> seb128: will do
<seb128> lool: could you also look at the GNOME sponsoring request assigned to you? new GNOME is due on monday and they will be outdated before being uploaded otherwise ;-)
<seb128> dholbach: thanks
 * seb128 hugs dholbach
<seb128> anyway I've to run, be back later
 * dholbach hugs seb128 back
<dholbach> see you
<lool> seb128: I know it's a bad excuse for not spending time on sponsoring, but I spent too much time on GNOME tasks this week that this sponsoring should happen after some mobile work
<lool> ideally, I would tend to everything immediately, but I can't really spend the whole week doing GNOME stuff
<seb128> lool: understood, thank you for the GNOME work on did ;-)
<fta> seb128, regression with nautilus. custom icons on directories (on the desktop) are replaced by a white/gray page (instead of the picture)
<lool> seb128: I reviewed vino's proposed upload, it was a bit disappointing
<lool> seb128: pushed libwnck 2.23.91
<pitti> seb128: yay seahorse gpg agent \o/
<alex-weej> i've a question
<alex-weej> who is the "kernel team"?
<alex-weej> actually, launchpad!
 * RainCT remembers mvo that his branch is ready for merging (I finished the "another update manager is running" stuff which I still wanted to do yesterday) :)
<mvo> RainCT: great, thanks! but we are still in archive freeze :)
<robertj> hello all, can someone point me to any info on Canonical's hardware regression testing?
<thvdburgt> I have a question, I'm testing intrepid right now and when I open something I downloaded via the firefox download-dialog it does not respect my 'Open With' settings. Why isn't gnome-open or something similar used for this (I understand this opens it with the preferred operation)?
<ScottK> thvdburgt: You might have more luck with that question in #ubuntu-mozillateam
<thvdburgt> Thank tou ScottK, I'll ask there?
<asdasdas> hi, when the iso for alha 5 willl be available?
<asdasdas> I mean alpha 5
<ScottK> jdstrand: Do we want to recommend apparmor in clamav or suggest it?  Since we ship it by default, if a user has removed it, I think it's a little unfriendly to bring it back when they install clamav.
<jdstrand> ScottK: that could be said of any software with Recommends. I believe that it would be highly unusual to have an Ubuntu system without apparmor installed. That said, the ApparmorProfileMigration was developed before Recommends were turned on by default, and I don't have a particularly strong opinion about Suggests vs Recommends
<pitti> ScottK: personally I'd Suggests: it
<pitti> ScottK: Recommends: is very strong nowadays, and clamav works perfectly fine without AA
<jdstrand> ScottK: btw, after more than a month of use, of course *today* (right after uploading the debdiff), my production server compalined and needed an adjustment
<ScottK> jdstrand: I think suggests because apparmor or no apparmor is a global system decision.  It's not specific to clamav.
<ScottK> jdstrand: OK.  I'm just reviewing the patch now.
<jdstrand> both you and pitti make a good point-- I'll adjust the wiki
<ScottK> jdstrand: Does /tmp need to be in the profile?  I thought we patched clamav to not use it.
<jdstrand> ScottK: is that new to Intrepid?
<ScottK> No.
<jdstrand> (cause hardy certainly needs it-- it was a file in /tmp that cause AA to complain)
<ScottK> The upstream code uses /tmp, but I thought we had patches to use /var for everything.
<ScottK> OK.
<ScottK> jdstrand: Do you know what file?  It may be updating the patch to not use /tmp is what's needed.
<jdstrand> ScottK: can you use the files on a production hardy server somewhere in complain mode, and forward me any complaints?
<lool> seb128: pushed vino 2.23.91
<ScottK> jdstrand: I can.  How about you send me your update first?
<jdstrand> kernel: [1349877.940962] audit(1220610317.840:79): type=1503 operation="file_lock" requested_mask="k::" denied_mask="k::" name="/tmp/clamav-45625f80857577367ff15bc472e13446/.dbLock" pid=4903 profile="/usr/sbin/clamd" namespace="default"
<jdstrand> ScottK: the change is simply:
<jdstrand> /tmp/** krw,
<jdstrand> (it was 'rw')
<mpt> pitti, I'm resuming work on the Hardware Drivers design now
<pitti> mpt: good morning; great!
<ScottK> jdstrand: Looks like that one's not settable in the conf file, so we'll need /tmp.
<Riddell> cjwatson: I think I've got oem-config sorted for KDE 4 now, shall I upload or do you want to look at it?
<ScottK> jdstrand: OK.  Got it.  I'll try to do some testing and get back to you.
<jdstrand> ScottK: great!
<mpt> pitti, what's the maximum number of drivers likely to be shown in this window?
<mpt> at one time, I mean
<jdstrand> ScottK: my little production server isn't too busy (and doesn't use amavisd-new), so the testing is much appreciated
<pitti> mpt: hard to tell, but I guess you'd not have more than ten
<jdstrand> (and I really just smoke-tested amavisd-new, as you know_
<pitti> mpt: usually maybe two or three (graphics card, wifi, printer)
<mpt> ok
<ScottK> jdstrand: Right.  Well I think for amavisd-new it would either be just fine or not work at all.
<cjwatson> Riddell: feel free to commit it; best not to upload yet, though, as technically we're still in milestone freeze
<pitti> Riddell: hm, your jockey kde4 merge apparently broke the test suite for run-kde4 heavily; did you patch that out of do-release or so?
<pitti> Riddell: anyway, fixing now
<mpt> pitti, is it true that drivers will sometimes be installed via this window, but never uninstalled?
<pitti> mpt: no, you can uninstall them there, too; the "Enable" button will turn into "Disable" for installed drivers
<mpt> or are drivers uninstalled if you deactivate them?
<pitti> mpt: well, "depends"
<pitti> mpt: if enabling a driver entailed installing a package, disabling will uninstall that package again
<mpt> ah
<pitti> mpt: if we already ship the driver in our kernel, and the user disables it, it just gets blacklisted
<pitti> (e. g. because the user doesn't want non-free drivers)
<pitti> mpt: in general, disabling in jockey will undo all effects that enabling did
<mpt> So, activating a driver will sometimes require Internet access because it needs installing from there
<mkrufky> where can i find the licenses for the firmware images shipped in /lib/firmware/`uname -r`/ ?
<alex-weej> anyone know what needs to be fixed in order for "coretemp" to be automatically loaded on my system (to get sensors)?
<pitti> mpt: right
<alex-weej> i've a bug open against linux, doesn't seem to be going anywhere though
<pitti> mpt: or an Ubuntu CD, any apt package source; but in general this will be the internet
<pitti> Riddell: is there a pyqt/pykde equivalence for: gobject.timeout_add(1000, self.ui.on_quit)
<pitti> Riddell: i. e. the passed function will be called after one second?
<cody-somerville> How do I add a new e-mail address to an existing gpg key?
<pitti> cody-somerville: gpg --edit-key, then adduid
<pitti> cody-somerville: seahorse has a nice UI for this -- "Add Name"
<geser> cody-somerville: don't forget to send the key to the keyservers afterwards
<pitti> have a nice weekend everyone!
<cody-somerville> \o_
<Riddell> pitti: yes
<geser> pitti: you too
<Riddell> QTimer.singleShot(1000, self.foo)
<pitti> Riddell: rock, thanks
<vinu76jsr> new on this
<vinu76jsr> where to start
<pitti> Riddell: that's not from PyKDE4.kde{core,ui} (I'm working on jockey tests/run-kde)
<tseliot> pitti: that's qt4 not kde4
<pitti> Riddell: right, but from PyQt4 import QTimer doesn't work either
<pitti> ah, PyQt4.Qt.QTimer
<vinu76jsr> not a place to ask ! sorry developers!!!
<tseliot> pitti: PyQt4.QtCore.QTimer I guess
<pitti> Riddell: rocking, that works, and fixes the segfault I'm getting when using gobject's timer
<pitti> tseliot: yep, thanks
<Riddell> yay
<tseliot> Riddell: doesn't KDE4 have a suspend button?
<Riddell> tseliot: how do you mean?
<pitti> ok, really off now, I'm late
<tseliot> Riddell: so as to suspend my laptop (as in suspend/resume)
<tseliot> I can see log out, shutdown but no suspend button
<Riddell> tseliot: either right click on the battery icon (guidance-power-manager) or on the logout dialogue the confusingly hidden hold mouse button on Turn Off
<Riddell> it was in our intrepid plan to tidy up the logout dialogue but it hasn't happened thus far
<tseliot> Riddell: ah, ok, thanks
<cjwatson> vinu76jsr: see http://wiki.ubuntu.com/ContributeToUbuntu
<vinu76jsr> thanx
<calc> how is alpha 5 going?
 * calc is waiting to upload new OOo 2.4.1 w/ openjdk until its safe
<seb128> lool: thanks
<mpt> pitti, e-mailed you a new mockup
<kees> seb128: thanks for the heads-up, I will investigate.
<seb128> kees: thanks
 * kees wonders if there is still some bug sneaking around in the troublesome libxml2 update.
<kees> seb128: I cannot reproduce the issue.  Additionally, the 2nd comment seems to indicate it wasn't libtiff4 (and I see no new bugs for libxml2)
<kees> I wonder if something else is going on?  I will try again on 64bit...
<seb128> kees: it's obviously not happening to everybody or we would have received lot of bugs, but 2 bugs mentionning libtiff just after the update seems a weird coincidence so I prefer to point it
<seb128> kees: could be trigger by some applet used or something dunno
<seb128> the bugs don't have so many details
<kees> seb128: yeah, it makes me worry a bit too.  I'll try to get more details
<jdstrand> kirkland: so I'm sure you've probably heard all kinds of arguments for and against auto-umount
<jdstrand> kirkland: one thing I might point out that may influence your decision is that I had my ~/Private directory auto-umounted
<jdstrand> then I tried to start firefox (I moved the .mozilla dir to ~/Private and symlinked it)
<jdstrand> this totally made ff not start at all
<jdstrand> apparently, firefox checks for .mozilla, but gets confused cause it's a broken symlink
<jdstrand> kirkland: if we start recommended ecryptfs for things like .mozilla, .ssh and .gnupg, then this will at the very least need to be documented
<jdstrand> kirkland: or somehow make it smarter so that it only auto-umounts when logging out from the session that was used to auto-mount it
<jdstrand> kirkland: eg, login via gdm, logout of gdm auto-umounts it...
<jdstrand> kirkland: what do you think?
<jdstrand> (and by not start at all, I mean there was no feedback as to what happened-- I had to strace ff)
<kirkland> jdstrand: actually, i'd like to use a trigger, like inotify or some such to auto-mount on demand, when necessary
<kirkland> jdstrand: but I don't know inotify well enough to hack that just yet
<jdstrand> kirkland: assuming that can be done safely and reliably, that would be cool too
<kirkland> jdstrand: as for the documentation, i absolutely agree
<kirkland> jdstrand: i will create an Encrypted Private "Best Practices" wiki page prior to Intrepid release
<kirkland> jdstrand: with some do's and don'ts
<kirkland> jdstrand: one really nasty gotcha is moving .ecryptfs into Private
<jdstrand> kirkland: sounds good-- you might mention the caveats/workarounds for things like the firefox issue I had
<kirkland> jdstrand: that's VERY BAD NEWS
<kirkland> jdstrand: true, i'll sign you up for review of that documentaiton
<jdstrand> sure
<calc> slangasek: ping
<slangasek> calc: pong
<calc> slangasek: how's the a5 freeze coming? :)
<calc> i didn't see the announcement go out yet so i assume its still frozen anyway
<calc> "Options
<calc> * More About Barton * Less About Barton
<calc> * More Status Stories * Fewer Status Stories
<calc> Options
<calc> Barton George | After 13yrs, today is Barton's last day at Sun. Its been a blast! (taking Sat & Sun off before I start the new job on Monday :)."
<calc> hmm copy & paste on facebook embeds stuff you don't see (garg)
<calc> sorry about the several lines of crap
<Treenaks> calc: some PDFs do that as well (from evince)
<Treenaks> I've gotten into the habit of test-pasting in a spare terminal
<calc> Treenaks: yea :-\
<slangasek> calc: I haven't seen anything blowing up, so I think you're ok to upload now; a5 should be out very shortly
<Treenaks> hm, I think some timer is going bad on my box:
<Treenaks> 28161 martijn   20   0  781m  97m  25m S    1  2.5  1708779h rhythmbox
<calc> slangasek: ok thanks! :-)
<emgent`nl> heya
 * calc uploading OOo 2.4.1-8ubuntu1 now
<slangasek> superm1|away: "describe how it's used" - you mean from a developer's perspective?  I think we want this to be end-user-oriented, so yeah
<jdong> calc: so that means the rest of us (tm) can't build anything for a few days, right? :)
<toresbe> Hello. I have what appears to be a kernel bug where the kernel fails to see my PATA disks. I will report it to Launchpad, but is there anything anyone would suggest I do, either to address the problem, or to supply meaningful additional info to the bug report?
<toresbe> I've already got dmesg, lspci -vvv and fdisk -l in.
<calc> jdong: there are three buildds per arch iirc
<tseliot> slangasek: if you're referring to DKMS, can I have a look at what you prepared for the release notes?
<mvo> RainCT: hello, are you around?
<slangasek> tseliot: https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview#DKMS
<slangasek> tseliot: s/release notes/technical overview/
<tseliot> slangasek: it looks good to me
<tseliot> slangasek: are you going to add a warning about the NVIDIA and ATI drivers in the Known Issues section?
<slangasek> tseliot: I'm not writing anything up for alpha-5; that's on the list of things to document for the release notes for final, if it remains unresolved
<tseliot> slangasek: ok, it makes sense. Let's wait until the final release
<mvo> RainCT: I merged your apturl changes, many thanks, excellent work! please re-merge, there is a minor correction I did
<slangasek> _MMA_: there still don't appear to have been any successfully completed tests of UbuntuStudio for alpha-5; I'm going to release the others, and if Studio gets some testing, it can be pushed out after
 * calc fixed his upload problems :)
<slangasek> you shrank the OOo code to < 5MB?
<jdong> slangasek: mv abiword openoffice.org? :)
<ion_> LyX! :-)
<jdong> vi!
<tech404> Does anyone know if/why util-linux is still using volid? The change log suggests that the maintainers plan to move to blkid for intrepid but I can't find much more info on it. Is there a reason we have decided not to stay with debian on this one?
* slangasek changed the topic of #ubuntu-devel to: alpha-5 released | archive: open, feature freeze in place | 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
<slangasek> superm1: mythbuntu also not included in alpha-5 yet, but I'm holding the cronjob if you want to test it and let me know it's ok to release
<superm1> slangasek, yeah one of our people should be pulling it to test
<superm1> i'll let you know
<cjwatson> slangasek: I did a very basic but successful ubuntustudio test, fyi
<cjwatson> only just had a chance to tell iso.qa about it
<_MMA_> cjwatson: Ill be doing one in about an hour. I had to scrounge some real HW to use 'cause of Vbox issues.
<cjwatson> hey, the ubuntustudio gdm screen is pretty classy
<_MMA_> :P
<cjwatson> not sure I like the desktop theme as much, never been much of a metal kind of guy
<cjwatson> err, I meant to say brushed-metal, damned lag
<slangasek> cjwatson: ah, ok, great
<slangasek> (.oO brushed-hiphop)
<_MMA_> Well, it's more in line with pro multimedia apps (the dark theme). That's our target audience. :) Brushed metal? The wallpaper has a hex pattern to it atm. :)
<cjwatson> I'm not sure I'm using the right term, it's just what it reminds me of. :)
<_MMA_> :)
<cjwatson> anyway, I'm not so much your target audience
<_MMA_> Sure. ;)
<_MMA_> cjwatson: Thanx for the test btw.
 * NCommander has found MIPS hardware
<NCommander> Wooo
<calc> doko: is openjdk-6 known to work properly on sparc?
<calc> doko: OOo failed to build using default-jre due to:
<calc> Checking DLL ../../unxlngs.pro/lib/check_libofficebean.so ...: ERROR: libmawt.so: cannot open shared object file: No such file or directory
<calc> not sure what caused that error though
 * calc will see how the other buildds react over the next few hours
<kees> pitti, slangasek, NCommander: I seem to have been missing from an important conversation.
<kees> through the magic of backlog temporal shift...
<kees> 06:22 < NCommander> slangasek, 15% of main alone FTBFS due to PIE/non-PIE linkages
<kees> I don't believe that to be true at all.
<kees> there are tons of reasons things don't compile with PIE.
<kees> 06:32 < NCommander> slangasek, at least you confirmed for me the -fPIE issues weren't quite so bad as kees made them sound to be
<kees> I'm not sure I ever said it was "so bad".  I just said we needed to carefully examine the .a file usage.
<kees> 06:36 < NCommander> slangasek, every executable still needs to be rebuilt with -fPIE
<kees> no need for "needs".  It'll all happen naturally.
<kees> 07:14 < pitti> do we actually need that new arch in soyuz? that's a quite expensive operation; wouldn't a local archive do as well?
<kees> a separate arch would be massive overkill
<doko> calc: please check that the correct pathes are used. it's likekey that OOo hardcodes something. this file lives in an arch specific dir
<NCommander> kees, we decided that :-)
<kees> 07:18 < slangasek> it shouldn't be that difficult, the static libs that need to be built should be identifiable by visual inspection
<kees> and, yeah, that's what I said.  :P
<NCommander> Can I say that this conversation happened early this morning when I should have been alseep?
<kees> haha
<kees> well, it happened while I _was_ asleep.  I just want to speak for myself is all.
<ion_> pitti, tkamppeter: http://heh.fi/patches/cups/01-pstopdf-ppd-settings
<ion_> pitti, tkamppeter: Updated
<tkamppeter> ion_, looks OK for me. pitti has probably already left for today.
<tkamppeter> ion_, for the question you asked me in private, CUPS does not have a PPD parser to be used from scripts.
<ion_> Yeah, i noticed the answer, thanks
<ion_> It works with the sed hack, itâs just ugly. :-)
<cameronh> i need to restart avahi-daemon every few minutes or else it stops working (ping blah.local elsewhere won't respond, broadcast shares won't pick up)
<lool> Kudos to the release team for the a5 release
<mdke> yes, intrepid is looking pretty nice already
<ion_> tkamppeter: Iâm not sure any changes are needed in testprint.ps. If someone *really* wants the printer to run the code, sheâs free to nc printer 9100 <testprint.ps
#ubuntu-devel 2008-09-06
<m0u5e> why does ubuntu have so many image viewing programs by default? don't we really just need one?
<_MMA_> ï»¿slangasek: Please push the Alpha for Studio. I'm happy with the tests I've done.
<slangasek> _MMA_: ack, will do shortly
<_MMA_> Thanx.
<slangasek> kirkland: nice manpage site!  title searches seem to be exact-match only?
<wgrant> Hmm.
<wgrant> How do I use it?
<wgrant> Nothing on the homepage seems to do anything.
<wgrant> Ah, I see. The top-right.
<doggymenz> ubuntu needs be able to install apps without root access
<doggymenz> and install it for this user only, not for all users
<slangasek> m0u5e: what image viewing programs are you referring to, specifically?
<wgrant> We have f-spot and eog... or do we still have gthumb?
<m0u5e> no we dont have gthumb
<m0u5e> but i know that fspot and eog come by default
<m0u5e> i thought there was one more...
<m0u5e> anyways, last time i checked i think the default viewer doesnt support gifs
<m0u5e> animated* gifs
<slangasek> f-spot isn't an image viewer, it's a photo manager
<slangasek> I'm not thinking that we want to launch f-spot for every image view :)
<slangasek> was ttf-liberation still being considered as a default for intrepid?  It's in main but doesn't seem to get pulled in by default
<slangasek> _MMA_: studio alpha-5 published, cronjob restarted
<slangasek> s/started/enabled/
<LaserJock> sebner: ping?
<_MMA_> slangasek: Thanx. :)
<wgrant> Hmmm, I'm currently using the alpha 5 i386 desktop CD, and it's thoroughly broken.
<wgrant> I have alphanumerics, ctrl, alt, shift, but not much else.
<wgrant> No arrow keys, home, end, delete...
<wgrant> Hmm, and my code doesn't think my touchpad is a touchpad.
<wgrant> X seems confused.
<LaserJock> wgrant: did it work in pre-alpha5 Intrepid?
<wgrant> LaserJock: I last upgraded on this machine about 48 hours ago.
<wgrant> So it could have broken in that time.
<wgrant> But it works flawlessly on my existing installation on this machine.
<wgrant> Hm.
<wgrant> Now that I've restarted X, the keyboard works fine.
<wgrant> Probably that HAL race.
<wgrant> And these images are too old for my touchpad fixes. That explains it.
<LaserJock> kirkland: wow, manpages.ubuntu.com is not intuitive at the start. You might want to add some sort of explanation to the top of the pages
<wgrant> LaserJock: +1
<kirkland> LaserJock: fair enough...  we'll improve the initial index.html page
<LaserJock> kirkland: yeah, just needs a "use the search box to find manpages" notice or something
<kirkland> LaserJock: I wish I had write access to that machine...  unfortunately, I don't
<LaserJock> I thought it was empty and nothing was very clickable
<kirkland> LaserJock: thanks for the input... i'll commit some changes to bzr, and drop a note for IT to pull those changes
<kirkland> LaserJock: would it have helped any if the starting page was http://manpages.ubuntu.com/manpages/
<LaserJock> kirkland: I guess what I was expecting was an alphabetical listing
<LaserJock> that page would have at least helped, but it's also somewhat confusing
<LaserJock> when you go to an individual release there are language codes
<LaserJock> I clicked on en and didn't find much
<LaserJock> it's only now I see the manX links
<NCommander> hey LaserJock & kirkland
<cjwatson> Riddell: could you please commit your change to oem-config that finalised 1.48, preferably using debcommit -r so that it sets the right tag and stuff?
<cjwatson> Riddell: thanks for the fixes
<cjwatson> Riddell: I don't suppose that fixed bug 245228 along the way?
<ubottu> Launchpad bug 245228 in oem-config "oem-config layout is broken on Kubuntu KDE4" [Medium,Triaged] https://launchpad.net/bugs/245228
<cjwatson> Riddell: also this looks a bit odd in oem-config-prepare:
<cjwatson>                         if [ -x /usr/lib/kde4/libexec/kdesu.distrib ]; then
<cjwatson>                                 kdesu=/usr/lib/kde4/libexec/kdesu.distrib
<cjwatson>                         elif [ -x /usr/lib/kde4/libexec/kdesu.distrib ]; then
<cjwatson>                                 kdesu=/usr/lib/kde4/libexec/kdesu.distrib
<cjwatson>                         fi
<Riddell> cjwatson: committed.  yes it should fix that bug.  commited a fix for that if elif
<cjwatson> Riddell: thanks
<balachmar> tkamppeter_: You requested my e-mail: wligtenberg  --AT-- gmail -- dot -- com (Don't know how good those e-mail parsers are...
<Martiini> You can tell Steve Langasek that Intrepid alpha-5 cd  (intrepid-desktop-i386.iso) does not boot on HP dv6565en (HP dv65000 series). kernel does not load at all
<cjwatson> Martiini: please file a bug rather than trying to tell the release manager directly; one person doesn't have to fix all bugs in Ubuntu :)
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
<askand> Hi, why are you including a recently written software for making usbinstallations when there is one that has been around for a while and works just fine?
<askand> I have contacted the developer of liveusb ( https://launchpad.net/liveusb ) and he is happy to merge the projects
<Hobbsee> askand: define 'you' here?
<torkel> askand: you will probably get a better answer asking on the mailing list than here, especially since it is weekend
<askand> Hobbsee: You as in developers :) torkel: ok thanks
<Hobbsee> askand: which is the one that we're supposedly writing?
 * Hobbsee hasn't heard about this.
<ScottK> Hobbsee: Do you have enough experience with seed management (and time, interest, etc.) that you could help me figure out why clamav-doc didn't make it into supported?
<askand> Hobbsee: https://lists.ubuntu.com/archives/intrepid-changes/2008-September/006362.html
<Hobbsee> bug 263551
<ubottu> Launchpad bug 263551 in ubuntu "[FFe] Please accept usb-creator 0.1" [Undecided,New] https://launchpad.net/bugs/263551
<Hobbsee> askand: ahh
<Hobbsee> ScottK: well, clamav-doc doesn't exist :)  I presume you mean clamav-docs
<ScottK> Ah.
<Hobbsee> ScottK: are you asking about intrepid ubuntu?
<ScottK> Yes.
<ScottK> Hobbsee: clamav is in server-ship now.
<ScottK> Germinate picked up everything I expected except that.
<Hobbsee> ScottK: are you aware that -docs is only a suggests of clamav?
<ScottK> Hobbsee: Yes, but the extra-include in supported has a regex match on -doc packages.
<ScottK> Now that you mention it, I expect -docs doesn't match.
<ScottK> I'll go look at that.
<Hobbsee> that's where i'd start looking.
<ScottK> Thanks for the hint.
<Hobbsee> y/w
<ScottK> This is the first time I touched the seeds directly, so the fact that nothing caught on fire and I merely missed one -doc package feels like a big win.
<cjwatson> ScottK: indeed, it'll be because it's called -docs. Feel free to add *-docs to Extra-Include
<cjwatson> (or rename the package)
<ScottK> cjwatson: OK.  I just added clamav-docs explicitly, I'll go back and add *-docs.  Thanks.
<ScottK> Done.
<cjwatson> askand: on the other hand, liveusb isn't in Ubuntu ...
<cjwatson> askand: it looks like liveusb is a fairly recent project as well, and perhaps Evan just didn't realise it existed until he was already pretty far down the road of writing his own
<cjwatson> that sort of thing does happen sometimes
<askand>  cjwatson: perhaps, all I know is that liveusb  has been around for a bit longer and therefore had users that reported bugs that has been fixed :) and usb-creator wasnt in ubuntu before 3 sep
<cjwatson> right, it just evidently didn't get noticed in the right place
<askand> cjwatson: anyhow i wrote a comment in the bugreport if they want to work together :)
<cjwatson> I'm unable to see when the feedback request on https://blueprints.launchpad.net/ubuntu/+spec/usb-installation-images was left. Did the liveusb developer notice that that specification existed and was assigned to somebody?
<askand> It was propably left there today, i told the liveusb developer of the other projects existence today
<cjwatson> I agree that it would make sense to pool efforts, although without yet having run either of the programs I can't make a judgement about which is better
<cjwatson> they seem to have similar feature sets from just looking through the code
<cjwatson> it doesn't look as though anyone mailed any of the usual mailing lists about liveusb
<cjwatson> (I checked ubuntu-devel, ubuntu-devel-discuss, and ubuntu-installer)
<askand> cjwatson: no, i dont think the liveusb developer was aware that such a feature was wanted for intrepid
<askand> as default
<cjwatson> right, so he didn't realise we were doing something and we didn't realise he was doing something; such things happen sometimes :-(
<askand> yep :)
<ScottK> Anyone else having trouble with builds on lpia?
<ScottK> I'm not quite sure what to do about "configure: error: C compiler cannot create executables" when the package builds on other archs.
<ScottK> OK.  Looks like the next upload had the same issue on lpia:
<ScottK> checking for C compiler default output file name... configure: error: C compiler cannot create executables
<ScottK> doko: It seems since your latest gcc4.3 upload (I think) lpia builds are failing.
<ScottK> http://launchpadlibrarian.net/17347626/buildlog_ubuntu-intrepid-lpia.clamav_0.93.3.dfsg-1ubuntu1_FAILEDTOBUILD.txt.gz is one such build log.
<devfil> ScottK: I have the same problem with opencascade
<devfil> checking for C compiler default output file name...
<devfil> configure: error: C compiler cannot create executables
<ScottK> It may just be archive skew too sinced the new gcc build is published on i386 (if there are arch all components),  but lpia is still building.
<ScottK> Or not.  I was looking at ia64.
<doko> no, it's all in the archive
<ScottK> Right.
<ScottK> doko: Looking, I don't see that any lpia builds have succeeded since it would have hit.
<doko> hmm, there seems to be a problem on i386 as well. I can't reproduce it yet in a local chroot
<geser> doko: i486-linux-gnu-gcc: error trying to exec 'cc1': execvp: No such file or directory
<geser> from config.log from a build on PPA (http://launchpadlibrarian.net/17348817/buildlog_ubuntu-intrepid-i386.antigrav_0.0.3-2build2~ppa1_FAILEDTOBUILD.txt.gz)
<doko> yes, seen as well: http://launchpadlibrarian.net/17348728/buildlog_ubuntu-intrepid-i386.fastjar_2%3A0.96-0ubuntu1~ppa1_FAILEDTOBUILD.txt.gz
<doko> now tell me why ...
<broonie>  /win 19
<doko> geser, ScottK: it looks that the buildd doesn't have the 4.3.x symlinks in some cases, look at
<doko> http://launchpadlibrarian.net/17348877/buildlog_ubuntu-intrepid-i386.fastjar_2%3A0.96-0ubuntu1~ppa2_FULLYBUILT.txt.gz (ok)
<doko> http://launchpadlibrarian.net/17348867/buildlog_ubuntu-intrepid-amd64.fastjar_2%3A0.96-0ubuntu1~ppa2_FAILEDTOBUILD.txt.gz (missing)
<doko> but they are in the archive ...
<ScottK> Odd.
<doko> ahh, it's a wrong version in a Replaces ...
<doko> now, let's see how to build that ...
<wujciol_> I've got question about Bazaar
<wujciol_> I pushed revision on branch but on project website lastest revision is not me but older
<ScottK> wujciol_: I'd suggest #bzr
<doko> gcc-4.1 doesn't like me: cc1: error: unrecognized command line option "-Wno-overlength-strings"
<ion_> pitti, tkamppeter: I rebased the CUPS patch against svn.
<_MMA_> Is art licensed under CC-by-ND allowed in the archive? If not, is there a link to this policy? (even a Debian one if we follow that)
<ion_> In multiverse, why not?
<_MMA_> Universe.
<ion_> IIRC ND means no derivatives, thus it isnât a free license.
<_MMA_> Im guessing no but Im trying to make sure its the same for us. If I had to bet its a no for Debian.
<geser> _MMA_: it fails point 3 from the DFSG (http://www.debian.org/social_contract.html#guidelines)
<_MMA_> Sure
<emet> what if Ubuntu got some kind of welcome screen for newbies
<cody-somerville> Then I'd cry
<emet> kind of like a out of box experience "Tour Ubuntu" type application
<_MMA_> The world would end.
<emet> lol
<_MMA_> Puppies would die.
<cody-somerville> God will kill kittens
<Nafallo> oooh
<Nafallo> what do I need to do? :-)
<_MMA_> Nafallo: Smite all notions of a 1st run/tour Ubuntu app.
<Nafallo> I wouldn't like that.
<ion_> We could make an arrow slide from the other side of the screen towards the application menu and then bump against it a couple of times. And patent tha.
<ion_> t
<Nafallo> lol
<emet> but I am seeing a lot of misconceptions about how to install software on Ubuntu
<cody-somerville> Same here
<emet> like newbies going to download.com or something, no joke
<cody-somerville> I think we should force new users to enrol in a course :-]
<emet> but when you think about it, and you are someone completely new to Linux or Ubuntu, you go and install Ubuntu - how are you suppose to know?
<emet> so that's why I think something, maybe a docbook pop up that explains what the hell to do after Ubuntu installs
<_MMA_> Isn't what FF does when 1st run?
<emet> yeah something like that
<cody-somerville> except its ineffective at what it does.
<ion_> Hm. I donât think iâve ever *read* the Firefox Ubuntu start page. :-)
<emet> is there a channel for ubuntu documentation development?
<cody-somerville> ember, yes
<cody-somerville> #ubuntu-doc
<devfil> can someone explain me why language-support-translations-it depends on thunderbird-locale-it?
<devfil> thunderbird isn't installed on a default installation, install the italian translation will install also it
<jpds> devfil: They are "Additional translations", as per apt-cache show.
<cody-somerville> devfil, Depends: thunderbird | language-support-it
<devfil> in intrepid it install thunderbird
<cody-somerville> Don't install language-support-translations-it then
<cody-somerville> install language-support-it
<devfil> cody-somerville: language-support-it depends on language-support-translations-it
<cody-somerville> I'm aware of that
<cody-somerville> But if you install language-support-it, then the dependency of thunderbird-locale-it will be met and thunderbird won't be installed
<_MMA_> language-support-it depends -> language-support-translations-it -> ï»¿thunderbird-locale-it -> Thunderbird. Last I knew.
<devfil> _MMA_: you're right
<devfil> so all italian users will have thunderbird installed...
<cody-somerville> I'll try it on my Intrepid box later today
<cody-somerville> on Hardy, it works as expected.
<devfil> cody-somerville: language-support-it isn't installed, it depends on thunderbird-locale-it, so it install thunderbird
<devfil> in order to install language-support-it
<Savago> Hello friends.
<Savago> Is there any *huge* side effect by installing an intrepid package in Hardy?
<ion_> If all its dependencies are in hardy, it should work but you wonât get security updates to it automatically. Now please read the topic.
<Savago> ion_, thanks a lot. :-)
<cjwatson> devfil: thunderbird-locale-it should depend on thunderbird | language-support-translations-it rather than thunderbird | language-support-it. That's a bug; please file it
<devfil> cjwatson: are you sure?
<cjwatson> yes.
<devfil> if I install -support-it
<devfil> it install thunderbird-locale-it in order to install language-support-translations-it
<cjwatson> yes, but this will at least stop it installing thunderbird too.
<cjwatson> we have no way to implement anything more fine-grained in the package manager right now; there's no way to say "if thunderbird is already installed then depend on thunderbird-locale-it". Installing an extra locale package that isn't needed (but at least not pulling in the extra application) is the lesser of two evils.
<devfil> cjwatson: yes ok
<devfil> a dep between them is ok
<cjwatson> devfil: actually, don't worry about that bug, I'll just fix it now
<devfil> thanks
<cjwatson> p.s. it's not Italian-specific, I fixed it for all languages
<devfil> cjwatson: oh, goos
<devfil> *good
<devfil> I don't use evolution, it is really frustrating to have also thunderbird installed
<devfil> :)
<gattaca> I have a vmware issue on gentoo .... its obscure ... perhaps someone skilled enough is willing to throw a hint my way
<gattaca> i'm running vmware workstation 64bit for linux 6.0.5 (as of a few minutes ago) on a current linux smp 64bit kernel (core2 duo with 2gb ram for the vm, no swapping) ... i have a virtual machine setup with current tools installed along with all updates ... the guest is a windows xp pro sp3 32bit smp system ... xp reports 100% combined cpu usage on two cores, while top in linux reports about 50% combined usage with no iowait and about 50
<gattaca> gentoo ... lol ... ubuntu
<_MMA_> gattaca: In the end, this is a development channel and the weekend. Not the place and gonna be slow here.
<gattaca> i think it could be hard coded into a vmware kernel module or background service ... just hoping someone else ran into this
<cody-somerville> If someone has, I bet you'll find the answer via google ;]
<gattaca> go ahead and look ... i've been on this for 17 hours non stop
<gattaca> the last thing i want to do is distract you guys from the important work i love ;)
<gattaca> ... yet, i am here.
<cody-somerville> :-)
<gattaca> on another note, my coding skills have come a long way .... is there a svn or git repository somewhere i could study off of?
<gattaca> one day i'd like to be in here permantly
<wgrant> svn or git repository for what?
<wgrant> We have an awful lot of code...
<gattaca> low level stuff is mostly what i understand
<gattaca> ... and security.
<_MMA_> gattaca: Best I can say is to try to get involved in something you care about.
<toresbe> gattaca: I've got to say, entering the Ubuntu developer's discussion forum and asking a Gentoo user support question is... ahm, ill-advised.
<_MMA_> toresbe: He corrected himself.
<gattaca> gentoo was a typo .... my bad. its ubuntu.
<toresbe> oh, sorry, I misunderstood, pardon me.
<gattaca> iv'e been using ubuntu as a primary, opensolaris as secondary, and osx as third for about 8 years now ... the windows stuff confuses me, always has, even for the 12 years i used it before becoming enlightened
<toresbe> Still; it's a user question, this is a developers' channel; it's not the place for it.
<_MMA_> toresbe: And he's been told.
<gattaca> k ... consider it dropped.
<gattaca> i'll be back ...
#ubuntu-devel 2008-09-07
<NCommander> doko, mind if I ask some glibc questions?
<doko> just ask
<NCommander> doko, to configure glibc to go into /lib32, vs /lib, it appears I need to set a few configure flags, but I'm kinda stumped on which ones those might be, and I was hoping you would know
<doko> hmm, the current glibc package should work fine. afaicr we move things around after the build
<NCommander> doko, I'm not building the package, sourceful build; I'm rebootstrapping the toolchain from scratch using a different set of CFLAGS (-fPIE/-fPIC enabled by default)
<doko> sorry, don't know this by heart
 * NCommander nods
<NCommander> You work more with GCC itself vs. glibc if memory serves
<doko> and it's 2am here, so maybe post to the list
<doko> yep
<NCommander> doko, you always ack my m68k toolchain patchs in Debian so thank you for that and your assistance ;-)
<ScottK> doko: Still no luck on lpia.  I retried clamav and it failed with the same error and I don't see any successful lpia builds today.  I verified from the build log that gcc-4.3 4.3.2-1ubuntu4 was used.
<ScottK> http://launchpadlibrarian.net/17354296/buildlog_ubuntu-intrepid-lpia.clamav_0.93.3.dfsg-1ubuntu1_FAILEDTOBUILD.txt.gz
<NCommander> doko, is there a way I can place the -fPIE flag somewhere will it will only affect compilation and linking against 64-bit (-m64) targets, but not the 32-bit ones in a biarch compiler
<ScottK> doko: Not just lpia either: http://launchpadlibrarian.net/17356138/buildlog_ubuntu-intrepid-ia64.kdelibs_4%3A3.5.10-0ubuntu3_FAILEDTOBUILD.txt.gz
<lukehasnoname> so is it known/acceptable that I can't put LVM on top of encryption?
<cjwatson> lukehasnoname: known, bug 267048. I think it's also Debian bug 494910 which would make it an easy fix; I'll look at it when I'm more awake
<ubottu> Launchpad bug 267048 in partman-crypto "partman-lvm cannot access luks-crypted newly-created partition" [Undecided,New] https://launchpad.net/bugs/267048
<ubottu> Debian bug 494910 in partman-crypto "partman-crypto: No longer allows to manually create LVM on crypto setup" [Serious,Closed] http://bugs.debian.org/494910
<lukehasnoname> mk, just wanted to make sure that was a predictable occurance.
<geser> doko: should gcc-4.3 (4.3.2-1ubuntu4) be good again?
<ScottK> geser: It's not.
<doko> geser, ScottK: what does 'ls -l /usr/lib/gcc/*' say on your local machine?
<geser> on my local machine the symlinks are there
<doko> geser, ScottK: thanks, sent email to ubuntu-devel. but I suppose we'lll have to wait for infinity or cprov-afk to have a look at the buildds
<ScottK> doko: I also see the problem on ia64 and hppa:
<ScottK> http://launchpadlibrarian.net/17360353/buildlog_ubuntu-intrepid-ia64.kdelibs_4%3A3.5.10-0ubuntu3_FAILEDTOBUILD.txt.gz
<ScottK> http://launchpadlibrarian.net/17356476/buildlog_ubuntu-intrepid-hppa.kdelibs_4%3A3.5.10-0ubuntu3_FAILEDTOBUILD.txt.gz
<ScottK> Additionally, it looks like primero (hppa) is broken in it's own special way as Hardy builds are dying there due to CHROOT problems.
<EagleSn> hi
<EagleSn> i am making a patch for a package, i am using: diff original.source.folder edited.source.folder > patch.diff
<EagleSn> i am using it well?
<cjwatson> EagleSn: diff -ru
<cjwatson> (never use diff without the -u option)
<cjwatson> if you created new files, diff -ruN
<EagleSn> -run == -Nur
<cjwatson> incorrect, -n != -N
<EagleSn> thanks you
<EagleSn>  if i want to build a new binary debian package with my patch applied, i think i have to make debian/patched folder and copy my patch into, then debuild will apply my patch automatically, am i right?
<ion_> pitti, tkamppeter: Rebased the CUPS patch again.
<cjwatson> if there isn't a debian/patches directory already, you should just apply the patch rather than adding a patch system
<EagleSn> cjwatson than my patch wont be in the sources
<ion_> pitti: Btw, using ${vcs}-buildpackage or equivalent would entirely remove the possibility of local changes sneaking into diff.gz. :-)
<fta> since 2.6.27, top and ps are acting strangely... http://www.sofaraway.org/ubuntu/tmp/top.gif
<fta> (look at %cpu)
<EagleSn> hi
<cjwatson> EagleSn: what makes you say your patch won't be in the source if you just apply it directly?
<cjwatson> EagleSn: (obviously if there already is a debian/patches/ directory then it's usually best to add the patch there.)
<EagleSn> yeah
<EagleSn> then i apply my patch directly to sources
<EagleSn> patch -p1 routr/to/my/patch
<EagleSn> i will submit my patch in Launchpad, then i want to make it correctly
<cjwatson> EagleSn: you should follow https://wiki.ubuntu.com/PackagingGuide/Howtos/Debdiff, then
<EagleSn> i already have read it
<EagleSn> but the patches i usually see in surces are not debdiff, they are diff or patch extension
<cjwatson> it's the same format
<cjwatson> you can apply any of them with patch
<cjwatson> the debdiff program just ensures some basic level of consistency in how the patch is created, and so is preferred for patches submitted as Ubuntu bug reports
<EagleSn> gpg gives me error at singing, it is as my passphrase was incorrect
<EagleSn> is any way to see my passphare for gpg? i dont use it since much time ago, may be i am typing it wrongly
<jpds> No, when you lose a passphrase, the key is useless.
<EagleSn> any quickly way to gpg ask me for password and can try multiple?
<jpds> The option: "--passphrase-repeat N" might help.
<EagleSn> debsign?
<jpds> No, that's a gpg option.
<EagleSn> --passphrase-repeat N must be typed in debuild command?
<jpds> Forget it, I just remembered that option is used when creating keys.
<EagleSn> i ma lamost sure that i am typing well the pasphrase
<EagleSn> i have imported today my gpg key, may be i imported it bad
<EagleSn> i have 4 files: my-private.key; my-public.key; mykey-ASCII.asc and revoke-mykey.asc
<EagleSn> i also printed my key in ASCII in paper
<EagleSn> i did gpg --import my-public.key
<EagleSn> gpg --import my-private.key
<EagleSn> was it enought for restoring my key?
<EagleSn> is it possible that gpg is working bas in Intrepid?
<EagleSn> working bad *
<cjwatson> I've not heard any complaints from developers who use it all the time
<cjwatson> check gpg --list-secret-keys output to make sure it imported your secret key to the right place
<EagleSn> right place?
<cjwatson> gpg maintains two different keyrings, one for public keys and one for secret keys
<cjwatson> gpg --list-secret-keys will show the contents of the secret keyring
<EagleSn> i ma sure that i am entering well my passphrase, i have done an experiment to know it, and gpg fails
<cjwatson> why do you care about the signature anyway?
<cjwatson> if you're just going to produce a debdiff, it doesn't matter if the signing step fails
<EagleSn> i think it is important
<cjwatson> that only matters if you have upload privileges and are going to upload it to an archive
<EagleSn> okay, but i would like to discover what is happening with my sign
<cjwatson> what is the error message from gpg?
<EagleSn> it is in Spanish
<cjwatson> 'LC_ALL=C debsign'
<EagleSn> i think there is a coomand to all output in console to be in English
<cjwatson> export LC_ALL=C
<EagleSn> that only affects to this terminal session?
<cjwatson> yes
<cjwatson> (this is quite basic; you might want to go elsewhere for general Unix help)
<EagleSn> when it ask me for pass, if i put it wrong intentionally, it warn me about it is incorrect, and ask for me again until 3 times
<cjwatson> if gpg is literally saying that your passphrase is wrong, then there are two possibilities: (1) you have another secret key with that UID etc., and gpg is using that rather than the one you expected (you can force it with 'debsign -kKEYID'), or (2) your passphrase is wrong
<EagleSn> yes, but if i put the pass correctly, it do not tell me that it is incorrect, directtly gives me an error
<Mithrandir> you can set it permanently in ~/.devscripts by having DEBSIGN_KEYID=$yourkeyid there.
<Mithrandir> you need to provide us with the error if we're going to help you debug it.
<EagleSn> yes, now
<EagleSn> now it is asking for pass, ok i am going to put it correctly
<EagleSn> look http://paste.ubuntu.com/44299/
<EagleSn> gpg: problem with the agent - disabling agent use
<EagleSn> that appears before i type passphrase
<cjwatson> comment out use-agent in ~/.gnupg/options; or else (if you're intending to use an agent) configure the agent to keep your key for some reasonable amount of time, and prime it in advance by signing some random bit of text
<cjwatson> (I use http://people.ubuntu.com/~cjwatson/tmp/gpg-refresh-cache for the latter purpose)
<EagleSn> i dont understand nothing lol
<EagleSn> reading the link
<cjwatson> if you have no idea what I'm talking about, then make sure use-agent is not set in ~/.gnupg/options
<cjwatson> and if you have no idea what I'm talking about, then gpg-refresh-cache is unlikely to be of any use to you
<EagleSn> ok, what is agent than, wehere can i read some ?
<cjwatson> oh, meh, we use an agent by default now, that's a bit annoying
<cjwatson> EagleSn: I suggest just putting 'no-use-agent' at the end of ~/.gnupg/options (create that file if it doesn't already exist)
<EagleSn> there is not options file in ./gnupg
<cjwatson> as I just said, "create that file if it doesn't already exist"
<EagleSn> ok
<EagleSn> options file does need any header?
<cjwatson> no
<EagleSn> i did it
<EagleSn> try debuild again?
<cjwatson> please, this is a developer channel and we expect people to try things for themselves :)
<EagleSn> i am doing it..
<EagleSn> exactly tha samep roblem is happening
<EagleScreen> cjwatson it seems that ./gnupg file is being ignored, see the output: http://paste.ubuntu.com/44322/
<cjwatson> EagleScreen: oh, I suppose it's ~/.gnupg/gpg.conf now
<EagleScreen> yes, i already did it
<EagleScreen> there are no problem now
<EagleScreen> thansk for your atention
<EagleScreen> i think in Debian Agent is not used by default, may be by that i hadn't problems with this before, this is the first time I use debuild in an Ubuntu system
<EagleScreen> where can i leanr the utility of gpg Agent?
<EagleScreen> *learn
<doggymenz> look, i have good idea for ubuntu to make it better
<doggymenz> http://img504.imageshack.us/img504/3081/pinkvolumewz2.png
<EagleScreen> doggymenz are you serious?
<doggymenz> yes
<doggymenz> you can choose color of volume partition, so you can have pink for porno, or maybe other color for something
<EagleScreen> i think your idea is to can custom icon of disk drives?
<doggymenz> ya
<EagleScreen> report it to Launchpad and also in bugzilla
<doggymenz> oh
<doggymenz> i request 10000 packages on launchpad, but nobody make them
<Ampelbein> hi there. i just tried uploading a source-package to my ppa but the build failed with the error "configure: error: C compiler cannot create executables". Is there something broken with my package or with the buildsystem?
#ubuntu-devel 2009-08-31
<Turl> hi
<Turl> will pidgin 2.6.1 get into karmic?
<Turl> there's a bug for that, it doesn't seem to have any 'official' opinion on the subject https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/415908
<ubottu> Launchpad bug 415908 in pidgin "Please merge pidgin 2.6.1-1 (main) from Debian experimental (main)" [Unknown,Fix committed]
<Turl> 2.6.1 is in debian experimental, whereas ubuntu has 2.5.8
<dave-ubuntu1> im looking for what mode of operation, algorithm, hashing algorithm, and keysize the ubuntu juanty alternate install cd supports
<dave-ubuntu1> anyone home? :/
<dave-ubuntu1> if you have an answer to my question please mail me at: davexthc@gmail.com or respond to https://answers.launchpad.net/ubuntu/+question/81467
<dave-ubuntu1> thanks in advance
<dave-ubuntu-1> i would like to add #ubuntu had no answer to my question afrer many hours
<dave-ubuntu-1> also if if it inst implemented i suggest when creating an encrypted LVM at least have the option to dd urandom to the target disk
<dholbach> good morning
<pitti> Good morning
<dholbach> hi pitti
<pitti> ScottK: sorry, was sleeping; seems it built by now
<highvoltage> morning dholbach and pitti
<dholbach> hey highvoltage
<StevenK> Morning pii
<pitti> hey StK
 * StevenK glares at his 't' key, which apparently works now
<foxbuntu> hey all, looking for a little advice on where to look for something
 * StevenK goes back to lurking, suitably embarrassed
<foxbuntu> I am trying to preseed a default for a gconf key but seem to figure out how to make it global for all users (including newly created ones)
<TheMuso> foxbuntu: You want dh_gconf and debian/gconf-defaults file
<foxbuntu> TheMuso, thanks! I will look at those
<TheMuso> foxbuntu: np
<foxbuntu> TheMuso, mind giving me a little help with dh_gconf?
<TheMuso> foxbuntu: Sure.
<TheMuso> If you want a good example, have a look at the ubuntustudio-default-settings package, that uses it.
<mattn> good morning - is there a way to install some gnome templates (xdg) via the package manager for every user?
<foxbuntu> TheMuso, well the only question is, since the package already uses dh do I need to do anything other than add a debian/gconf-defaults file?
<mattn> some standard way? or do i have to copy them manually to the home dirs?
<dholbach> hola juanje!
<juanje> hola dholbach! :-)
<TheMuso> foxbuntu: Just make sure the binary package in question has ${misc:Depends} in the Depends field in debian/control.
<TheMuso> foxbuntu: and if you have more than one binary package, make sure the file is debian/$package.gconf-defaults
<TheMuso> where $package is the package name.
<pitti> dholbach: I'm doing some sponsoring now, are you currently hammering at the queue and we need to coordinate? or can I just fire at will?
<dholbach> pitti: just go ahead :)
 * pitti hugs dholbach
 * dholbach hugs pitti back
 * dholbach needs to prepare his UDW session :)
<dholbach> maybe I'll do some more sponsoring later on
<foxbuntu> TheMuso, hmm, I have done both of those, and the conf still doesnt show up in place after the install, also in the dh log after build there is nothing for dh_gconf
<TheMuso> foxbuntu: ok hang on a sec
<TheMuso> foxbuntu: What packaging system are you using?
<foxbuntu> TheMuso, np, thanks in advance for all the help
<foxbuntu> TheMuso, cdbs
<TheMuso> foxbuntu: Right you do need to explicitly call dh_gconf, at least thats what I had to do with ubuntustudio-default-settings.
<foxbuntu> TheMuso, alright, so just add it to the debian/rules thenN?
<TheMuso> foxbuntu: I suggest you download the source for ubuntustudio-default-settings and have a look at debian/rules
<foxbuntu> TheMuso, will do
<foxbuntu> TheMuso, ahhh...thats what I was missing... thanks!
<TheMuso> np
<pitti> slangasek: mmm, current live CDs are well within size limits again
<pitti> slangasek: documentation gets stripped now, and gnome-games alone bought us 16 MB \o/
<slangasek> pitti: w00t
<pitti> can I seed frozen bubble now? :-)
<StevenK> pitti: What was the gnome-games change?
<pitti> StevenK: gnome help translations get stripped now, and stuffed into langpacks
<StevenK> \o/
<pitti> and I did a no-change upload of mousetweaks and gnome-games yesterday (against the new mangler)
<pitti> I needed two packages for testing, and I wanted the CDs to not be oversized any more
<StevenK> 0830 is oversized
<pitti> but not 0831 (today)
<pitti> that's what I meant
<pitti> I did the stripping/langpack-o-matic changes yesterday
<slangasek> pitti: no, but you can make a new derivative called frozenbubbluntu
 * pitti sobs
<pitti> blubbuntu!
<sebner> pitti: yeah, back in action at least. Is there anything else I could do (debug?) or do we have to wait for other traces, that tell you more or do we have to wait for upstream?
<pitti> sebner: at this point I'm waiting for Lennart's (upstream's) response
<sebner> kk :)
<pitti> I don't know about the black magic that libatasmart does, I'm afraid
<sebner> pitti: heh, not that bad (since it works with the workaround) but release is nearing and should be fixed anyways before it
<pengo1> I cannot believe this bug persists. https://bugs.launchpad.net/bugs/150872
<ubottu> Launchpad bug 150872 in ubiquity "Installer should not list removable media in /etc/fstab" [High,Fix released]
<pengo> (according to reports in the bug report anyway)
<pengo> makes me sad
<matteo> ciao
<matteo> there is a package in ubuntu I use
<matteo> that's libdmtx
<matteo> it's version 0.6.0 while upstream is 0.7.0
<matteo> debian sid already has 0.7.0 so i'm using the sd package
<matteo> the maintainer is the MOTU
<matteo> i have filed a bug report
<matteo> tme ago
<matteo> there is a way to join the team and do the upload myself?
<matteo> I have some PPA and i know good debian packaging system
<matteo> https://bugs.launchpad.net/ubuntu/+bug/396131
<lifeless> there is, but its not overnight, got to let people get to know you
<ubottu> Launchpad bug 396131 in libdmtx "update to 0.7.0" [Undecided,Confirmed]
<lifeless> what you can do, right now, is follow the 'sync' process documented in ubuntu-policy and on the ubuntu wiki, and that will get it updated
<matteo> what sync? from debian?
<lifeless> we're in feature freeze, so it may need a FFe approval
<lifeless> yes
<matteo> oh :(
<torkel> matteo: you probably want to join #ubuntu-motu
<matteo> i have ugly #ifdef in my code
<matteo> to support both debian and ubuntu
<pitti> meh, usb-creator seems completely broken right now :/
<hyperair> what's wrong with it?
<pitti> NotImplementedError: add_image is not implemented by the backend.
<pitti> I can't add an .iso
<hyperair> ouch
 * hyperair takes note not to wipe thumbdrive until usb-creator's fixed.
 * pitti installs jaunty version
<pitti> "Unable to determine the partition number" -- WTH?
<pitti> seems I won't create an usb install stick today :/
<davmor2> pitti: fortunately for me I keep one main box on a stable version for just that occasion :)
<ogra> pitti, broken for .img as well btw
<ogra> i know evand has a fix pending for that
<ogra> (we talked on friday)
<ogra> pitti, https://launchpad.net/bugs/420438
<ubottu> Launchpad bug 420438 in usb-creator "DeviceKit-disks backend does not show a device unless it has a formatted vfat partition" [High,Confirmed]
<pitti> ogra: right, sounds like it; I added a vfat partition now, and it works with the jaunty version now
<ogra> right
<ogra> i rolled back to jaunty as well, but it doesnt get me anywhere since jaunty had no .img support at all
<davmor2> ogra: can't you just add image-writer for that ?
<ogra> davmor2, well, imagewriter is supposed to be replaced by usb-creator
<ogra> indeed imagewriter works, its a dumb dd frontend, had to break :)
<ogra> *hard
<davmor2> ogra: yeah but as a temporary measure I meant
<ogra> sure, but then i can just dd anyway :)
<AnAnt> Hello, tzdata on jaunty needs to be updated
<cody-somerville> pitti, When I open jockey-gtk and try to activate a restricted driver in Xubuntu it says "You are not authorized to perform this action.". Why would it start doing that?
<pitti> cody-somerville: hm, seems you don't have policykit-1-gnome?
<pitti> it needs that to ask you for your password for authorization
<pitti> cody-somerville: hm, no, it's a dependency of jockey-gtk
<pitti> I guess you have it installed, but it's not running
<pitti> cody-somerville: can you confirm that pidof polkit-gnome-authentication-agent-1 is empty?
<sgallagh> Question: Can someone point me at a page listing the standard configure paths expected for an Ubuntu build? (e.g. ./configure --prefix=/ --sysconfdir=/var/lib etc.)
<pitti> cody-somerville: and if so, can you please change /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop to say "OnlyShowIn=GNOME;Xfce;"? does it start automatically then?
<cody-somerville> pitti, pidof is indeed empty
<cody-somerville> pitti, I need to reboot anyhow so I'll see if that change autostarts it
<cody-somerville> pitti, brb
<cody-somerville> pitti, Adding XFCE worked like a charm! :)
<pitti> 04-add-xfce.patch.disabled
<pitti> o_O
<pitti> cody-somerville: okay, will fix; thanks
<davmor2> cody-somerville: I bugged that a week or so ago :)
<cody-somerville> davmor2, bug #?
<pitti> davmor2: oh, do you have a bug #?
<davmor2> pitti, cody-somerville: bug 417462
<ubottu> Launchpad bug 417462 in jockey "Jockey-gtk is throwing up a box saying you are not authorised to perform this action" [Undecided,New] https://launchpad.net/bugs/417462
<pitti> davmor2: thanks
<mdke> kees: not sure if you've seen http://ardchoille42.blogspot.com/2009/08/canonical-advocates-insecure-practices.html
<Yoe> where are these debug packages?
<mdke> kees: seems to have comments disabled :(
<directhex> mdke, people who post blog posts which require response, but don't have comments enabled, require punishment. possibly with a 2-by-4
<cody-somerville> mdke, Whats your position on the issue?
<mdke> directhex: yes, I guess it's intentional
<mdke> cody-somerville: I'm not a security expert (and kees is) but from what I can see, there is nothing on the wiki page or the blog post that explains why enabling the root account is more dangerous than using sudo
<ScottK> It's not in many circumstances.
<ScottK> The one security advantage to sudo is enhanced logging of who did what.
<mdke> ok
<mdke> I guess if you have both, it gives a malicious users two possible passwords to guess/force, rather than one
<mdke> but that's not really something that makes enabling the root account inherently dangerous, afaics
<ScottK> That's a security advantage, not risk.
<mdke> anyway, the wiki page should reflect our policy, and as far as I'm aware kees is in about the best position to determine what that policy is, if it requires further discussion it should be escalated in the usual way
<ScottK> At least on a server as long as you disable root login via ssh
<cody-somerville> mdke, Its also probably needed, as kees said in his e-mail, for some users who have legacy tools/scripts/infrastructure requiring an actual root account and don't take advantage of sudo.
<ScottK> mdke: It's a wiki.  If people want to give information on alternative ways to do stuff, it is expected.
 * mdke nods
<mdke> wiki edit wars are no substitute for proper discussion on a mailing list
<ScottK> We don't want 'wiki police' running around and deleting stuff that's "not doing it right"
<mdke> especially not wiki vigilantes :)
<virtuald> sudo can be configured to ask for the root password. anyway the no root password thing makes me feel i should have a more secure password for my account?
<ScottK> mdke: Also we have a cultural norm of not reverting reversions to avoid  wiki wars.  The guy that made the blog post is IMO wrong on that account.
<mdke> ScottK: well, his post got reverted
<mdke> his edit, i mean
<mdke> ScottK: oh, I see what you mean now
<cody-somerville> "I have served as an op in official Ubuntu IRC channels where telling others how to enable root can get you kicked out of the channel." <-- Wow.
<jcastro> let me guess, RootSudo?
<ScottK> Yep
<mdke> pitti: I saw that you uploaded the new pkgbinarymangler yesterday so I will do a new ubuntu-docs upload soon with all the translations and we will see how it works :)
 * ogra looks for his hard hat for tomorrow :)
<mdke> heh
<ogra> mdke, btw i like to tell people that sudo vs root account is mainly a usability thing (despite the logging ScottK mentioned there is not much added security)
<ScottK> And the logging thing is totally irrelevant for single user systems.
<ogra> yeah
<ScottK> It's more of a tool for the autopsy than a security feature anyway.
 * mdke nods
<lamont> it used to be (apparently) that DEBIAN_FRONTEND was set when running postinst...  did that go away recently?
<jdstrand> actually, there are a few benefits of sudo: a) logging (as mentioned), b) no password for a well known account (ie root). this is especially good when combined with our sshd_config of allowing root logins and keeps people from brute-forcing root and c) it encourages the good behavior of not logging in as root
<ScottK> jdstrand: I think it's a given if you enable root you have to disable ssh login as root.
<jdstrand> in and of itself is there a tremendous security advantage? no. added together I think it adds security to the system overall
<jdstrand> ScottK: it is logically a given, but it is not a given with the current system
<ScottK> True, but I file that under "don't change this unless you know what you are doing".
<jdstrand> and it is only logically a given if you know what you are doing
<jdstrand> ScottK: I agree
<thebishop> hi, I'm working with a handheld device that uses MTP for file transfer.  The trouble is the most recent version of mtpfs only works in Hardy, I can't get it working in Jaunty
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<thebishop> can anyone tell me what changed in how Jaunty handles MTP devices compared to Hardy?
<pitti> tkamppeter: I had a question for you in bug 420015
<ubottu> Launchpad bug 420015 in udev "usblp Kernel module needs to be removed and /dev/bus/usb/*/* made accessible for USB printers to work with CUPS 1.4.x" [High,Invalid] https://launchpad.net/bugs/420015
<pitti> tkamppeter: is it actually easily possible to tell which devices are USB printers? (for creating an udev rule); otherwise I'd just have the backend run as root
<pitti> tkamppeter: I'll use the "root backend" approach for now; I can revert it if/when we get udev rules
<superm1> tkamppeter, can you email that patch again attached with that change since holtmann doesn't want to take the Changelog entry out himself again
<tkamppeter> pitti, yes. See the udev rules of system-config-printer-udev (/lib/udev/rules.d/70-printers.rules) for udev rules only starting a script when a printer is (dis-)connected.
<pitti> ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="07", ATTR{bInterfaceSubClass}=="01", GROUP="lp", MODE="660"
<pitti> tkamppeter: ^ could you please give this a quick test? I can't access an USB printer under karmic right now
<tkamppeter> pitti: See http://pastebin.ubuntu.com/262581/ for udev rules which determine and use bus and device number of the connected USB device.
<pitti> tkamppeter: but that's a per-vendor/product list again, and always behind and outdated by nature
<pitti> that's not covered by ATTR{bInterfaceClass}=="07"?
<pitti> tkamppeter: a rule like the above is reasonable to commit to udev, but http://pastebin.ubuntu.com/262581/ absolutely isn't
<pitti> that should be shipped by hplip then
<pitti> but that has its own backend anyway, doesn't it?
<tkamppeter> pitti, the pastebin stuff is not to demonstrate how to determine what is a printer, but how to extraxt bus and device number so that one can manipulate /dev/bus/usb/*/* files (to find the right one).
<tkamppeter> pitti, I thought about (but can be overkill):
<tkamppeter> ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="07", ATTR{bInterfaceSubClass}=="01", PROGRAM="/bin/sh -c 'X=%k; X=$${X#usbdev}; B=$${X%%%%.*}; D=$${X#*.}; file=`printf /deb/bus/usb/%%03i/%%03i $$B $$D`; chgrp lp $$file; chmod 660 $$file'"
<pitti> tkamppeter: why not simply GROUP="lp", MODE="660" ?
<pitti> that's what they are meant for
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 25 minutes in #ubuntu-classroom
<tkamppeter> pitti, is /dev/bus/usb/*/* automatically the file where GROUP="lp", MODE="660" acts on?
<pitti> tkamppeter: yes
<tkamppeter> if I do ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="07", ATTR{bInterfaceSubClass}=="01", GROUP="lp", MODE="660"
<pitti> tkamppeter: I put a proposed rule into the bug report (same as I pasted above) for testing
<tkamppeter> and connect the DesignJet 130 (a printer not covered by HPLIP) the permissions and ownerships do not get changed, but
<tkamppeter> ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="07", ATTR{bInterfaceSubClass}=="01", RUN+="udev-configure-printer add %p"
<tkamppeter> starts udev-configure-printer.
<pitti> tkamppeter: where did you add the rule?
<pitti> # libusb device nodes
<pitti> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0664"
<pitti> ^ from 50-udev-default.rules
<pitti> so it needs to run later than 50-*
<tkamppeter> In /lib/udev/rules.d/70-printers.rules, right before the rule to start udev-configure-printer (did not want to create a new file for the test and wanted to have it done before udev-configure-printer).
<pitti> tkamppeter: added updated rule to bug report
<tkamppeter> pitti, should it not be /etc/udev/rules.d/69-cups.rules as there is already /lib/udev/rules.d/70-printers.rules
<pitti> doesn't matter much
<pitti> tkamppeter: uploading new cups to experimental and karmic now, so that this gets fixed
<tkamppeter> pitti, but why does my rule not work if it is in /lib/udev/rules.d/70-printers.rules, right before the rule for udev-configure-printer?
<pitti> I don't know
<tkamppeter> pitti, before you upload new CUPS packages, one point:
<pitti> (too late..)
<pitti> tkamppeter: would be interesting to see an udevadm test output for the printer, to see whether the rule matches at all
<tkamppeter> pitti: The usblp kernel module should not be completely thrown out of the distro. It should only get deactivated for systems actually running CUPS.
<pitti> tkamppeter: right, that happens now, the blacklist file is shipped by cups
<tkamppeter> pitti, so my suggestion is to add a file /etc/modprobe.d/blacklist.conf file
<tkamppeter> So you did it already? Great.
<pitti> tkamppeter: I added blacklist-cups.conf
<pitti> then the apparmor profile update, and usb backend as root (for now)
<tkamppeter> Yes, I meant blacklist-cups.conf.
<tkamppeter> pitti, how did it work with the udevadm test?
<pitti> tkamppeter: you need the sysfs path of the printer device (udevadm monitor --udev -e, then plug it in), and then udevadm test devices/..., the output shoudl show the matching rules
<tkamppeter> pitti did you not put the udev rule into the CUPS package?
<pitti> tkamppeter: no, I didn't; it doesn't belong there, and you said it doesn't work
<pitti> tkamppeter: I install the backend to run as root for now
<tkamppeter> pitti, here is the udevadm result: http://pastebin.ubuntu.com/262600/
<kevdog> any plans for ubuntu to add the lzma file compression/decompression utilities lzma, lzip, or xz to its repositories.  I read that Slackware is now distributing files from its repository in .txz format
<maxb> !info lzma hardy
<ubottu> lzma (source: lzma): Compression method of 7z format in 7-Zip program. In component main, is required. Version 4.43-12ubuntu1 (hardy), package size 116 kB, installed size 296 kB
<maxb> kevdog: Look before you assume something is not there!
<kees> mdke: yeah, saw the blog post.  I like how he didn't include further emails with him.  anyway, as discussed, I don't think having a root account makes a system less secure.  there is one good point about knowing the "root" account exists, but that's pretty minor if it has a good password.
<neilwilson> mterry: Are you around?
<kevdog> maxb: I looked in my repository and did see anything regarding xz.  lzma is a part of 7zip, but I was wanting the standalone program if possible
<kees> mdke: I'm not hugely interested in "fighting" for having it in the wiki or not; my angle was simply "this smells like censorship".  It's documented in "man sudo_root", so I can always point there.
<ScottK> kevdog: xv is in xv-utils
<ion> xz-utils: /usr/bin/xz
<ScottK> v/z
<maxb> kevdog: What I just pointed out *is* a standalone program. Please head over to #ubuntu or #ubuntu+1 as appropriate for assistance installing/using stuff already in the repositories
<ScottK> maxb: It's worthin noting it's onlyl in Karmic though, not in a release.
<maxb> ScottK: but.... <maxb> !info lzma hardy  <ubottu> lzma (source: lzma): .... Version 4.43-12ubuntu1 (hardy) .... !?
<ScottK> maxb: I was talking about xz.
<kevdog> maxb: #ubuntu pointed me here.  Im using intrepid.  As far as using an apt-cache search xz -- nothing comes up with relevant results.  There is no /usr/bin/xz in my install -- possibly my fault
<ScottK> kevdog: No xz in Intrepid, just Karmic.
<maxb> OK, well, you also asked about lzma, which is there.
<kevdog> ScottK: Thanks -- you've answered my question -- what about lzip?
<maxb> karmic only, too
<kevdog> maxb: cool -- Thanks guys
<maxb> Is there anyone around who feels like sponsoring an upload of Subversion? LP 406245
<ubottu> Launchpad bug 406245 in subversion "Merge subversion 1.6.5dfsg-1 (main) from Debian unstable (main)." [Undecided,Confirmed] https://launchpad.net/bugs/406245
<ScottK> Got FFe?
<maxb> FFe is granted
<tkamppeter> pitti, still there?
<ScottK> maxb: Looking into it.
<maxb> yay, thanks
<mterry> neilwilson, will be around in 20m
<kees> pitti: is my reply to bug 413278 sufficient for an SRU?  Sorry I hadn't been clear enough.
<ubottu> Launchpad bug 413278 in eglibc "stack protector guard value does not lead with a NULL byte" [Medium,Fix released] https://launchpad.net/bugs/413278
<mathiaz> cjwatson: hi - I've gone through an cloud installation from the -server iso
<mathiaz> cjwatson: and it seems that the eucalyptus-cc package is not installed during the Cluster installation.
<mathiaz> marjomercado: hi - I've written some test cases for UEC
<mathiaz> marjomercado: http://testcases.qa.ubuntu.com/Install/UECInstall
<mathiaz> marjomercado: could you add these to the ISO testing tracker?
<pitti> kees: ah, thanks
<slangasek> mathiaz: probably not, but I can :)
<t0bi> wheren't there supposed to be talks regarding the ubuntu developer week in this channel?
<mathiaz> slangasek: ok.
<slangasek> t0bi: talks are held in #ubuntu-classroom
<t0bi> ah, thx!
<tkamppeter> pitti, still there?
<mathiaz> slangasek: are you taking care of updating the iso tracker with the new test cases?
<slangasek> mathiaz: yes
<mathiaz> slangasek: great - here is another set of testcases:
<mathiaz> slangasek: http://testcases.qa.ubuntu.com/System/CloudImages
<TheSteve0> I am running Karmic and I would love to give feedback - what is the best IRC channel to do that in
<sgallagh> Question: Can someone point me at a page listing the standard configure paths expected for an Ubuntu build? (e.g. ./configure --prefix=/ --sysconfdir=/var/lib etc.)
<TheSteve0> I should say I am running Karmic from 8/29 and applying multiple daily updates
<ScottK> TheSteve0: You should file bugs at launchpad.net.  You can send email to ubuntu-devel-discuss@lists.ubuntu.com.  IRC is possibly #ubunt+1.
<TheSteve0> scottK I don't know what you mean by that IRC channel
<ScottK> maxb: svn test build takes a long time on my laptop.....
<ScottK> TheSteve0: I had a typo.  #ubuntu+1 is the irc channel for discussion of issues and problems with the developmet release of Ubuntu.
<TheSteve0> scottK excellent - thanks
<slangasek> mathiaz: are those test cases specific to EC2?  Are there additional test cases for UEC pending (per Matt's mail)?
<ncb000gt> Is there any reason that files listed with dpkg-deb --contents <package> would not be installed properly when using sudo dpkg -i <package>?
 * ccheney may finally be moving, looking at house today that is 375 m^2 with additional 200 m^2 attic walk out storage
<ScottK> maxb: Subversion uploaded.  Thank you for your contribution to Ubuntu.
<slangasek> ncb000gt: because another package that you have installed Replaces: that package
<ncb000gt> slangasek: Perfect! Thank you kindly!
<jdstrand> seb128: hi! I've got a fix for bug #422130 and bug #417736 I plan to upload today. will this conflict with anything you are doing?
<ubottu> Bug 422130 on http://launchpad.net/bugs/422130 is private
<ubottu> Launchpad bug 417736 in gnumeric "[karmic] evince apparmor stops gnumeric previews" [Undecided,Invalid] https://launchpad.net/bugs/417736
<jdstrand> bug #422130
<ubottu> Bug 422130 on http://launchpad.net/bugs/422130 is private
 * jdstrand just made it public...
<jdstrand> bug #422130
<ubottu> Bug 422130 on http://launchpad.net/bugs/422130 is private
<jdstrand> meh
<jdstrand> seb128: bug #422130 is a bug in hamster fixed by this commit: http://git.gnome.org/cgit/hamster-applet/patch/?id=e9b7738328637ccc5aa49f63296c77c04927b7db
<ubottu> Launchpad bug 422130 in hamster-applet "hamster-applet crashed with GError in load_ui_file()" [Undecided,New] https://launchpad.net/bugs/422130
<jdstrand> thanks ubottu
<seb128> jdstrand, hello, no change are planned on evince so upload whatever you need to change
<jdstrand> seb128: what about hamster?
<seb128> jdstrand, you can also upload the hamster change
<jdstrand> seb128: thanks! :)
<seb128> thank to you for working on those!
<jdstrand> seb128: I'm kinda surprised how dependent I've become on hamster :)
<seb128> ;-)
<sgallagh> mathiaz: ping
<mathiaz> slangasek: thanks for updating the tracker
<slangasek> mathiaz: did you see my question about whether there were separate UEC test cases pending?
<slangasek> (vs. EC2)
<mathiaz> slangasek: hm - the test cases are the same, but both EC2 and UEC images should be tested
<mathiaz> slangasek: as they're different
<mathiaz> slangasek: both UEC and EC2 images should go through http://testcases.qa.ubuntu.com/System/CloudImages
<slangasek> are they?  I thought the image was supposed to be identical, distributed via 2 different channels
<slangasek> how do you test "availability zones" for UEC?
<mathiaz> slangasek: different clusters
<slangasek> and  should UEC point at the ec2 archive mirrors?
<mathiaz> slangasek: IIUC availability zones are different clusters in UEC
<slangasek> ok
<mathiaz> slangasek: hm right. This has to be updated.
<mathiaz> slangasek: I'll update the testcases then.
<slangasek> ok, cheers
<mathiaz> slangasek: test case wiki page updated.
<slangasek> ok
<mathiaz> slangasek: I've added a new test case - UEC Image
<mathiaz> slangasek: the other issue we run into this morning while testing the cloud installation on the server iso was that the eucalyptus-* packages weren't installed
<mathiaz> slangasek: the packages are on the isos and the eucalyptus udeb is trying to install tham
<mathiaz> slangasek: *them*
<mdke> kees: if its a valid use case and doesn't have negative security implications, I think it *should* be in the wiki. anyway, it is there now and the guy seems to have stopped editing it, I believe. Did you resolve anything in later emails?
<kees> mdke: I had replied to him with my justifications (before he posted to his blog -- and he didn't seem to publish *that* email...) so I figure I'm done with it for now.
<mdke> kees: fair enough, thanks for making the effort
<slangasek> mathiaz: I currently don't have an ISO test setup here; do you have enough information to file a bug against the installer about this?
<mathiaz> slangasek: well - there isn't anything in the log
<jtimberman> anyone here use sbuild?
 * jtimberman sorted, nm!
<YokoZar> Apparently there's something about launchpad's build daemons that I don't know.  I have a rules file that's little more than a copy command and it's building on i386 but failing on amd64 and I have no idea why. http://launchpadlibrarian.net/31090181/buildlog_ubuntu-karmic-amd64.wine1.2-gecko_1.0.0-0ubuntu2_FAILEDTOBUILD.txt.gz
<YokoZar> It works when I build locally with dpkg-buildpackage -rfakeroot too
<cjwatson> mdke: I'll get round to fixing it in karmic this week; I don't really think it merits an SRU, to be honest
<soren> cjwatson: Can you ping me when you're done with Eucalyptus for today?
<soren> cjwatson: I have a few more things I'd like to get done and then I'll upload at some point.
<soren> cjwatson: I'm sprinting in St. Louis, so it's still early for me. I'll make sure to get it done so that whatever we do will be on tomorrow's dailies.
<soren> slangasek: We would really appreciate some attention to bug 420035
<ubottu> Launchpad bug 420035 in eucalyptus "exception request; addition of the image store client interface" [Undecided,New] https://launchpad.net/bugs/420035
<soren> slangasek: There's a bunch of other interesting bug fixes in upstream's bzr, and we'd like not have to filter out these new features.
<cjwatson> mathiaz: yep - fixed in bzr now
<cjwatson> mathiaz: or should be, anyway
<mathiaz> cjwatson: great - thanks
<cjwatson> soren: I'm done for the moment, please do upload
<soren> cjwatson: Would you prefer I do it now, or is it cool if I wait a few hours?
<cjwatson> don't care
<cjwatson> this was essentially running through today's installer and fixing all the issues I could see
<cjwatson> which unfortunately wasn't many because the fact that eucalyptus-cloud doesn't get installed rather screws up the world
<soren> cjwatson: Yes, we noticed. We were just about to work on that when I saw your commits, so thanks :)
<cjwatson> soren: if you guys have time, it would be worth doing a test run of today's installer in the ordinary server mode, selecting eucalyptus-simple-cluster in tasksel
<soren> mathiaz: ^^
<cjwatson> soren: I'm a bit worried by the fact that I haven't yet been able to test a from-scratch installation of the cloud/cluster controllers in karmic
<mathiaz> cjwatson: we're current testing all of this.
<mathiaz> cjwatson: is there anyway to test your changes before waiting for a new round of dailies?
<soren> cjwatson: We sould be significantly closer to that by tomorrow.
<cjwatson> YokoZar: your package is architecture-specific but you're doing work in binary-indep, rather than in binary-arch where you should be doing it
<cjwatson> mathiaz: "the ordinary server mode, selecting eucalyptus-simple-cluster in tasksel"
<cjwatson> mathiaz: will not actually test my changes directly but will test the stuff that's significantly less well-tested and thus significantly scarier
<mathiaz> cjwatson: ok.
<cjwatson> YokoZar: you can reproduce this locally with debuild -B
<cjwatson> mathiaz: the main thing this won't test, of course, is the installer integration that deals with creating a node preseed file
<YokoZar> cjwatson: ahh I guess that happened when I migrated it from all to 3 arches.  Thanks that clears it.
<cjwatson> mathiaz: what you could do is as follows: boot the UEC installer in expert mode (i.e. select UEC at boot menu and use F6 to switch on expert mode), run through the installer until immediately after "retrieving installer components" or whatever it's called, switch to tty2, nano /var/lib/dpkg/info/eucalyptus-udeb.postinst, apply my changes, save and exit, switch to tty1, select "change debconf priority", select "high", continue
<cjwatson> mathiaz: actually, I might try that myself now
<jdstrand> kirkland: fyi, bug #359338 should no longer be a blocker for you
<ubottu> Launchpad bug 359338 in apparmor "apparmor paths are broken when using ecryptfs on jaunty" [High,Fix released] https://launchpad.net/bugs/359338
<kirkland> jdstrand: \o/
 * kirkland high fives jdstrand 
<jdstrand> kirkland: I assume you'll let evand know when he is around?
<jdstrand>  5
<jdstrand> o/
<kirkland> jdstrand: let evan know what, exactly?
<jdstrand> kirkland: that it is not a blocker. I thought that was the last thing for the installer. However, I forgot it was in email, so I'll respond there
<cjwatson> soren: seems like it'd be safer to || true that dpkg-statoverride --remove call?
<cjwatson> soren: and using dpkg-statoverride for this is fundamentally broken, in case you didn't already know :)
<cjwatson> dpkg-statoverride is a *user* override
<cjwatson> soren: packages are supposed to create any users/groups they need to own their files in their preinst, and then just ship the files owned by the correct user/group in the filesystem tarball in the .deb
<kirkland> jdstrand: great, thanks ;-)
<cjwatson> soren: certainly, without the || true, that's going to fail on initial installation - the if ! getent block will create a statoverride for euca_rootwrap in /usr/lib not in /usr/share, and then dpkg-statoverride --remove will fail because the override doesn't exist
<soren> cjwatson: Even for setuid files?
<cjwatson> yep
<soren> cjwatson: Ok.
<soren> cjwatson: I got my inspiration from some other package that shipped a setuid binary..
<soren> cjwatson: How does that work on the initial isntall, though?
<soren> cjwatson: when its first installed, it the user eucalyptus user doesn't exist, so what would happen then?
<cjwatson> some packages inherit a crazy view of the world from the really old way things used to work
<cjwatson> you create the eucalyptus user in the preinst if it doesn't exist
<soren> Then I need a Pre-Depends on adduser, don't I?
<cjwatson> yes
<cjwatson> this is better than the alternative
<soren> Fascinating :)
<cjwatson> if you create the user in the preinst, then it's available when dpkg-deb unpacks the tarball
<cjwatson> http://lists.debian.org/debian-devel-announce/2001/01/msg00004.html
<soren> Sure. I just thought Pre-Depends was something we tried really, really hard to avoid.
<cjwatson> also http://lists.debian.org/debian-mentors/2001/02/msg00174.html may help
<cjwatson> Pre-Depends is often to be avoided, but this is one of its standard uses
<cjwatson> it shouldn't be avoided at the cost of poor behaviour elsewhere
<soren> cjwatson: Doesn't the first link say that I /should/ use dpkg-statoverride?
<soren> Oh, /me just read the second link..
<cjwatson> not in your maintainer scripts
<jono> hey all
<jono> can I run Devicekit on Karmic alongside HAL?
<cjwatson> there is some justification for using dpkg-statoverride in maintainer scripts on occasion, to migrate overrides around when files change name
<cjwatson> the reason I went to look at your change was that I wrote code to do this very recently in man-db and I wanted to compare yours with mine :-)
<mathiaz> kees: what's your take on bug 194140?
<ubottu> Launchpad bug 194140 in cyrus-sasl2 "Dependency cycle prevents upgrade of libsasl2-2" [Low,Incomplete] https://launchpad.net/bugs/194140
<cjwatson> it's probably too much effort unless it's likely that lots of sysadmins will have used statoverrides, which they probably won't have dared to do when the package is scribbling over them itself
<tkamppeter> rickspencer3: hi
<davmor2> jono: why would you need too?
<jono> davmor2, to write some software that uses DeviceKit
<kees> mathiaz: i have not been able to reproduce it
<davmor2> jono: I thought devicekit was mostly implemented in karmic
<slangasek> jono: if you're running karmic, you already have devicekit (or as much of it as is implemented)
<sivang> hi all
<sivang> does anyboidy know where I can find daffyd harris ?
<davmor2> with a name like that I'm going to guess at Wales
<sivang> well, I want to talk to him on IRC
<jono> slangasek, in the default install?
<sivang> I'mm find his email
<slangasek> jono: yes
<soren> cjwatson: Hm... So adduser in preinst (so with a Pre-Depends: on adduser) is the preferred way to do something like this or is there a third way that doesn't suck at all?
<rickspencer3> hi tkamppeter
<davmor2> jono: yes
<cjwatson> mdke: ah, I see Brian already fixed the guide in karmic
<jono> slangasek, ahhh great :)
<seb128> jono, that's what gvfs uses by default in karmic
<jono> seb128, ahhh great :)
<jono> thanks for info, chaps
<cjwatson> soren: adduser in preinst is preferred for this, to the best of my knowledge
<cjwatson> specifically in the case where the package needs to ship a file owned by a particular user
<cjwatson> soren: this really doesn't suck at all in practice; eucalyptus-common is extremely unlikely to be unpacked in an environment where adduser is not already configured
<cjwatson> I mean, even without the pre-depends
<cjwatson> pre-depends get sucky when they're used in less widely separated parts of the stack
<cjwatson> sivang: I don't believe he's involved with Ubuntu any more; try other contact methods
<soren> cjwatson: Do you have any idea why mlocate is using dpkg-statoverride?
<soren> cjwatson: I'll fix up Eucalyptus to not use dpkg-statoverride. Thanks for clarifying this.
<cjwatson> soren: no, but at least it uses a --list check to ensure that it doesn't conflict with existing sysadmin overrides, so its implementation isn't buggy, merely (IMO) awkward
<soren> *cough* Yeah, that is a good idea :)
<mathiaz> slangasek: some of the opendrim-lmp-* packages are in State: Failed to upload - how should this be fixed?
<slangasek> mathiaz: hrm, were the source packages buildable while still in universe?
<mathiaz> slangasek: nope - one of the build-dependency (sfcb) was in multiverse
<slangasek> hum
<slangasek> which ones are failed-to-upload?
<mathiaz> slangasek: opendrim-lmp-baseserver, opendrim-lmp-ip, opendrim-lmp-ethernetport
<soren> cjwatson: Could you take a peek at a diff for this for me
<soren> ?
<cjwatson> soren: sure
<soren> cjwatson: http://pastebin.com/f69e08d22
<soren> cjwatson: I'm not sure if I'm being overly defensive.
<soren> cjwatson: Disclaimer: I've not tested it yet.
<cjwatson> soren: hmm, one awkwardness with this scheme is that you do have to ensure that euca_rootwrap is group eucalyptus in the tarball yet - that may be tricky
<cjwatson> s/yet //
<soren> cjwatson: *chuckle*
<soren> cjwatson: Err.. Yeah.
<cjwatson> soren: this code looks fine, but maybe I led you up the garden path, sorry, I can't think how to safely make it the right group in the tarball :-(
<soren> cjwatson: Heh :)
<cjwatson> in that case the fallback would be to use a --list check as in mlocate
<cjwatson> damn and blast, etc.
<slangasek> .oO ('fakeroot adduser ...')
<cjwatson> that really is foul, there should be a better way
<soren> cjwatson: No worries. It was an interesting thought experiment.
<cjwatson> you want something like fakeroot_allow_user/group
<cjwatson> which talks to the faked
<soren> I'm not sure I like the idea of putting gain-root-command specific stuff in the rules file :)
<soren> In fact, I'm quite sure I don't like that idea. :)
<cjwatson> oh, also, 04750 is stated by policy as being wrong for setuid executables - should be 04754
<cjwatson> on the basis that there's no point in making an executable non-world-readable when anyone can go to the archive and find out what it contains
<soren> Heh :) good point.
<cjwatson> "Cannot find Eucalyptus bootstrapper: com/eucalyptus/bootstrap/SystemBootstrapper"
<soren> cjwatson: :(
<soren> cjwatson: I'll poke Dan in a second about it.
<cjwatson> eucalyptus-msgs-1.6-devel.jar has that class
<cjwatson> and that file is being opened
<soren> cjwatson: http://pastebin.com/f36b620cb instead, then?
<ebroder> TheMuso: You said a while back that you were concerned that the attached debdiff for bug #330766 "could break dir/file handling in .pulse". Could you clarify what you mean by that?
<ubottu> Launchpad bug 330766 in pulseaudio "pulseaudio hangs, prevents login, home as ntfs" [Unknown,Fix released] https://launchpad.net/bugs/330766
<soren> cjwatson: Oh, I'll see if I can do the 4750->4754 thing as well.
<cjwatson> soren: yeah, that looks better - I'd || true the --list just in case somebody makes the postinst set -e in the future
<soren> cjwatson: Oh, I didn't realise that it was considered an error condition. Thanks.
<cjwatson> yeah, it's picky
<TheMuso> ebroder: Will comment in the bug.
<ebroder> TheMuso: Thanks
<ion> Home as... ntfs? :-D
<soren> cjwatson: http://pastebin.com/ffdb84c3
<ebroder> ion: I've specifically seen it happen with networked homedirs when you run out of quota
<TheMuso> ebroder: Seems I didn't comment in the bug, and I thought the diff contained a different patch, so no things look ok actually.
<ebroder> Ok, thanks. Anybody from ubuntu-sru want to ACK bug #330766?
<ubottu> Launchpad bug 330766 in pulseaudio "pulseaudio hangs, prevents login, home as ntfs" [Unknown,Fix released] https://launchpad.net/bugs/330766
<dieselmachine> I'm in need of assistance with applying a patch to some source code
<dieselmachine> The patch is for a newer version of Ubuntu than that which I am using
<dieselmachine> But the relevant parts appear to be the same, so I assume it should work
<dieselmachine> How do I replace the current version on my system with the modified source I have?
<dieselmachine> Also, gvfs is garbage and it infuriates me that such a brutal bug was present for so long with no action being taken
<tormod> dieselmachine, debuild -b -us -uc, then dpkg -i the resulting binaries
<cjwatson> soren: looks fine except that I think you should remove the old statoverride too
#ubuntu-devel 2009-09-01
<dieselmachine> do i run that from the root of the source directory? Don't I need to do ./configure, or make or something?
<cjwatson> debuild -b (etc.) runs debian/rules build as one of its steps, which does ...
<dieselmachine> I do not have that package currently installed, and apt-get hasn't heard of it. What package do I need inorder to get access to debuild?
<dieselmachine> oh, disregard, it provided the answer in the error message
<dieselmachine> Sorry for the uninformed question
<ion> I tend to dpkg --unpack the resulting binaries and then apt-get -f install.
<dieselmachine> what does the -f parameter do?
<ion> man apt-get
<dieselmachine> How helpful
<dieselmachine> ls -al
<dieselmachine> oops
<dieselmachine> where does debuild dump the binaries?
<dieselmachine> a straight answer instead of linking me to a page with the answer would be great
<directhex> ..
<dieselmachine> awesome, thanks
<soren> cjwatson: Ah, right. Good catch. Thanks for the review!
<mathiaz> slangasek: could you add another test case for UEC images (last section from http://testcases.qa.ubuntu.com/System/CloudImages)?
<rndm_> karmic alpha 3 seems busted on modern imacs, there's no fb device in /dev. the live-cd doesn't go to anything graphical. It sounds like this: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nv/+bug/404577
<ubottu> Launchpad bug 404577 in xserver-xorg-video-nv "Xorg does not load in karmic using Zotac ion board A series" [Undecided,New]
<TheMuso> rndm_: How modern is modern?
<rndm_> TheMuso: has 9400m. the current production model i believe
<rndm_> i tested against the daily livecd actually, so newer than alpha 3
<TheMuso> rndm_: ah ok
<rndm_> it's model #A1224, the current 20inch if that means anything to you
<rndm_> if someone more experienced with development in this area would like to guide me on what may be relevant i'll file a report
<dave-ubuntu1> ive been looking for an answer to this question for days
<dave-ubuntu1> https://answers.launchpad.net/ubuntu/+question/81467
<dave-ubuntu1> i have tried #ubuntu for many hours also
<ScottK> mathiaz: They just needed a retry.  The failed to upload ones were ones that finished building (in Multiverse) before Soyuz noticed they'd moved.  I retried several of them, but I doubt I got them all.
<cjwatson> dave-ubuntu1: I'll answer on Launchpad
<virtuald> dave-ubuntu1: i think it uses LUKS default options, see man 8 cryptsetup
<cjwatson> virtuald: I have given an answer in LP based on what the code does
<virtuald> great
<lamont> Keybuk: bug 393656 - thoughts?
<ubottu> Launchpad bug 393656 in postfix "postfix fails on boot with "fatal: could not find any active network interfaces"" [Undecided,New] https://launchpad.net/bugs/393656
<MindVirus1> Hello. I have some suggestions, if anyone cares.
<MindVirus1> Don't know if anyone's listening. Here are my ideas.
<MindVirus1> Since I'm running a netbook and don't like netbook-remix, I keep my panel on the right side of the screen.
<MindVirus1> The window picker applet won't render text vertically though, like the Clock applet does.
<MindVirus1> I recommend that it should, instead of showing "..".
<cjwatson> MindVirus1: suggestions on IRC are likely to be lost, as chances are that the right people aren't paying attention, or can't fix things *right now*; it's much better to file bugs, or for ideas that aren't well-enough-formed for bugs you can use brainstorm.ubuntu.com
<MindVirus1> OK. :)
<MindVirus1> I don't mean to bother you guys. Does anyone have access to ubottu?
<MindVirus1> !hal
<ubottu> Hal is in the process of being depreciated.  See https://wiki.ubuntu.com/Halsectomy and http://en.wikipedia.org/wiki/Hardware_abstraction_layer for more info.
<MindVirus1> Should say "deprecated" instead of "depreciated". That is all.
<dholbach> good morning
<dholbach> morning pitti
<dholbach> pitti: I just sponsored a tangerine-icon-theme change and used the same build system you used in human-icon-theme :)
<dholbach> great work :)
<pitti> Good morning
<pitti> dholbach: \o/
<StevenK> Morning pitti
<pitti> plain make FTW :)
<dholbach> pitti: you know... I was young, didn't know any better and needed the money
<pitti> lol
<kagou> Hi
<kagou> bryce, I have subscribed you to bug #421225 . Hoping that you can detect if it's a Xorg bug.
<ubottu> Launchpad bug 421225 in xsplash "Xsplash freeze the system" [High,New] https://launchpad.net/bugs/421225
<kagou> bryce, sorry if it's not the right way to do that. Regards
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<slangasek> mathiaz: so the first two test cases only apply to EC2, and the third only applies to UEC, right?
<tkamppeter> pitti, the FTBFS of CUPS got fixed upstream, so we can get a fixed CUPS into alpha 5.
<tkamppeter> pitti, yesterday I have applied the upstream patch for the USB backend hang.
<StevenK> ArneGoetje: Does ibus really need a .desktop entry under /usr/share/applications? It's being picked up by netbook-launcher and put into an "Other" category
<StevenK> ArneGoetje: (care of bug 420282)
<ubottu> Launchpad bug 420282 in ibus "ibus is in "other" category in the menu" [Undecided,New] https://launchpad.net/bugs/420282
<tkamppeter> pitti, one other thing of yesterday: I tested the suggested udev rule and it did not work for me. I had uploaded udevadm output to http://pastebin.ubuntu.com/262600/.
<pitti> tkamppeter: thanks; I saw the poppler API fix, I'll apply that as well
<mdke> cjwatson: ok, well I've fixed it on help.u.c in all versions but I don't think it's necessarily essential to keep the packages in line with that. I'll reject the other bugs tasks and we'll regard it as fixed
<pitti> tkamppeter: sorry, did you say something after my "you need /devices.."? DSL reconnect..
<tkamppeter> pitti, one other thing of yesterday: I tested the suggested udev rule and it did not work for me. I had uploaded udevadm output to http://pastebin.ubuntu.com/262600/.
<pitti> tkamppeter: I still got that
<pitti> pitti| tkamppeter: thanks; I saw the poppler API fix, I'll
<pitti>        apply that as well
<pitti> pitti| tkamppeter: ah, I see what's wrong
<pitti> pitti| tkamppeter: you ran udevadm info on the interface,
<pitti>        not on the device
<pitti> pitti| tkamppeter: you need /devices/pci0000:00/0000:00:1d.
<pitti>        1/usb3/3-1/3-1.4/3-1.4.3/3-1.4.3.4 for the device
<pitti>        (the one with DEVNAME=/dev/bus/usb/003/016)
<seb128> jdstrand, pitti: you might want to have a look to bug #414506
<ubottu> Launchpad bug 414506 in gdm-guest-session "broken AppArmor profile" [Undecided,New] https://launchpad.net/bugs/414506
<seb128> jdstrand, pitti: you might want to have a look to bug #414506
<seb128> ups
<pitti> seb128: the entire guest session is broken anyway..
<pitti> still on my TODO list
<seb128> pitti, ok thanks
<pitti> seb128: oh, that; I alrady discussed that with Martin-Eric
<seb128> pitti, speaking of guest-session somebody mentioned yesterday that only a  +x is to change or something
<seb128> I think that was dbarth
<pitti> bug updated
<pitti> tkamppeter: meh, with the pdftopdf fix, it doesn't build any more with poppler 0.10 in Debian; so more magic dpatching required..
<tkamppeter> pitti, for the Alpha 5 we can use a "magic" dpatch, but later we need conditional compiling with switch in ./configure, as the filters are upstream code and they should work with all incarnations of the daily changing API of Poppler.
<tkamppeter> pitti, new udevadm test: http://pastebin.ubuntu.com/262959/
<tkamppeter> pitti, can you upload bluez to get bug 418465 fixed for Alpha 5? superm1 will still be sleeping when Alpha 5 freeze happens.
<ubottu> Launchpad bug 418465 in bluez "bluetooth CUPS backend should output device listings immediately when it discovers the devices (in discovery mode)" [Medium,Fix committed] https://launchpad.net/bugs/418465
<ArneGoetje> StevenK: no, it doesn't. As long as the settings are accessable from the System/Preferences Menu, other entries are not needed.
<al-maisan> I have a Samsung Q45 laptop running karmic and the screen brightness control keys don't work at all (no reaction when pressed); can somebody please explain how to fix this or point me to existing documentation?
<AnAnt> Hello, can someone merge console-setup from Debian, since it would close LP 390292
<ubottu> Launchpad bug 390292 in console-setup "undefined kernel key code ( in karmic a2)" [Undecided,Confirmed] https://launchpad.net/bugs/390292
<Trewas> al-maisan: probably same bug 409889, it mentions a workaround
<ubottu> Launchpad bug 409889 in linux "NC10 fails to up and down the brightness" [Medium,Triaged] https://launchpad.net/bugs/409889
<al-maisan> Trewas: thanks for the pointer!
 * al-maisan takes a look.
<jjardon> hello, someone can take a look at https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/418401 and https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/418981 ? I think they are important to https://wiki.ubuntu.com/Halsectomy
<ubottu> Launchpad bug 418401 in gnome-bluetooth "gnome-bluetooth doesn't depend on HAL" [Undecided,New]
<al-maisan> Trewas: the workaround described in the bug did work. Thank you very much!
<pitti> tkamppeter: no, the patched filter was in debian/local/
<pitti> tkamppeter: (pdftopdf)
<pitti> tkamppeter: bluez> looking
<pitti> tkamppeter: hm, what's the exact rule you have now?
<ojwb> mvo: the xapian-core build failed on most platforms, due to running out of fds in the tests
<pitti> tkamppeter: new cups uploaded to experimental and karmic
<tkamppeter> pitti, have you seen my last comments here?
<tkamppeter> pitti, have you checked my new  udevadm test: http://pastebin.ubuntu.com/262959/?
<pitti> tkamppeter: pitti| tkamppeter: hm, what's the exact rule you have now?
<mvo> ojwb: heh :) impressive - is that a buildd configuration problem? should I talk to the buildd admins aobut it?
<tkamppeter> pitti: /lib/udev/rules.d/70-cups.rules:
<tkamppeter> pitti: ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{bInterfaceClass}=="07", ATTR{bInterfaceSubClass}=="01", GROUP="lp", MODE="660"
<pitti> tkamppeter: and can you please check /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.3/3-1.4.3.4
<pitti> oops
<pitti> tkamppeter: and can you please check /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.3/3-1.4.3.4/bInterfaceClass ? is that really "07"?
<pitti> tkamppeter: and likewise for bInterfaceSubClass ?
<tkamppeter> pitti, debian/local/filters stuff is upstream at http://www.openprinting.org/download/printing/pdf-printing/ and also at http://opfc.sf.jp/.
<ojwb> mvo: sorry, the phone rang!
<ojwb> mvo: i'm not sure what the cause is, but one of the debian alpha buildds does it too (and another doesn't)
<ojwb> i guess sbuild sometimes has more fds open itself or something like that?
<ojwb> if you fancy fixing it, just kill the ulimit as the patch does, but globally
 * ojwb can file a bug if that's better
<tkamppeter> pitti: cat /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.3/3-1.4.3.4/3-1.4.3.4:1.0/bInterfaceSubClass
<tkamppeter> pitti: 01
<tkamppeter> pitti: cat /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.3/3-1.4.3.4/3-1.4.3.4:1.0/bInterfaceClass
<tkamppeter> pitti: 07
<pitti> tkamppeter: ah, that woudl be it; that's again the interface, not the device
<pitti> so I see why that rule doesn't work
<pitti> tkamppeter: hang on
<pitti> tkamppeter: https://bugs.edge.launchpad.net/ubuntu/+source/cups/+bug/420015/comments/53
<ubottu> Launchpad bug 420015 in cups "usblp Kernel module needs to be removed and /dev/bus/usb/*/* made accessible for USB printers to work with CUPS 1.4.x" [High,Fix released]
<cjwatson> AnAnt: I don't think it's a good idea to merge console-setup (and please leave that kind of decision up to the installer team). I'll backport the fix
<cjwatson> if only because it will stop people thinking it causes other random bugs
<AnAnt> cjwatson: actually, I do have a problem with console-setup LP 416949
<ubottu> Launchpad bug 416949 in console-setup "Keyboard layout toggle does not work anymore in karmic" [Undecided,New] https://launchpad.net/bugs/416949
<tkamppeter> pitti, that's it, it works now. Thanks.
<AnAnt> cjwatson: and indeed, I thought that maybe 390292 is related to it
<tkamppeter> pitti, can you ap[ply the rule to the appropriate package to get it fixed in Alpha 5?
<pitti> tkamppeter: not necessary for alpha-5, since the usb backend runs as root, it should work now; I'll just commit it
<pitti> ... to udev upstream
<pitti> and once it's in, revert the "root backend" change
<tkamppeter> pitti, OK, thanks.
<AnAnt> cjwatson: I even thought of trying Debian's console-setup on karmic after I found a hard time trying to merge Ubuntu's changes
<AnAnt> cjwatson: do think that's a good idea, just to see if my problem goes ?
<cjwatson> AnAnt: terrible idea, I think :)
<cjwatson> AnAnt: I'm not merging it because it's really complex and will require other installer changes
<AnAnt> yes, it is complex indeed
<cjwatson> anyway, I'll backport the change and you can see
<AnAnt> ok
<mvo> ojwb: a bug would be prefered, fortunately it build on i386 and amd64 so at least the "big" arches are good :)
<tkamppeter> pitti, thanks for uploading bluiez.
<jjardon> pitti, about https://wiki.ubuntu.com/Halsectomy
<jjardon> Could you take a look at t https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/418401 and https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/418981 ?
<ubottu> Launchpad bug 418401 in gnome-bluetooth "gnome-bluetooth doesn't depend on HAL" [Undecided,New]
<ojwb> mvo: LP#422493
<ojwb> hope it's coherent, I have a cold atm
<pgraner> pitti: have a min to discuss the dvb firmware stuff?
<pitti> jjardon: looking, will comment in the bugs
<pitti> pgraner: hey
<jjardon> pitti, great, thanks!
<pgraner> pitti: after talking with mdz he feels it would be better to move the questionable firmware into a package than can be put in multiverse and have jockey pull from that. Thoughts?
<pgraner> pitti: the main rationale is that the firmware files keep changing URLs quite often and having them in a package ensures things "just work"
<pitti> pgraner: if the problem is just non-freeness, that sounds great, and much easier than URL fishing
<pitti> pgraner: however, if some of the firmware lacks a license completely, or explicitly forbids redistribution (like b43), this won't work either
<pgraner> pitti: lack of license is the issue and mdz felt that it was ok to do it that way.
<pitti> no, we can't, sorry
<pitti> we cannot redistribute stuff without a license
<pgraner> pitti: if thats the case then we will have to remove it and regress the dvb users
<pgraner> pitti: I suggest we talk to mdz when he comes online in a few hours
<pitti> pgraner: otherwise we could just leave it in restricted as it is now, and we wouldn't need to go through all this dance
<pgraner> pitti: its in the linux-fw package not in restricted
<pitti> ok, but at least we could move l-firmware to restricted if needed, and still install it by default
<pitti> but without permission to redistribute we can't stick it into the archive at all
<pgraner> pitti: ok, I'm not sure whats best but we have to do something. I sent an email to mdz & you we can hash it out there. mdz is in the US and I'm in Taiwan and tz's will kills us on IRC
<Mez> so, seems that gnome is a bit broken right now.
<Mez> I think I may have upgraded half way through a transition
<davmor2> Mez: sounds about right :)
<Mez> davmor2: not fun ... gnome-panel-data installed, gnome-panel not.
 * Mez steals the deb from LP and reboots X
<pitti> jjardon: bugs and Halsectomy page updated, thanks
<jjardon> pitti, Can I rename https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/418401 to "Upgrade gnome-bluetooth to drop libhal dependency" ?
<ubottu> Launchpad bug 418401 in gnome-bluetooth "port killswitch handling from hal to udev" [Undecided,Triaged]
<NCommander> stgraber, ping, if you have a moment, I'd like to talk to you on adding armel+dove images to the ISO tracker
<ogra> NCommander, slangasek can do that as well, but there is a prob in pointing the download location to ports iirc
<NCommander> ogra, ugh, what's the problem?
<ogra> i dont remember off the top of my head and the tracker is empty atm
<ogra> it was either a prob with .img files or a prob pointing to the right image location
<NCommander> ogra, doesn't sound like a show stopper ... */2 cents*
<ogra> it isnt
<pitti> jjardon: sure, go ahead
<blackxored> h3ll0 x 4all
<directhex> cjwatson, if you're still in a mouseemu bug-squashing mood, #362500 appears to be a real bug along similar lines
<cjwatson> directhex: probably not just at the moment ...
<jjardon> pitti, done
<jjardon> also upstream buf filled for GDM: http://bugzilla.gnome.org/show_bug.cgi?id=593787
<ubottu> Gnome bug 593787 in general "drop HAL code from gdm" [Normal,Unconfirmed]
 * pitti chuckles at http://xkcd.com/619/
<pitti> jjardon: thanks!
<dayanandasaraswa> Hello all, I want to know all about ext2 filesystem. I want to know its superblock structure and where all the information is stored..Where can I get all these?
<cjwatson> dayanandasaraswa: the kernel source - include/linux/ext2_fs.h, include/linux/ext2_fs_sb.h, fs/ext2/
<cjwatson> and Documentation/filesystems/ext2.txt of course
<jdstrand> seb128: re bug #414506> yeah, pitti is right. it also happens to be a dupe of bug #412551 (marked as such)
<ubottu> Launchpad bug 414506 in apparmor "broken AppArmor profile (dup-of: 412551)" [Undecided,Invalid] https://launchpad.net/bugs/414506
<ubottu> Launchpad bug 412551 in apparmor "apparmor_parser cannot create cache files on non-karmic kernels" [Medium,Confirmed] https://launchpad.net/bugs/412551
<dayanandasaraswa> cjwatson: Oh thank you..I'll take a look at them..:D
<seb128> jdstrand, ok thanks
<dayanandasaraswa> I'm actually in need of copying the whole ext2 filesystem's datastructures. Will e2image do that reliably? I actually want a replica of my HDD's filesystem's datastructures so that I can examine them separately for my project..
<cjwatson> have you read the documentation? :-)
<dayanandasaraswa> cjwatson: No, I have not :{
<dayanandasaraswa> :P
<dayanandasaraswa> cjwatson: I'm just now going to do that..But wanted to know the tools before hand :D
<cjwatson> e2image is probably the right tool
<dayanandasaraswa> cjwatson: Thank you so much :D
<mathiaz> slangasek: yes - two test cases are for EC2 and one for UEC
<mathiaz> slangasek: thanks for setting things up on the tracker
<robbiew> cjwatson: with evand on vacation, do we have anyone else familiar with usbcreator?  bug 422071 is a pain in the @$$
<ubottu> Launchpad bug 422071 in usb-creator "usb-creator throwing exception, not starting" [High,Confirmed] https://launchpad.net/bugs/422071
<cjwatson> robbiew: nobody really directly, although I should think anyone familiar with Python could sort it out
<robbiew> cjwatson: not a big deai...can wait
<robbiew> he's back tomorrow
<robbiew> thanks
<teknico> superm1, hi, may I ask you something about a malfunctioning fglrx driver?
<superm1> teknico, AMD hasn't published a supported driver for karmic yet AFAIK
<teknico> superm1, oh, it's curious, the latest Catalyst also builds deb packages for karmic
<teknico> but it doesn't work, so I guess you're right :-)
<superm1> teknico, the packaging is ready to go, they just need the appropriate code changes
<teknico> superm1, thanks, how will I know when it's ready?
<superm1> teknico, it will be uploaded to karmic when it's ready
<seb128> robbiew, I can fix that I know what the issue is
<teknico> superm1, right, which reminds me that version 2:8.632-0ubuntu1 is already in restricted (and not working either)
<robbiew> seb128: cool...thanks a lot
<seb128> you're welcome
<teknico> I'll wait for a new version
<cjwatson> robbiew: fixed in bzr
<cjwatson> seb128: oh, sorry, beat you to it :)
<cjwatson> I didn't look back at this channel in the meantime ...
<robbiew> lol
<robbiew> thanks all
<seb128> cjwatson, no problem, thanks
 * robbiew thinks about throwing random bug numbers into the channel to see how quickly they get fixed :P
<cjwatson> hmm, question is should I try to upload something for a5
<cjwatson> I'm not sure of the state of the rest of the bits in bzr
<cjwatson> I think I'd rather that wait for evand to return
<sgallagh> mathiaz:
<sgallagh> mathiaz: ping, rather
<robbiew> cjwatson: sounds fine to me
<mathiaz> sgallagh: hi
<cjwatson> robbiew: http://bazaar.launchpad.net/~usb-creator-hackers/usb-creator/trunk/revision/142 if you just want to get the fix locally
<seb128> cjwatson, I would upload a version based on the karmic one with only this change
<seb128> that's what I did with update-manager yesterday
<sgallagh> mathiaz: I wanted to let you know, we found, fixed and pushed a real change for that startup problem you were seeing (I gave you the band-aid patch for your beta release)
<cjwatson> seb128: mm, might be best, will do
<mathiaz> sgallagh: right - I saw the commit
<seb128> cjwatson, thanks
<mathiaz> sgallagh: thanks for working on this. I'll push a new package.
<sgallagh> mathiaz: Ok, just wanted you in the loop.
<mathiaz> sgallagh: thanks
<sgallagh> mathiaz: Well, I'm still investigating the provider=legacy problem that's hanging the SSSD on ubuntu
<ScottK> cjwatson: If your considering a usb-creator upload, rgreening has some usb-creator-kde changes too.
<ScottK> He was waiting for evand to get back.
<sgallagh> mathiaz: So you may want to wait until that's in before rolling a new package (though I don't know Ubuntu's process)
<ScottK> It's (I understand it) broken now, so there's no downside risk to updating.
<cjwatson> ScottK: I'm not qualified to review them
<mathiaz> sgallagh: that's fine. we can fix bugs in different uploads
<rgreening> ScottK, cjwatson: My changes have been uploaded to bzr branch. Just need to release 0.2.4 from bzr
<cjwatson> ScottK: and there's other stuff in bzr too so it's rather a mess
<cjwatson> sigh, ok, I'll attempt to review the lot :P
<ScottK> cjwatson: Your call of course, but rgreening did the KDE port to start with, so I'd expect it's reasonable.
<cjwatson> there's more than just his changes
<ScottK> right
<cjwatson> and I don't know if Evan's changes are pending some other dependency or something
 * ScottK steps back and lets the guy who's doing the work decide.
<rgreening> cjwatson: my changes make usb-creator-kde work again (mostly). There are some unimplemented bits in the backend evand wrote which cause FOrmat, and .iso images to not work, so I addressed in usb-creator-kde by temporarily disabling those buttons. CD-ROM install works.
<rgreening> which is better than it is currently.
<rgreening> also, I don't think the usb-creator-gtk works in either case (current or trunk), at least in my testing.
<rgreening> cjwatson: I get "An unhandled exception occurred:
<rgreening> Duplicate object id 'alignment3' on line 630 (previously on line 287)"
<cjwatson> yes, I just fixed that in bzr, that's where we came in :)
<rgreening> ok cool. then we should be able ot release.
<rgreening> I've been testing from trunk on the kde one.
<rgreening> cjwatson: I can confirm gtk version works now and did not impact kde version locally with the updated bzr.
<cjwatson> rgreening: cool, that saves me some testing time, thanks :)
<rgreening> np
<rgreening> Im here to serve cjwatson :P
<cjwatson> ok, uploading
<Keybuk> cjwatson: thought of the day: the PPA system should allow you to upload to UNRELEASED
<cjwatson> cr3: what are all these checkbox-generated reports landing on kbd? seems to be something to do with chvt failing, but it seems astonishingly unlikely that the problem is actually in the chvt program itself
<cr3> cjwatson: kbd?
<cr3> cjwatson: I see the problem, which package should it land against?
<seb128> cody-somerville, urg, you want to get the old gdm back in karmic?
<cody-somerville> seb128, Yes, as discussed.
<seb128> discussed when where?
<cody-somerville> seb128, here and several weeks ago
<seb128> I don't think it's a good idea, it's going to create configuration handling issues for user switching between version
<seb128> and it means we will have to reopen and reassign bugs and maintain old buggy code
<cody-somerville> I don't like this anymore then you do. However, gdm has taken a different direction that doesn't make it suitable as desktop agnostic display manager.
<seb128> what about trying to pick one of the other available?
<seb128> ie xdm
<cody-somerville> None of them are suitable
<seb128> rather than pushing an unmaintained version of gdm back there
<cody-somerville> Those other options aren't maintained either
<seb128> why not?
<cody-somerville> seb128, numerous security issues
<seb128> who is going to assure the security of the old gdm codebase?
<seb128> is that something you discussed with the security team already?
<cody-somerville> seb128, The Xubuntu team will take responsibility for maintaining the package
<seb128> that's going to be costy
<cody-somerville> seb128, We're hoping to have the new gdm working for karmic+1
<seb128> will you also be responsible for fixing issues due to switch between versions in both sides?
<cody-somerville> seb128, We'll try our best to resolve any critical issues that presents.
<cody-somerville> seb128, I've tried it out myself and I didn't run into too any trouble
<seb128> what is not suitable in the new gdm?
<seb128> the option taken there seems far to be optimal
<seb128> I would rather spend efforts fixing the new ones than trying to bring both version together
<cody-somerville> seb128, The issue isn't bugs, the issue is that they've decided to depend on other gnome components
<seb128> how do you plan to fix that in karmic+1?
<cody-somerville> seb128, I'm hoping to use our relationship with Xfce to have changes made to different Xfce components that will enable us to be able to drop them in place of the gnome ones.
<mr_pouit> (so there is no plan)
<seb128> hum, I think trying to bring previous gdm in karmic is not a good move
<seb128> but shrug
<seb128> if other people are fine with that
<seb128> pitti, ^ opinion on that?
<pitti> seb128: hm, cody-somerville's choice in the end; if there's no other option, xubuntu doesn't have much choice, I guess
<pitti> however, I'm interested in the particular reasons
<pitti> the alternative dependencies and components weren't enough? what was missing?
<superm1> yeah, what particularly?  for the mythbuntu case, it appears to not be pulling in exorbitant amounts of gnome now, and working fine
<cjwatson> cr3: problems changing tty are usually kernel bugs, AIUI
<cody-somerville> Theres no way to set a system wide default session
<cr3> cjwatson: I'll make the necessary changes, thanks
<cody-somerville> People would login to xterm instead of xfce4 by default
<superm1> oh, we're cheating with that for now, but i agree that's a problem
<superm1> for mythbuntu, we're providing a gnome.desktop in mythbuntu-default-settings
<ScottK> Maybe cody-somerville could use your cheat this cycle?
<pitti> cody-somerville: that doesn't seem excessively hard to add, though
<pitti> it could use "default.desktop" if present, and prefer that
<superm1> there is a bug filed for that, bug 403291
<ubottu> Launchpad bug 403291 in mythbuntu-default-settings "Unable to change the default session for GDM" [Undecided,Fix released] https://launchpad.net/bugs/403291
<cody-somerville> How about we accept gdm-2.20 and I'll continue to work out the kinks with the new gdm. If I'm satisfied by beta, we can remove gdm-2
<cody-somerville> This is just a backup plan
<superm1> isn't the autologin code in ubiquity (user-setup ?) already transitioned to the new gdm?
<pitti> superm1: yes, it is
<pitti> cody-somerville: was there any other blocker?
<pitti> cody-somerville: sorting out the configuration issues seems to be more work to me than to teach gdm about a preferred session
<cody-somerville> pitti, I found that the busy cursor was always present
<pitti> I don't mind having gdm-2 in universe, but I feel it'd create more problems than it solves
<cody-somerville> pitti, and I need to take care of theming as right now it looks like crap
<pitti> right, we share _that_ problem :)
<cody-somerville> which one? the busy cursor or the theming?
 * cody-somerville goes to eat lunch.
<pitti> cody-somerville: the theming; I don't see a busy cursor here
<dholbach> Ubuntu Developer Week starting in 19 minutes in #ubuntu-classroom
<kirkland> liw: ping
<kirkland> liw: you asked once about changing the screen size of a kvm vnc window
<kirkland> liw: in karmic, you now have 2 options
<kirkland> liw: the window itself is dynamically resizable, doing the scaling/stretching of the bitmaps of the virtualized system
<kirkland> liw: also, bryce committed a couple of fixes (hacks) to the xserver that should allow more different actual screen resolutions
<kirkland> liw: enjoy ;-)
<RainCT> :)
<RainCT> (oops)
<RainCT> seb128: Any plans to update gnome-shell & co?
<seb128> RainCT, it's on my list but I just came back from vac yesterday
<seb128> and I had other things I wanted to get on the coming alpha
<seb128> RainCT, you can do it if you want or I will do it later this week
<RainCT> seb128: Okay, I may take a look at it. I'm also wondering whether seed will be in Karmic (or rather, if there's any reasons why it isn't in Karmic and it can get a FFe)?
<seb128> RainCT, I would just say ETOOMUCHTODO
<seb128> RainCT, but it's in debian now I will sync it
<RainCT> seb128: Oh, right - Cool! There's also an updated gobject-introspection there.
<seb128> RainCT, will look into that too
<fbond> What are the ballpark odds that Ubuntu will switch to connman from NetworkManager?
<pitti> fbond: for karmic? 0
<pitti> fbond: (feature freeze)
<fbond> pitti: No, not for karmic, for karmic+1, karmic+2, etc...
<fbond> Mostly trying to get a sense for the developer sentiment.
<pitti> fbond: I think it's safe to say that it won't happen for karmic+1, since it's LTS and we won't change infrastructure much; beyond that, nothing is decided yet
<pitti> fbond: asac might have a qualified feeling, though
<fbond> pitti: Okay, thanks.
<fbond> asac: thoughts on ConnMan?
<asac> fbond: well. so far there is not even a UI ... except for netbooks.
<asac> connman is really young projects. so i would lean towards saying it wont be ready for serious karmic+1 consideration
<asac> but you never know
<asac> we keep our eyes open
<fbond> asac: Hm, I thought there was a connman-gnome project.  That is for netbooks only?
<pitti> YokoZar: hey!
<pitti> YokoZar: we were wondering about the status of desktop-karmic-wine-integration; is that still likely to hit karmic (with some FF), or should we call it postponed for Karmic+1?
<asac> fbond: thats abandoned upstream atm
<asac> fbond: we even have the package, but its not developed upstream for the time being.
<mvo> apachelogger: many thanks for the apturl kde frontend, I'm uploading now
<apachelogger> \o/
 * asac dances
<Riddell> yay
<asac> so i can now depend on apturl without pulling in gnome?
<asac> mvo: ?
<mvo> asac: apturl-kde
<asac> Riddell: will you install that by default?
<mvo> asac: or how do you mean? you can depend on apturl | apturl-kde
<asac> otherwise i cannot say "apturl | apturl-kde"
<asac> which would pull in apturl still
<asac> mvo: if apturl-kde isnt installed by default it would be better to put it into the same package i guess ... and make that to only depend on stuff thats already there
<asac> but i guess it should just be seeded
<mvo> asac: yeah, having it in a single package is not very elegant
<sgallagh> mathiaz: ping
<apachelogger> asac: yeah, should be seeded, especially since it integrates with konqueror anyway
<apachelogger> + it doesn't introduce any new deps
<sebner> apachelogger: first is has to build though :P
<asac> apachelogger: ok. will you take care of the seeding?
<asac> or rather Riddell ?
<apachelogger> can do
<asac> anyway. let me know when thats done so i can adjust the depends of ubufox
<Riddell> one of us will
<asac> thx
<asac> oh
<asac> do apturl and apturl-kde conflict?
<asac> or are you parsing some env to call the right backend if both are installed?
<apachelogger> Riddell: first you need to poke apturl-* through binary new anyway :P
<sgallagh> mathiaz: What configure flags do you use for SSSD when packaging?
<apachelogger> asac: apturl binary in apturl-common package looks for KDE_FULL_SESSION and starts -kde if that is set
<apachelogger> if someone wants to enforce a certain frontend they might call apturl-kde or apturl-gtk directly
<asac> apachelogger: good. i assume it falls back to any (if available) if the right desktop variant is not installed?
<apachelogger> asac: if desktop is not proofen to be KDE it will use -gtk if it is installed, otherwise it starts whining
<apachelogger> I suppose that could be made if ENVAR;elif -x -gtk; elif -x -kde; else; fi ... that way it would also try -kde if desktop is not kde which might make sense after all :)
<asac> yeah. i think we should try all combinations if there is no match
<asac> order probably doesnt really matter
<mathiaz> sgallagh: hi - http://launchpadlibrarian.net/30797006/buildlog_ubuntu-karmic-amd64.sssd_0.5.0-0ubuntu1~ppa1_FULLYBUILT.txt.gz
<mathiaz> sgallagh: ^^ this is the build log - you should be able to find the configure flags in there
* slangasek changed the topic of #ubuntu-devel to: karmic alpha-4 released | Archive: main frozen for alpha-5, FeatureFreeze | 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
<sgallagh> mathiaz: Great, thanks. I just wanted to set up a script in my VM environment to build it equivalently to how you would
<mathiaz> Riddell: hey - are you planning to process the NEW source queue today?
<Riddell> mathiaz: yes, any requests?
<mathiaz> Riddell: sssd would be interesting to process
<ogra> pitti, kees, congrats for joining the TB !!!!
<sgallagh> mathiaz: What does "processing" entail?
<kees> ogra: thanks!  :)
<mathiaz> sgallagh: review the source package and accept in the karmic archive
<strider_> hi everyone
<sgallagh> mathiaz: Ok, any issues you come up against, please log a bug.
<mathiaz> sgallagh: sure
<strider_> what's the best way to keep track of what is being done in the development of Ubuntu ?
<sgallagh> strider_: Become a developer :)
<strider_> well i am a developer, you mean an official Ubuntu developer ?
<sgallagh> strider_: It was something of a joke. I meant that if you were a developer, then you can keep track of yourself :-P
<slangasek> mvo: I don't see any reason bug #353534 should be a blocker for alpha-5 - is it in progress currently?
<ubottu> Launchpad bug 353534 in linux "dapper->hardy->intrepid upgrade path leaves user with unmaintained kernel" [High,Fix released] https://launchpad.net/bugs/353534
<strider_> actually, i'm thinking about building a web platform to ease collaboration between developers , but I wanted to know how the things worked at the present moment. I'm missing a piece of the puzzle I guess
<sgallagh> strider_: What sort of a platform?
<sgallagh> strider_: Something like Fedora Community?
<strider_> let's take a simple example, I just updated karmic, and  i saw that empathy was removed from the system, i was wondering "where does that come from ? who made that decision ? where can i find it on the web"
<sgallagh> strider_: Yes please :)
<strider_> well, something based on Google wave, so there's no equivalent at the moment ;)
<strider_> Fedora community looks interesting
<jcastro> strider_: we call it launchpad. :D
<ogra> yeah
<strider_> Launchpad is a great tool, but when interaction between developers is concerned there is obviously something missing
<mvo> slangasek: no need to block - it was my target date, but we can move that to a6
<ogra> seb128, do you plan more uploads during the freeze ?
<robbiew-afk> slangasek: Ubuntu Repository of Software...UR Software for short
<robbiew-afk> lol
<slangasek> heh
 * robbiew never left
<sgallagh> How does one install the debuginfo for an ubuntu package to debug it?
<ogra> there is a wikipage about that
<pitti> ogra: thanks!
<ogra> :)
<Lutin> Compiling /usr/lib/pymodules/python2.5/ubuntutools/requestsync/lp.py ...
<Lutin>   File "/usr/lib/pymodules/python2.5/ubuntutools/requestsync/lp.py", line 25
<Lutin>     from ..lp.udtexceptions import *
<Lutin> SyntaxError: 'import *' not allowed with 'from .'
<Lutin> geser: when upgrading ubuntu-dev-tools ^
<pitti> that might be a 2.6ism
<pitti> tkamppeter: bug 419834 -- nice!
<ubottu> Launchpad bug 419834 in hplip "Needs porting to policykit-1" [Undecided,Confirmed] https://launchpad.net/bugs/419834
<slangasek> bwuh, who switched ubuntu-dev-tools from python-central to python-support?
<slangasek> DktrKranz: what does python-support have to do with "easing initial import into Debian"?
<DktrKranz> slangasek: there are plans to migrate almost every package to pysupport
<slangasek> whose plans?
<DktrKranz> some discussions in debian-python
<slangasek> there's a group of python package maintainers who think python-support is great and eschew python-central.  Just because they have plans doesn't make them relevant.
<seb128> ogra: yes, why?
<DktrKranz> even if pycentral will be dropped one day?
<seb128> ogra: do you plan to ask other meaningless questions?
<slangasek> DktrKranz: who is dropping pycentral?
<slangasek> the maintainer isn't dropping it, so long as python-support's maintainer fails to address its known problems
<rndm_> so /dev/fb0 isnt being created on aluminum 20inch imacs. the current livecd doesnt make it into x
<slangasek> recent discussion on debian-python consists of "we should have a single tool; neither python-support nor python-central is it"
<ogra> seb128, well, the armel buildds are 100% busy with kde stuff that was coming in yesterday, and i'd like to make A5 with arm given that we couldnt make A4 already and i'd like to match my deliverables at some point
<seb128> ogra: I did read the freeze email after this upload and I don't plan to break CD builds no
<ogra> thanks a lot
<ogra> (i dont mean to attck you or something with these questions, i just want to be prepared what to expect)
<DktrKranz> there are indeed open issues for both tools
<rndm_> not sure what to file a bug report against. installing from alternate and then installing the nvidia drivers works as a work around but you have to manually supply an xorg.conf to get around x barfing over no fb dev
<DktrKranz> Many sponsors will prefer pysupport over pycentral because the latter is known to have some more problems
<seb128> ogra: I usually try to not disturb things too much but to not block work or changes too much either
<ogra> seb128, yeah, i know and i know you enough to know that :)
<DktrKranz> and *I* (this won't mean *all*) think (based on practice) pysupport behaves well.
<slangasek> ArneGoetje, pitti: what are these language-pack-gnome-* packages that have been lingering in the uninstallable list, with no corresponding language-pack-*?  (ig,ks,pap,sa,shs,tk)
<pitti> slangasek: ah, I bet langpack-o-matic doesn't create empty language-pack-*; however, -gnome isn't actually supposed to have a hard depends: on the common langpack
<slangasek> DktrKranz: it behaves in ways that work most of the time, are pathological some of the time, and the maintainer has shown himself unwilling to address those cases.
<slangasek> pitti: well, even a Recommends: would show up on the report, we want Recommends to be fulfilled as well :)
<pitti> slangasek: seems we need to teach langpack-o-matic to create empty common langpacks then, or drop the depends
<slangasek> DktrKranz: anyway, maybe you'll find sponsors into Debian more easily that way, but I won't be one of them <shrug>
<DktrKranz> slangasek: I always found joss very collaborative, but that's probably just me. Are there issues with that change? If so, I will invest time fixing my mistakes.
<pitti> slangasek: bug 422760
<ubottu> Launchpad bug 422760 in langpack-o-matic "always generate common langpack" [Medium,Triaged] https://launchpad.net/bugs/422760
<slangasek> DktrKranz: I don't see any technical problems with it, I just noticed the change when looking at the install-time bug mentioned above
<slangasek> DktrKranz: I'm just generally dismayed by the convergence on an imperfect tool that doesn't seem to be getting any better
<slangasek> pitti: cheers
<DktrKranz> slangasek: I was just trying to improve things (at least from my POV). If that will turn to be a bad decision, I will fix my errors. By the way, thanks for sharing your thoughts! :)
<slangasek> DktrKranz: well, now that we've had this conversation I understand your reason for the change; it doesn't make me happy, but I can't claim that it's wrong ;)
<slangasek> DktrKranz: fwiw, in a sense ubuntu-dev-tools is now still blocked on "solving" the python politics in Debian anyway
<slangasek> because requestsync now uses python 2.6-specific syntax, and python 2.6 being the default in Debian depends on resolving certain compatibility issues
<slangasek> (you're welcome to fix the 2.6-specific syntax problem, if you prefer, but in the meantime I'm making the package installable again :)
<pitti> ttx: euca needs a Java Excel API? interesting...
<tkamppeter> pitti: HP is really the best printer manufacturer in terms of supporting Linux.
<pitti> tkamppeter: :)
<pitti> it actually seems that we can ship Karmic without any old PK stuff except for hal (which we don't even use any more)
<pitti> the only reason why we still need the old PK is because KDE still uses hal to mount internal drives
<pitti> but well, we'll settle that in karmic+1, I hope
<slangasek> mathiaz: you merged squid three weeks ago, but haven't been bothered that it's been uninstallable since? :-)
<ttx> pitti: not really. It needs drools, and drools provides some statistics thing that can output Excel, I suppose. But Euca doesn't make use of that specific drool feature
<pitti> ttx: it's just funny how it manages to pull in so much stuff it doesn't need
<ttx> pitti: it's the miracle of java libraries build dependencies. Multiplication of packages.
<ttx> <insert biblic reference here>
<YokoZar> pitti: If I work like crazy this week, I think it can go in
<YokoZar> The actual Wine 1.2 release won't be until Karmic +1 though, so I need to tweak all the dialogs and handle the dual-install case and such (since we need to ship both wine 1.0 and the latest beta, the "wine1.2" package)
<mathiaz> slangasek: where did you notice the squid package was uninstallable?
<slangasek> mathiaz: http://people.canonical.com/~ubuntu-archive/testing/karmic_probs.html
<slangasek> mathiaz: squid-langpack is a new source package that hasn't been synced; I'm doing that now
<mathiaz> slangasek: ok - thanks for taking care of this.
<slangasek> or at least, I'm trying to do that, if it ever bothers to show up in the queue :)
<ttx> pitti, about bug 422788: my understanding was that we should fix the packages so that they don't use the deprecated java-*-compat-* virtuals but properly depend on the new *-jdk stuff instead. That is, if something only builds with gcj, it should build-dep on gcj-jdk. See https://wiki.ubuntu.com/JavaTeam/LibraryPackaging
<ubottu> Launchpad bug 422788 in libjamon-java "need default-jdk migration" [High,Triaged] https://launchpad.net/bugs/422788
<pitti> ttx: hm, I'm afraid I don't know that; doko?
<pitti> hm, -ENODOKO
<ttx> pitti: I don't think we *need* to migrate all gcj-jdk stuff to build with openjdk for this release
<pitti> I thought doko was trying to get rid of gcj
<ttx> pitti: I can try, obviously, but I wouldn't make that a blocker
<pitti> but ICBW
<ttx> pitti: in karmic+1, methink
<pitti> ttx: so if you think gcj is correct, leave it like it is now, make a comment on the bug, and WONTFIX the karmic task
<pitti> (main task shuold still be kept open, I think)
<ttx> yes.
<jono> bryce, have you had any reports of current Karmic crashing when alt-tabbing with compiz switched on?
<bryce> jono, yes
<bryce> jono, not crashing so much as locking up
<jono> bryce, yeah, it locked my machine, I had to perform a hard reset
<jono> and now I can't switch compiz back on
<jono> cool, just wanted to check if you were aware
<bryce> jono, I have a fix, one sec
<jono> bryce, no rush, I can run without compiz until the fix is in
<bryce> jono, install this:  http://people.canonical.com/~ogasawara/lp419264/
<jono> thanks bryce :)
<ogasawara> bryce: fyi looks like this patch also got merged upstream
<bryce> jono, as a workaround when it locks up, do ctrl-alt-f1 and then kill the compiz process and you can recover your session
<bryce> ogasawara, excellent news
<ogasawara> bryce: tim just pulled my backport but we'll only need to carry it shortly until the next upstream rebase
<bryce> great
<bryce> ogasawara, thanks again for quick work with that patch :-)
<jono> thanks bryce, ogasawara :)
<ogasawara> bryce: no worries, it's easy when they're already on their way upstream
<sivang> anybody remember what's simon law's nick ?
<jono> sflaw?
<slangasek> seb128: empathy's .pc file references telepathy-glib, but the -dev package doesn't depend on it; this breaks rebuilding desktop-data-model - should I just commit a fix to bzr and let you pick it up for next upload?
<slangasek> no, wait, this branch is ~ubuntu-desktop, I guess I can't commit there... and the branch isn't up to date anyway
<seb128> slangasek, you can commit there
<slangasek> oh, ok
<geser> Lutin: bah, another error :( I guess pitti is right, relative imports are a 2.6ism
<slangasek> seb128: still, the branch doesn't seem to be up-to-date with the archive?
<seb128> slangasek, let me push my changes
<slangasek> seb128: ok
<slangasek> seb128: thanks :)
<taavikko> what controls usb devices in *.31 kernels*? in jaunty one could "rmmod uhci" and reload to gain function
<seb128> slangasek, changes pushed to bzr now
<mkoehler> hey guys, I've got a quick question for ya'll.  I'm looking to work on making some patches for some bugs on launchpad, but I'm not sure exactly which ones to go after.
<mkoehler> I was looking at a few programs (e.g. nautilus), but a lot of the bugs are marked as upstream bugs
<mkoehler> I was just wondering when something should be marked as an upstream bug (I've read the wiki a couple of times) and if there's a good project to work on
<ulaas> mkoehler, add quick view to nautilus
<mkoehler> is that related to a bug (wishlist or otherwise) that I can look at?
<ulaas> mkoehler, nope. but i think your name will be remembered if you make it work :)
<seb128> mkoehler, ubuntu doesn't write most of the softwares it distribute
<johanbr> mkoehler, I guess the "papercut" bugs would be a good place to start
<johanbr> https://wiki.ubuntu.com/PaperCut
<seb128> bugs in the upstream code are upstream issue
<mkoehler> yeah
<mkoehler> is there any way to just see those in launchpad
<ulaas> gnome-shell !!!! yay
<Kamusin> I sent an email about next ubuntu hugday (is waiting for moderation), can anyone take a look  please :)
<Kamusin> (this email was sent to ubuntu devel list!, I forgot say that heeh)
<slangasek> mathiaz: oh; turns out squid-langpack was already in, but had been left in universe, heh that's why it didn't hit the queue
<lifeless> slangasek: haha
<cody-somerville> Does anyone know how to use python apt to get information about a specific version of a package?
<lifeless> cody-somerville: yes
<slangasek> lifeless: "haha" on squid?
<lifeless> slangasek: yes
<lifeless> slangasek: not in a hostile fashion :)
<lifeless> cody-somerville: what do you need to do vis a vis package data?
<arpu> hello
<cody-somerville> lifeless, err.... say again? :)
<arpu> anyone know an ubuntu ppa kernel with this Patch ? http://bugzilla.kernel.org/attachment.cgi?id=22180
<lifeless> cody-somerville: 08:08 < cody-somerville> Does anyone know how to use python apt to get information about a specific version of
<lifeless>                          a package?
<cjwatson> http://en.wikipedia.org/wiki/Vis-%C3%A0-vis
<cjwatson> if the problem is comprehension
<cody-somerville> ah
<cody-somerville> lifeless, I just want to grab the file path
<lifeless> of the deb ? in the repo ?
<cody-somerville> lifeless, yes
<lifeless> cjwatson: thanks :)
<lifeless> gimme a sec, just grabbing the code conflict checker uses
<lifeless> cody-somerville: do you want to be using the local packages cache for metadata; the code I have handy reads packages.gz and goes from there
<cody-somerville> lifeless, I generate an "apt tree" and instruct python-apt to use that.
<lifeless> ok
<lifeless> 291 		
<lifeless>                 sections = parser.Section
<lifeless> 292 		
<lifeless>                 info = self._extract_package_identity(sections)
<lifeless> 293 		
<lifeless>                 url = mirror + sections['filename']
<lifeless> bah, loggerhead fail.
<lifeless> anyhow, thats how I'm doing it at the moment
<lifeless> thats inside a loop on the parser
<lifeless>             parser = apt_pkg.ParseTagFile(local_file)
<lifeless> 290 		
<lifeless>             while parser.Step() == 1:
<lifeless> you may be using a higher level, in which case this will be possibly useless :(
<cjwatson> if you have an apt.Cache object, then cache[pkgname].candidate.filename
<cjwatson> >>> import apt
<cjwatson> >>> cache = apt.Cache()
<cjwatson> >>> cache['man-db'].candidate.filename
<cjwatson> 'pool/main/m/man-db/man-db_2.5.6-1_i386.deb'
<cody-somerville> cjwatson, Thats what I'm doing but there are multiple versions of the package available.
<cody-somerville> cjwatson, so I want to get the filename of the older version
<cjwatson> >>> cache['man-db'].versions
<cjwatson> <VersionList: ['2.5.6-1', '2.5.5-3']>
<cjwatson> though only as of python-apt 0.7.9, I forget what one did before that
<mathiaz> cjwatson: while trying to install uec node, there is a prompt for the username and password
<mathiaz> cjwatson: would it make sense to preseed that as well?
<mathiaz> cjwatson: in order to get the most automated installation experience?
<cjwatson> mathiaz: it should already be preseeded to the same as was provided when installing the cloud controller
<cjwatson> mathiaz: modulo the node preseeding stuff actually working, of course
<cjwatson> mathiaz: see if http://CLUSTER-IP/node-preseed works
<mathiaz> cjwatson: hm - passwd/user-password-crypted is preseeded
<mathiaz> cjwatson: is the username automatically chosen?
<cjwatson> the username should be preseeded too
<cjwatson> question d-i passwd/user-fullname string
<cjwatson> question d-i passwd/username string
<mathiaz> cjwatson: neither in cloud.seed nor in node-preseed.conf
<mathiaz> cjwatson: node-preseed.conf has passwd/user-password-crypted and preseed/late_command commented out
<cjwatson> mathiaz: what does passwd/username look like in /var/log/installer/cdebconf/questions.dat?
<mathiaz> cjwatson: it says that the value is set to ubuntu
<mathiaz> cjwatson: we had to enter it manually though
<mathiaz> cjwatson: I'll double check that we're prompted for username
<mathiaz> cjwatson: the main bug we're run into is bug 422876
<ubottu> Launchpad bug 422876 in eucalyptus "avahi cluster detection is run before networking is brought up during installation" [Undecided,New] https://launchpad.net/bugs/422876
<cjwatson> mathiaz: I just fixed that in bzr
<mathiaz> cjwatson: great - thanks
<cjwatson> mathiaz: the main *main* bug is that eucalyptus-cloud doesn't start on a fresh install
<mathiaz> cjwatson: right - this is being worked on
<cjwatson> I'm completely blocked on that at this point
<cjwatson> more or less, anyway
<cjwatson> mathiaz: ah, I see the problem with preseed file generation, fixing
#ubuntu-devel 2009-09-02
<cjwatson> mathiaz: r488
<mathiaz> cjwatson: great - thanks
<Guest14892> what are the key differences btween karmic and jaunty ps iM A LINUX NOOB
<Turl> hi
<Turl> apturl package is broken
<Turl>  error creating directory `./usr/lib/python2.6/dist-packages/AptUrl/gtk': No such file or directory
<dholbach> good morning
<dholbach> vorian: bug 386428 is assigned to you, when will you take care of it?
<ubottu> Launchpad bug 386428 in xom "Please merge xom_1.2.1-1 (universe) from debian unstable" [Wishlist,In progress] https://launchpad.net/bugs/386428
<StevenK> ArneGoetje: I'd like to change the ibus.desktop to also have NoDisplay=true to hide it in the Applications menu. I've confirmed with both desktop and UNR that the preferences under System->Preferences is a seperate .desktop file. What do you think?
<ArneGoetje> StevenK: IMHO the System->Preferences entry is sufficient, so we don't need any other .desktop file. IMHO it should be removed by upstream.
<StevenK> ArneGoetje: That sounds fine too. Shall we patch it out first ourselves?
<ArneGoetje> StevenK: let's get the package maintainer's opinion first... I'll comment on the bug
<StevenK> ArneGoetje: Sounds good
<porthose> are alpha5 iso images available?
<pitti> Good morning
<tkamppeter> pitti, good morning
<tkamppeter> pitti, one additional thing about CUPS:
<pitti> hi tkamppeter
<pitti> good morning
<tkamppeter> Installing it, adds a blacklist against the usblp module, but if a user updates and the module is loaded, the module keeps dangling around blocking the printers.
<tkamppeter> pitti, Perhaps we should do "rmmod usblp" in postinst.
<pitti> no
<pitti> rmmod is evil, bad, and wrong
<pitti> and it might even fail
<pitti> but perhaps I was missing an update-initramfs call
<pitti> to make the blacklist go into the initramfs, too; otherwise there's a chance that it gets loaded there
<tkamppeter> pitti: Can modprobe more safely remove modules?
<pitti> tkamppeter: no, modules can't guaranteed to be removable
<pitti> something can still use the device, then it will just fail
<pitti> but in the worst case it causes kernel panics and all that
<pitti> tkamppeter: but after a jaunty->karmic upgrade you have to reboot anyway
<tkamppeter> pitti: Should we perhaps set this special bit which is also set on kernel updates and shows the user a pop-up telling him that he needs to reboot?
<pitti> tkamppeter: we can do that, yes; the postinst can check if upgrading from 1.3.x, and check if /usr/share/update-notifier/notify-reboot-required exists, and call that
<pitti> :q
<pitti> meh, compiz' focus handling sucks
<ogra> can someone rescore empathy on armel ?
<pitti> ogra: done
<ogra> thanks
<ogra> pitti, could you bump oo.o too ?
<pitti> ogra: done
<ogra> thanks again :)
<pitti> except... lazr.restfulclient.errors.HTTPError: HTTP Error 503: Service Unavailable
<pitti> ogra: web UI times out, too; sorry
<ogra> gah
<pitti> crank faster?
<ogra> there is only so much lever i can apply
<ogra> oo.o takes at least 36h
<ogra> cjwatson, did you bump dove to -203 ABI too (your changelog entry doesnt say so)
<cjwatson> ogra: no
<tkamppeter_> pitti, your AppArmor fixes on CUPS do not work, the usb backend only works with "sudo aa-complain cupsd".
<pitti> tkamppeter_: please reopen the bug and attach dmesg after a failed attempt
<pitti> I'm off for some two hours for some errands
<YokoZar> ArneGoetje: Can I ask for your opinion on https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/412195 please?
<ubottu> Launchpad bug 412195 in wine1.2 "ttf-tahoma-replacement makes some web-sites look ugly" [Undecided,Confirmed]
<ogra> cjwatson, dove bump comitted and pushed in platform seed and d-i ... in case you do another upload, please include it (doesnt look good for armel anyway since OO.o failed and is just being retried)
<ogra> cjwatson, thanks :)
<ArneGoetje> YokoZar: I will test the font myself and give you feedback
<YokoZar> ArneGoetje: Thanks.  I'm hoping it's something I can just fix with an upstream patch
<smb> pitti, Would you have time to have a quick look at bug 399877? Could that be a side effect of moving away from hal? To me it looks as there is a nautilus/banshee/whatever problem with the fact that the first partition of that device seems to be unusable but the second contains data.
<ubottu> Launchpad bug 399877 in linux "Unable to mount 80GB iPod with nautilus" [Medium,Incomplete] https://launchpad.net/bugs/399877
<t0bi1> hey guys, i disabled nautilus at startup in jaunty, but after the karmic-update its back again...i checked gnome-session-properties, but it aint there...where does it get started and how can i disable it?
<seb128> t0bi1, /desktop/gnome/session/required_components_list
<seb128> in gconf-editor
<t0bi1> thx!
<seb128> you're welcome
<t0bi1> brb
<iulian> pitti: Hi.  It seems that libyaml-perl is in dependency wait state due to libtest-cpan-meta-perl being in Universe.  I was thinking of writing a MIR for it but I noticed that libyaml-perl has 3 other dependencies in Universe.
<iulian> pitti: These dependencies were added because some tests failed.
<iulian> pitti: I'm not sure what to do.  Is a MIR needed for all dependencies?
<pitti> juanje: at least a main inclusion request bug; for simple perl libs we don't need a full-fledged MIR wiki page, but we still need to review the pacakges
<pitti> smb: I'll have a look
<tkamppeter> pitti, I have fixed the remaining AppArmor problem of bug 420015 now.
<ubottu> Launchpad bug 420015 in udev "usblp Kernel module needs to be removed and /dev/bus/usb/*/* made accessible for USB printers to work with CUPS 1.4.x" [Wishlist,In progress] https://launchpad.net/bugs/420015
<pitti> tkamppeter: oh, nice; saw your dmesg mail, but didn't read it yet
<tkamppeter> pitti: Still remaining problem is that the infinite loop of the usb backend (bug 420797) is still there.
<ubottu> Launchpad bug 420797 in cups "CUPS 1.4.0, USB backend hangs" [Critical,Confirmed] https://launchpad.net/bugs/420797
<iulian> pitti: I suppose that message was for me, right?
<pitti> iulian: oops, sorry
<pitti> yes
<pitti> meh, the apport retracers fail due to a wadllib exceptions
<pitti>   File "/usr/lib/python2.6/dist-packages/wadllib/application.py", line 809, in bind
<pitti>     value = validated_values[param.name]
<pitti> KeyError: 'content_type'
<pitti> did anyone happen to see this?
<tkamppeter> pitti, I trying to build CUPS, but the test suite prevents it:
<tkamppeter> FAIL: 1 warning messages, expected 0.
<tkamppeter> W [02/Sep/2009:13:17:43.805950 +0200] [CGI] Unhandled message: interface=org.freedesktop.DBus.Introspectable, path=/, member=Introspect
<pitti> right, I saw that as well yestercay
<pitti> it still built fine on the buildds, but I guess something changed in between
<pitti> james_w: would it be possible to suppress creating bzr brnaches for packages which have a Vcs-Bzr:?
<pitti> james_w: now people keep getting confused and send me merge requests against e.g. lp:ubuntu/apport/karmic
<james_w> technically, sure
<pitti> but they are totally useless, since they are unmergeable
<james_w> we don't want to do it wholesale
<james_w> we will fix it for cases like that and just use your branch
<pitti> but if a package already is maintained in bzr, anyone who uses the auto-import can just wreak more havoc?
<james_w> I'm waiting on some fixes to make that possible though
<james_w> yes, and I'm keen to fix it
<pitti> ok, thanks
<james_w> it was easier to just not special case anything to start and then fix up these cases later
<james_w> unfortunately we're still waiting on external changes though
<pitti> ok, I see
<geser> could someone please give-back: ibus-anthy liblauncher liblouis. They failed to upload on ia64 and once sparc as the upload happened when the source got promoted to main. Thanks
<iulian> pitti: Hmm, there are loads of packages that need to be promoted.  If we only promote yaml's deps, those dependencies will go in depwait state.  Is there an easy way to find all packages that need to be promoted? apt-cache + grep is not useful.
<pitti> iulian: in fact there is: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<cjwatson_> geser: done
<geser> iulian: you could try to simulate a install of each package in a pbuilder (or any other clean environment), filter out the needed packages and check for them the component
<tkamppeter> pitti, the CUPS upstream fix for bug 420797 has no effect. Seems that Mike has done a wild guess without testing.
<ubottu> Launchpad bug 420797 in cups "CUPS 1.4.0, USB backend hangs" [Critical,Confirmed] https://launchpad.net/bugs/420797
<geser> asac: is it a mistake that both xulrunner-1.9 and xulrunner-1.9.1 try to build a xulrunner-dev package? this caused a failed to upload error for xulrunner-1.9 on powerpc
<asac> geser: yes. xulrunner-1.9 is probably quite outdated?
<asac> hmm
<asac> could be that i forgot to remove it ;)
<asac> let me check
<iulian> geser: Good idea.  That ought to be much easier.
<geser> iulian: try something like that: for i in `apt-get -s install libtest-yaml-meta-perl | grep ^Inst | cut -d" " -f2`; do apt-cache madison $i | grep universe; done
<lifeless> uhm
<lifeless> where has runlevel and telinit gone ?
<lifeless> or perhaps a better question, can someone tell me what package they are in, on your running karmic ?
<pitti> $ dpkg -S /sbin/runlevel
<pitti> upstart: /sbin/runlevel
<pitti> lifeless: ^
<pitti> (same for telinit)
<lifeless> ah
<lifeless> my upstart didn'tupgrade
<lifeless> because of upstart-logd
<lifeless> so I'll be making a boot disk for my laptop tomorrow
<lifeless> is it worth filing a bug? if there were some way to say 'gotta have upstart > X || <old thing'
<asac> geser: fixed in xulrunner-1.9.head branch for .14
<EagleScreen> how can I change the text editor used by dch?
<ion> select-editor
<lool> Sorry what's the magic for calling cpp so that it dumps all macros it knows about?
<lool> Ah -dM
<lool> Found it in the man page, like last time </slap>
<soreau> I am writing a script that installs some trivial components (extra compiz plugins in this case) and needs certain dependencies. I would like to have the dependencies in the script checking if they're installed before running apt-get install blah blah. Is there an easy way to check if a package is already installed via bash script?
<soreau> I was thinking about grepping dpkg -l but that seems a bit cumbersome
<lool> cjwatson: Would love if you could apply the minor fix I just pushed to lp:~ubuntu-core-dev/console-setup/ubuntu in Debian if it's not there already (s/dpkg --print-installation-architecture/dpkg --print-architecture/)
<cjwatson> lool: already done in console-setup 1.37
<lool> k that's what I guess thanks
<lool> guessed
<Chipzz> soreau: dpkg --get-selections
<soreau> Chipzz: What's the difference between 'install' and 'deinstall' there?
<soreau> That is a very nice looking list though ;)
<ScottK> soreau: A more elegant way to solve the problem would be to put your script into a Debian package and have that package depend on the packages that need to be installed.
<soreau> ScottK: If that were the case, I would just make a deb package compiz-plugins-experimental. The reason for the script is that it should work on other distros too provided the dependencies are installed for that system
<ScottK> Then a dpkg solution won't work either.
<soreau> I'm just tailoring it to fit ubuntu since it's the most popular and more noobs use it
<cjwatson> soreau: it wouldn't be all that much less efficient to just 'apt-get install' them unconditionally, and probably easier
<cjwatson> anyway, dpkg --get-selections is wrong; that lists desired states, not current states
<soreau> cjwatson: That's what it does currently
<soreau> and that's how I'm thinking of keeping it, just tinkering with the script and will write a how-to on the forums
<cjwatson> you probably want something more like the third column of:  dpkg-query -W -f '${Status}\n' $packages
<soreau> cjwatson: ok
<soreau> Thanks for all your help guys, gotta go to work
<cjwatson> you could use 'apt-get --no-upgrade install', even
<tkamppeter> pitti, I have found a fix for bug 420797 now. Can you upload CUPS, bug is probably severe enough to let the fix go into Alpha 5.
<ubottu> Launchpad bug 420797 in cups "CUPS 1.4.0, USB backend hangs" [Critical,Confirmed] https://launchpad.net/bugs/420797
<pitti> tkamppeter: yay you
<pitti> tkamppeter: it might not make alpha-5, since the candidate images are already built, but of course people can dist-upgrade after installation, so we should still get it uploaded
<cjwatson> we're going to need a respin
<cjwatson> really needed to sort out a grub issue
<pitti> ok, uploading right away then
<cjwatson> Keybuk: did you say you'd run into fsck failing due to timestamp skew again?
<pitti> tkamppeter: did you commit the fix? bzr pull gives nothing new
<pitti> tkamppeter: forgot to push? in the bug you said you committed
<tkamppeter> pitti, now it is pushed.
<pitti> tkamppeter: hm, now I get a "bzr: ERROR: mismatched lock context and write group. None, <bzrlib.transactions.WriteTransaction object at 0xa118dac>"
<pitti> tkamppeter: ah, works now
<Keybuk> cjwatson: a couple of people have reported it
<Keybuk> but so far the reasons have been explainable by other problems
<cjwatson> cr3: meet Keybuk
<cjwatson> I've noticed it myself, though only once and it didn't happen next time; I wonder if it's something to do with unreliable NTP sync
<Keybuk> the two I've seen were
<Keybuk> - installing over top of Windows, UTC=yes but hardware clock was in localtime
<Keybuk> Live CD doesn't "save back" the time
<Keybuk> so the first boot, you have the wrong time (double timezone)
<Keybuk> then NTP fixes that
<Keybuk> then you shutdown and save the hwclock
<Keybuk> and then the second boot, your mount time is in the future
<Keybuk> (and after that, it's fine)
<pitti> tkamppeter: uploaded
<davmor2> Keybuk: I'm having issues on every first reboot
<Keybuk> the second is Scott Ritchie, who dual boots between jaunty and karmic, and one is UTC=no and the other is UTC=yes which is clearly not going to work ;)
<Keybuk> davmor2: first reboot after what?
<cjwatson> FWIW I've seen it on a server install in kvm with a blank disk
<cjwatson> which is about the simplest scenario imaginable
<cjwatson> unfortunately, as I say, it didn't happen the next time when I was trying to look at it
<Keybuk> yeah that's the problem
<davmor2> Keybuk: install
<Keybuk> a couple of people have hit it
<Keybuk> then "fixed" it and carried on
<Keybuk> to debug, I need them to stop at the fsck prompt and reach for help
<Keybuk> since that's the only time we can see the disparity between the hardware and system clocks ;)
<cjwatson> fsck didn't prompt in the case I saw - it just exited 1
<Keybuk> right, it'll say on the screen what the difference between the timezones is though
<davmor2> Keybuk: tell me what you need and give me 20 minutes
<gnarl> Not sure this was somehow involved in my other issue but it seems apturl_0.4.0ubuntu3 ist not installable on my system
<Keybuk> davmor2: do an install, and the reboot, and it should fail to boot
<Keybuk> with fsck outputting information
<Keybuk> need the info fsck outputs
<Keybuk> and "hwclock --debug --show", "grep UTC /etc/default/rcS" and "date"
<davmor2> Superblock last mount time (Wed Sep  2 16:18:53 2009, now = Wed Sep  2 15:31:31 2009) is in the future this info or all of it?
<mathiaz> cjwatson: hi - I'm testing the new daily -server iso.
<mathiaz> cjwatson: it seems that the node-preseed file is not generated correclty
<cjwatson> mathiaz: ok, details?
<mathiaz> cjwatson: /etc/eucalyptus/node-preseed.cfg doesn't exist at all once the system is installed
<davmor2> Keybuk: right re-installing now the line above was from my last install
<mathiaz> cjwatson: /etc/eucalyptus/node-preseed.conf to be correct
<cjwatson> mathiaz: can I see logs?
<mathiaz> cjwatson: sure - one moment
<sistpoty|work> Keybuk: imho fsck shouldn't panic in this situation, would that be a solution?
<mathiaz> cjwatson: http://people.canonical.com/~mathiaz/euca-cc-install.log.tgz
<cjwatson> mathiaz: what does euca-cc.preseed contain?
<davmor2> keybuk: do you want all the info dropping in bug 422869?
<ubottu> Launchpad bug 422869 in e2fsprogs "fsck halts bootup when checked file has timestamp in the future from other Ubuntu installation" [Undecided,Incomplete] https://launchpad.net/bugs/422869
<mathiaz> cjwatson: http://people.canonical.com/~mathiaz/euca-cc.preseed
<cjwatson> mathiaz: you aren't installing eucalyptus-udeb
<cjwatson> -ianna/choose_modulesstring modules
<cjwatson> oops
<cjwatson> d-i anna/choose_modules string modules
<cjwatson> that should be:
<cjwatson> d-i anna/choose_modules string eucalyptus-udeb
<NCommander> Stupid question, but if I do apt-get dist-upgrade in the live environment, then install, do those updates translate across?
<mathiaz> cjwatson: oh right - paste failure
<mathiaz> cjwatson: I'll try again
<cjwatson> NCommander: no
<NCommander> That's what I thought :-/
<cjwatson> (intentionally)
<mathiaz> cjwatson: with the corrected line in the preseed
<maco> NCommander: use net install. then youre always up to date ;)
<NCommander> maco, I need to use live images in this case
<maco> oh boo
<maco> chroots?
<Keybuk> sistpoty|work: disagree
<Keybuk> davmor2: interesting that your software and hardware clocks are not out by a timezone multiple
<davmor2> Keybuk:  but it is from utc to timezone
<Keybuk> <davmor2> Superblock last mount time (Wed Sep  2 16:18:53 2009, now = Wed Sep  2 15:31:31 2009) is in the future this info or all of it?
<Keybuk> ?
<Keybuk> oh, sorry
<cjwatson> that isn't software and hardware clocks, is it? it's time when filesystem was last touched (software) to current time (hardware)
<cjwatson> or possibly vice versa software/hardware, I forget
<Keybuk> right you took 13 minutes to reboot
<Keybuk> used to seeing those numbers closer together
<davmor2> Keybuk: I was running more than one install :)
<davmor2> Keybuk: do you want us to use that bug or would you like us to open a new one for this?
<Keybuk> open a new one
<Keybuk> scott ritchie's bug is very clear and obvious
<Keybuk> and is his own config error
<davmor2> np's
<sbeattie> Keybuk: I'm seeing it guests on karmic's virtualbox, where it's taking the host's setting (in PDT -0700) and exporting it to guest as utc (-0000) which means on reboot it thinks the current hardware time is nearly 7 hours earlier than the superblock last modified time.
<sbeattie> This results in being dropped to a shell to manually fsck.
<Keybuk> sbeattie: that should be ok though surely
<Keybuk> assuming the install has UTC=yes
<kirkland> bryce: i think you added Ubuntu to the spell-check database in Karmic, one of the paper cuts, right?
<kirkland> bryce: i was hoping to add virtualization
<sbeattie> UTC is set to yes. The dropping to a shell for a manual fsck happens on every cold boot.
<kirkland> bryce: can you give a pointer?
<Keybuk> sbeattie: what is the exact fsck message when it happened?
<davmor2> Keybuk:  bug 423247
<ubottu> Launchpad bug 423247 in ubuntu "Superblock last mount times cause fsck to fail" [Undecided,New] https://launchpad.net/bugs/423247
<davmor2> keybuk: is that everything you need or is there anythind else?
<davmor2> anything even
<Keybuk> don't know, please leave it at that root prompt for a moment
<Keybuk> err
<Keybuk> you haven't pasted all the hwclock output
<Keybuk> more specifically, you haven't pasted THE MOST IMPORTANT BIT! :D
<davmor2> keybuk: no probs
<davmor2> I'll add the rest
<Keybuk> interesting that your "last mount time" is an hour in the future
<Keybuk> the real, genuine future
<Keybuk> your hardware clock looks like it has the right value (15:40ish UTC)
<Keybuk> UTC=yes matches that
<Keybuk> your timezone file looks like it has the right value (16:40ish BST)
<Keybuk> and your resulting system clock is right (16:40ish UTC)
<Keybuk> what's _wrong_ is that your filesystem was unmounted at 17:30 BST
<Keybuk> which is an hour from now
<Keybuk> unless Wolverhampton is being dragged into a space time vortex?
<Keybuk> ok
<Keybuk> let's try something else
<Keybuk> can you do the install again
<Keybuk> (wiping it)
<sbeattie> Keybuk: here's the fsck message I see in a vbox guest: http://www.nxnw.org/~steve/tmp/fsck-on-boot.png
<Keybuk> but don't reboot, open a terminal instead
<Keybuk> sbeattie: again, output of "hwclock --debug --show", "grep UTC /etc/default/rcS" and "date" plz
<sbeattie> Keybuk: yep, one sec
<davmor2> Keybuk: added
<Keybuk> davmor2: thanks - I think this is a problem somewhere in the installer
<Keybuk> davmor2: this is your *first* reboot, right?
<Keybuk> you've not rebooted the real system yet?
<cjwatson> I'm happy to help if it is, but will need advice
<Keybuk> cjwatson: well, the filesystem was unmounted in an hour's time
<Keybuk> and the hardware and system clock are otherwise correct
<Keybuk> so that suggests to me (assuming this is the first boot of the installed system) that the system clock was wrong during the installer session
<Keybuk> (live I guess)
<cjwatson> hmm
<cjwatson> log-output -t clock-setup chroot /target hwclock --systohc --debug &
<davmor2> Keybuk:  On this box this was first reboot from the installed system
<cjwatson> in clock-setup's finish-install script
<cjwatson> I wonder if that's at all related
<Keybuk> errr
<davmor2> Keybuk:  normally it is the first reboot after installation though
<Keybuk> shouldn't think so
<sbeattie> Keybuk: http://www.nxnw.org/~steve/tmp/hwclock-info.png
<Keybuk> davmor2: ok, so we need to go through an install
<Keybuk> and keep checking the hardware and system clocks as we go through each step
<davmor2> yes
<Keybuk> see if there's some point it goes wrong
 * cjwatson places a small bet on it being in finish-install
<davmor2> Keybuk: would this be easier from an alternate cd in expert mode?
<Keybuk> sbeattie: fresh install as well?
<cjwatson> though if it's not there, it'll be in clock-setup when it calls rdate
<Keybuk> davmor2: and alternate install is an entirely different installer ;-)
<cjwatson> davmor2: have you already reproduced it with an alternate CD?
<cjwatson> the alternate and desktop installers do have the bits of code I consider most likely to be causing this problem in common
<cjwatson> but that's an estimate ...
<davmor2> just checking with kirkland about his
<cr3> I can kick off an alternate install if anyone likes
<sbeattie> Keybuk: roughly; like I said it happens every cold boot (ubuntu-server install from 24 hours ago).
<Keybuk> cjwatson: oddly, the hardware clock looks *right* though
<Keybuk> sbeattie: weird, because again, your hardware and system clock are right
<cjwatson> presumably the unmount time will be set from the system clock
<Keybuk> welkl
<cjwatson> so if the system clock is wrong, and the hardware clock isn't set (properly) from it on shutdown
<Keybuk> it's very odd that your hardware clock thinks it's 8am ;)
<Keybuk> cjwatson: that's true
<Keybuk> oh
<Keybuk> no
<Keybuk> sbeattie: it's obvious what your problem is
<Keybuk> sbeattie: your hardware clock says 8am, which is PDT not UTC
<Keybuk> but your system has UTC=yes
<Keybuk> so the system clock is set 7 hours wound back from that
<Keybuk> then you boot
<Keybuk> NTP runs
<Keybuk> and resets your system clock forwards
<Keybuk> and then you unmount on shutdown
<Keybuk> with a "future" time
<Keybuk> your "hardware clock" would normally be saved (at least mucking up the clock)
<Keybuk> but since it's a virtual machine... that's discarded
<Keybuk> so you hit it every boot
<Keybuk> sbeattie: change UTC=yes to UTC=no
<davmor2> cr3: are any of your issues on alternate?
<sbeattie> Keybuk: right; but note this only happens on karmic, do to (apparently?) more strict checking by fsck, jaunty and earlier guests don't hit it on boot.
<cr3> davmor2: I haven't noticed, I'm preparing an installation now
<Keybuk> sbeattie: not so much
<Keybuk> fsck upstream had slipped in a hack for Ubuntu to not fail on clock errors
<Keybuk> I undid that hack
<sbeattie> Keybuk: oh, hah.
 * sbeattie wanders off to file a bug against virtualbox, for not exporting the actual UTC to the guest.
<dholbach> Ubuntu Developer Week in #ubuntu-classroom - NOW! :-)
<kirkland> davmor2: what was you question for me?  is this happening on server install?  yes, absolutely.
<davmor2> cool so it should happen on alternate too :)
<jjardon> pitti, I've added some comments about gnome-power-manager in https://wiki.ubuntu.com/Halsectomy; maybe they are of your interest
<davmor2> Keybuk: I'll run an expert install and save it all to a file it should all > to a txt file shouldn't it
<mathiaz> jdstrand: hey - does bug 423246 make sense?
<ubottu> Launchpad bug 423246 in openldap "slapd should have a ufw profile" [Undecided,New] https://launchpad.net/bugs/423246
<LaserJock> slangasek: if I do some work on the Edubuntu seeds is that going to mess up Alpha 5 release management at all?
<jdstrand> mathiaz: it does in general to me, we do for several other services
<mathiaz> jdstrand: great - thanks
<jdstrand> mathiaz: I peeked at the debdiff, but haven't really gone over it. conceptually, I like it though :)
<cjwatson> LaserJock: if in any doubt, wait; it's certainly possible
<LaserJock> cjwatson: yeah, I'd rather not hold up progress trying to get the Edubuntu DVD seeds worked out. I can wait a couple days
<cjwatson> commit to a branch ...
<ogra> yippie, my notifications are back where they belong :)
<ebroder> Anybody from ubuntu-sru around who could look at bug #330766?
<ubottu> Launchpad bug 330766 in pulseaudio "pulseaudio hangs, prevents login, home as ntfs" [Unknown,Fix released] https://launchpad.net/bugs/330766
<pitti> jjardon: thanks for your help with that
<jjardon> pitti, :) . I've added some upstream bugs too
<davmor2> right running from live cd it's too much of a headache from alt :(
<bryce> kirkland, yep, snag the aspell-en and hunspell packages, and append your word(s) to the extrawords.txt files in each
<bryce> kirkland, whoops, should be hunspell-en-us
<hyperair> dpkg: error processing /var/cache/apt/archives/apturl_0.4.0ubuntu3_all.deb (--unpack): error creating directory `./usr/lib/python2.6/dist-packages/AptUrl/gtk': No such file or directory
<hyperair> is anyone getting that?
<james_w> hyperair: check the bug reports
<hyperair> ah
<hyperair> hmm three of the same bug eh
<ogra> fis was uploaded 1h ago
<ogra> *fix
<hyperair> ah
<davmor2> Keybuk: Right I've added clock.txt to the bug it list when I took the info.  I went for key points I could think of through the install and then post install until the fsck issue.
<Keybuk> what was the bug# ?
<davmor2> Keybuk: bug 423247
<ubottu> Launchpad bug 423247 in ubuntu "Superblock last mount times cause fsck to fail" [High,Confirmed] https://launchpad.net/bugs/423247
<davmor2> Keybuk: hope it makes sense
<davmor2> Keybuk: On a plus note you know it's reproduce-able :)
<Keybuk> hmm
<Keybuk> Wed 02 Sep 2009 06:18:42 PM UTC  -0.935498 seconds
<Keybuk> UTC=yes
<Keybuk> Wed Sep  2 17:21:36 UTC 2009
<Keybuk> --
<Keybuk> that's very odd
<Keybuk> davmor2: did the install take 10 minutes or 1h10m ?
<davmor2> probably 10 minutes give or take
<Keybuk> ok
<Keybuk> so the hardware clock is being set during the install
<Keybuk> and being set an hour forward
<Trewas> btw I hit that fsck ~bug today after upgrading a karmic installation in virtualbox (a couple of days worth of updates)... but I didn't take notice of any details
<Keybuk> Trewas: thanks for your help ;-)
<davmor2> Keybuk: so this happens not always on first reboot but certainly on second reboot.  That is a reboot from the installed system.  rather than the one that spits out the cd if you get me :)
<Keybuk> davmor2: yeah
<Keybuk> is definitely an installer bug
<Keybuk> it's storing local time in the hwclock, not UTC
<davmor2> Keybuk: Glad my log was useful then
<Keybuk> davmor2: OOI grep GMT /etc/default/rcS
<davmor2> Keybuk: Nothing shows up
<Keybuk> ok, just checking
<torkel> Keybuk: is that something that will affect upgraded systems too? Because I have seen it on my laptop which is upgraded from jaunty to karmic?
<Keybuk> no, shouldn't think so
<torkel> changing to UTC=yes seems to have fixed it though
<lool> Keybuk: Not sure what you said to Cody Russell on xsplash; I think you suggested using system wide config files for the list of apps to wait for, but that doesn't work to wait for different components when multiple environments are installed and user-selected on the gdm screen
<lool> Keybuk: Did you take that into account and decided it was not worth supporting, or did I miss how it would be supportable?
<lool> Keybuk: #418716
 * ccheney is signing the contract on his new home today, buying a new house is scary, heh
<soren> cjwatson: I'm working on making the eucalyptus configuration not a conffile. I'm not sure how to handle this on upgrades. Can you offer some advice on that?
<soren> mathiaz: I've merged your two Eucalyptus branches. Can you mark them as merged, please?
<davmor2> bryce: are you about?
<bryce> davmor2, need something?
<davmor2> I'm just tracking down the bug number
<davmor2> bryce: bug 421225 I'm about to try an install from the latest iso is there anything that you need info wise?
<ubottu> Launchpad bug 421225 in xorg-server "Xorg freeze" [High,Confirmed] https://launchpad.net/bugs/421225
<bryce> davmor2, apport-collect <bug-num> and steps to reproduce,
<bryce> davmor2, you're seeing this on -ati?
<davmor2> yes
<davmor2> but I haven't tried out todays images yet only yesterdays
<bryce> yeah there's a new -ati uploaded yesterday which would be worth doublechecking
<davmor2> bryce: right np's I let you know :)
<davmor2> bryce: same thing as yesterday.  I knocked splash off the kernel line so at least I can now access the terminal
<mathiaz> soren: they've already been marked as merged.
<slangasek> smoser: do we have candidate EC2 AMIs for alpha5 yet that I can link from the tracker?
<soren> mathiaz: Sort of :)
<soren> mathiaz: They're marked as Merged, but their status is still development (presumably because they were merged into a branch that is not the trunk).
<mathiaz> soren: ok - fixing this as well then
<mathiaz> soren: the merge proposal was marked as merged
<smoser> slangasek, just now, yes.
<slangasek> smoser: ok, cool - what are the AMIs?
<smoser> us-east-1.i386.karmic.ami:ami-3520c05c
<smoser> us-east-1.x86_64.karmic.ami: ami-99df3ff0
<smoser> slangasek,  but those aren't public at the moment
<slangasek> smoser: should they be made public for testing?
<smoser> yes, except
<smoser> the name
<smoser> ami-99df3ff0   ubuntu-alphas-us/karmic-x86_64-alpha5.manifest.xml
<smoser> thats how i bundled/registered it
<smoser> what do you think? should i re-register under a different name?
<smoser> or is it ok that it says 'alpha5'
<smoser> slangasek, ^^
<slangasek> smoser: that doesn't seem critical IMHO
<smoser> ok. then i'll flip them to public
<slangasek> smoser: sounds good
<davmor2> bryce: bug 421225 apport-collect wasn't all that  good :(  I've added my lspic-vvnn Xorg.0.log and syslog anything else I can do for you?
<ubottu> Launchpad bug 421225 in xorg-server "Xorg freeze" [High,Confirmed] https://launchpad.net/bugs/421225
<bryce> davmor2, oh xsplash must not have apport hooks
<smoser> slangasek, those are public
<mathiaz> cjwatson: hey - while going through the generated preseed for the node installation, all of the questions asked during the cluster controller installation are included but commented out in the generated preseed file
<mathiaz> cjwatson: it looks like a logic problem in the question function from eucalyptus-udeb.finish-install
<mathiaz> cjwatson: the answers are correct though
<davmor2> bryce: the end of the syslog file is interesting
<bryce> davmor2, add your gdm log files too
<bryce> davmor2, RT kernel?
<davmor2> bryce: gnome-session timing out
<bryce> no, what's the RT business there?
<davmor2> bryce: No idea default ubuntu iso
<davmor2> 20090902.1 or .2
<bryce> davmor2, can you explain how you're determining that you're getting the same bug as #421225 ?
<bryce> (X freeze problems can arise from a variety of different root causes, but all look the same at first glance)
<slangasek> smoser: cheers
<slangasek> smoser: are European AMIs also in progress?
<davmor2> bryce: It looked the same bug when it was reported.  I can report a separate one if you want
<smoser> slangasek, i'm gonna sniff these really quick
<smoser> then i'll migrate
<bryce> davmor2, yeah thanks, let's do that
<bryce> better to have a dupe than to have two bugs and get only one fix
<davmor2> bryce: no probs I'm having issues copying the gdm logs
<davmor2> bryce: Okay I got it :)
<cjwatson> soren: it gets complicated - the "Config file handling" section of debconf-devel(7) might help
<cjwatson> mathiaz: hmm, I thought I'd fixed that - logs again?
<mathiaz> cjwatson: sure - just one moment
<cjwatson> Keybuk: what do you think about http://paste.ubuntu.com/264016/ ?
<davmor2> bryce: any preference on package I file against?
<bryce> davmor2, just file against xorg
<davmor2> np's
<bryce> I've got scripts that will move the bug to the appropriate place :-)
<taavikko> #422989 should be dublicate of #419126 ?
<mathiaz> cjwatson: http://people.canonical.com/~etienne/euca-cc-install.tar.gz
<cjwatson> gar, no visible errors
<cjwatson> mathiaz: can I get node-preseed.conf too?
<davmor2> bryce: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/423415
<ubottu> Launchpad bug 423415 in xorg "Ati driver issues when logging into desktop" [Undecided,New]
<bryce> davmor2, thanks
<davmor2> bryce: anything else before I move the cd onto another machine so I can continue to test.  Ps had no issues testing on that box last week just thought of  that
<mathiaz> cjwatson: http://people.canonical.com/~etienne/node-preseed.conf
<bryce> davmor2, dmesg please?
<davmor2> bryce: np's
<bryce> davmor2, also your gdm0.log appears to be an Xorg.0.log - can you check that you've attached /var/log/gdm/:0.log and maybe :0.log.1
<cjwatson> mathiaz: hmm
<davmor2> bryce: that is the right one.  It took me a while to figure out how to copy it.  In the end I did cat :0.log > /mnt/drive/...
<bryce> davmor2, hmmmm that is sounding wrong
<davmor2> bryce: you are on about the logs that are in /var/log/gdm right?
<cjwatson> mathiaz: don't wait for me, but I'm trying to work this out - I'll need to attempt to reproduce it locally
<mathiaz> cjwatson: right - not critical for alpha5
<bryce> davmor2, that's right
<mathiaz> cjwatson: should I file a bug in LP?
<cjwatson> mathiaz: yes please
<mathiaz> cjwatson: ok
<davmor2> bryce: figured out why I couldn't copy it cp didn't like the : at the begining
<bryce> ah yeah gotta escape that
<bryce> it's a shame gnome includes that in the filename
<bryce> guess they're just reusing $DISPLAY for it tho
<davmor2> bryce: right added 0.log which is a direct cp of :0.log and dmesg
<mathiaz> cjwatson: bug 423424
<ubottu> Launchpad bug 423424 in eucalyptus "Generated node preseed file has commented out answers" [Undecided,New] https://launchpad.net/bugs/423424
<bryce> davmor2, okay thanks.  I don't think we have a good error message yet, but am not sure where to look next.  I'll send the bug upstream and maybe they can give guidance
<davmor2> bryce: no worries just ping me if you need me for anything
<slangasek> smoser: European AMIs?
<smoser> slangasek, give me 2 minutes
<slangasek> okie
<ion> Â½.
<ion> Whoops
<ion> That would be me killing ssh, thinking 0) the us keyboard layout is active and 1) the connection is dead.
<ogra> what is it though ? my font is so small
<ogra> does it mean "half a dot" ?
<mathiaz> cjwatson: what's the state of the node acknowledgement process on the cluster controller?
<mathiaz> cjwatson: is there a command that needs to be run to register/accept the nodes on the cluster controller?
<ion> Yeah, the `~ key is Â§Â½ in the (awful) fi layout.
<cjwatson> I haven't written that bit yet
<mathiaz> cjwatson: ok - cool.
<cjwatson> if somebody would like to do it, it shouldn't be hard
<soren> ion: Danish as well.
<cjwatson> euca_conf --discover-nodes was the agreement, I think
<cjwatson> it'd basically be a wrapper around avahi-browse
<cjwatson> mathiaz: I just had a brainwave about the preseeding thing - you're preseeding the cluster installation, right?
<mathiaz> cjwatson: hm - not in this use case
<cjwatson> oh, ok
<cjwatson> scratch that brainwave then
<mathiaz> cjwatson: ie the last installer logs I send you
<mathiaz> cjwatson: it's true that I have other installations that I preseed - however this time around it was an install from the iso on plain hardware
<cjwatson> I've traced it back as far as the seen flag simply not being set in questions.dat
<cjwatson> at least not for all but a very few questions
<mathiaz> cjwatson: one question that was asked was the timezone
<mathiaz> cjwatson: the node-preseed generated file has the correct answer (Us/Central)
<cjwatson> right, the value is correct but it doesn't have the flags set properly
 * mathiaz nods
<cjwatson> flags are set for the questions that were preseeded, but not for those asked interactively
<cjwatson> which implies a cdebconf bug
<davmor2> bryce: it only effect ubuntu and maybe xubuntu kubuntu is working fine on that ati box
<smoser> slangasek, i'll get those to you, but its going to be a while
<slangasek> smoser: ok.  how's testing on the US ones, in the meantime?
<davmor2> bryce: it appears that there was an issue with the livefs so is the older ati driver
<smoser> well, so far fine other than bug 419306
<ubottu> Launchpad bug 419306 in python-boto "boto.utils.get_instance_userdata() hangs for a long time if no userdata is provided" [Undecided,New] https://launchpad.net/bugs/419306
<smoser> which we think we have to just document as known issue for this release.
<cjwatson> oh, wait, cdebconf deliberately doesn't save the seen flag in d-i. argh. I'd forgotten about that.
<mathiaz> ttx_: http://paste.ubuntu.com/264075/
<slangasek> mathiaz: ubuntu-server build is up
<kirkland> slangasek: we're already rsync'ing
<kirkland> slangasek: ;-)
<slangasek> kirkland: good, good
#ubuntu-devel 2009-09-03
<slangasek> smoser: incidentally, does the UEC image generation process also create a file list for the image?
<slangasek> if so, it would be nice to have that published next to the images, so we can see when things are out of date
<smoser> slangasek, you mean like 'find /' ?
<smoser> it does not
<slangasek> smoser: a list of the .debs that went into it
<slangasek> (with versions)
<slangasek> this is standard output for the livefs buildd jobs
<slangasek> so perhaps it exists somewhere but you're just not grabbing it at present
<slangasek> (they're called foo.manifest when they're generated with the livefs)
<smoser> i dont know. i'll poke around.
<smoser> eu karmic-x86_64-alpha5: ami-9e6249ea
<smoser> eu karmic-i386-alpha5: ami-986249ec
<smoser> slangasek, ^^ (those are eu ami ids)
<slangasek> posted to the tracker
<slangasek> how's the image testing going, so far?
<slangasek> (no results posted to the tracker, so I have no idea if these images are good or if we're facing more re-rolls and a delay in the alpha publishing)
<smoser> slangasek, i really have only sniff tested so far. been struggling with the publish and such. i will run through the testing.
<smoser> and updated tracker
<slangasek> ok
<slangasek> cody-somerville: xubuntu images are available for testing for alpha5, if you haven't seen
<cody-somerville> thanks
<slangasek> luisbg, TheMuso: likewise for ubuntustudio
<slangasek> superm1: and also for mythbuntu
<TheMuso> slangasek: Saw the tracker email earlier, getting ready to test now.
<slangasek> ok
<slangasek> smoser: you consider http://iso.qa.ubuntu.com/qatracker/result/2960/339 a failed test due to bug #419306?
<ubottu> Launchpad bug 419306 in python-boto "boto.utils.get_instance_userdata() hangs for a long time if no userdata is provided" [High,New] https://launchpad.net/bugs/419306
<slangasek> smoser: is there no workaround for that bug?
<slangasek> (or did the test fail for other reasons?)
<smoser> slangasek, it is easily worked around
<smoser> how do i show that?
<smoser> i was really just trying to mark a bug. and hit save to say "known bug" . but i think i registered 'fail'
<slangasek> smoser: there's a "Result:" field, click it to 'passed' instead of 'failed'
<slangasek> (and then put something in comments, if you like)
<smoser> am i able to edit existing ? or does each time i do it add a new 'run' of the tests?
<slangasek> smoser: it only lets you edit the existing
<slangasek> (AFAIK)
<slangasek> oh, or you may need to click on the magnifying glass on the far end of the row
<slangasek> smoser: ^^
<slangasek> LaserJock: hi - you disappeared before I could respond to your edubuntu seed inquiry this morning
<LaserJock> slangasek: sorry about that
<slangasek> LaserJock: are the current seeds suitable for testing as an alpha5 candidate?
<LaserJock> slangasek: not really
<LaserJock> the problem is that the Edubuntu DVD is just building from Ubuntu's DVD seed
<slangasek> oh, there's not a separate edubuntu seed pod?
<LaserJock> as edubuntu.karmic doesn't yet have it's own seed (that's what I'm trying to add)
<LaserJock> there is
<LaserJock> but it depends on Ubuntu's seed pod
<LaserJock> or inherits is maybe a better term
<slangasek> adding edubuntu.karmic doesn't seem like it should disrupt anything else?
<LaserJock> edubuntu.karmic exits, it just doesn't have a dvd seed in it
<slangasek> (if there's cdimage work to be done yet to get it working correctly, we may run out of time for including it in the alpha; but it doesn't sound like you're changing things that will disrupt other images)
<LaserJock> so I *think*, worst case scenario, I screw up the seed and the Edubuntu DVD build is crap
<slangasek> right
<LaserJock> the cdimage work is already done
<slangasek> I think you should definitely go for it then
<LaserJock> ok
<LaserJock> let me know though if for some unforeseeable reason it causes a problem
<slangasek> if you need to make changes to the *ubuntu* seed pod, we should discuss specifics first
<slangasek> but if you're only changing your own, go for it
<LaserJock> yeah, only edubuntu.karmic
<slangasek> smoser: thanks for the comment there - it seems like this is something we probably want to include in the Tech Overview as errata, yes?
<smoser> absolutely
<smoser> zul, http://iso.qa.ubuntu.com/qatracker/build//all
<smoser> slangasek, so why does that say 1(2)
<slangasek> smoser: there are two tests for the image, we have test results for one of them
<slangasek> (I guess you mean "1/2" rather than "1(2)", right?)
<smoser> ah. ok. i was thinking that was 1 of 2 failed
<smoser> y
<slangasek> failures are put in parens afterwards if any
<zul> The requested instance type's architecture (i386) does not match the architecture in the manifest for ari-8e9bb3fa (x86_64)
<slangasek> zul: what ami is that?  That's not one of the ones posted to the tracker for alpha5
<zul> slangasek: its the eu one smoser is looking at it
<slangasek> zul: ari-8e9bb3fa is not the eu one smoser gave me to post to the tracker
<smoser> slangasek, zul's pasted the ari
<smoser> but the ami needs to be 'fixeed'. i must have published it wrong
<smoser> i'll fix that
<slangasek> ah
<TheMuso> s it just me, or is grub not responding to an escape key press?
<cjwatson> hold shfit
<cjwatson> shift
<TheMuso> oh ok
<cjwatson> and see https://wiki.ubuntu.com/DesktopExperienceTeam/KarmicBootExperienceDesignSpec#Bootloader
<superm1> slangasek, unfortunately will need a re-roll after mythtv publishes again.  there was a problem with a hardcoded filename in a postinst somewhere
<slangasek> superm1: so we're looking for -0ubuntu3?
<superm1> slangasek, yeah. just uploaded it a few minutes ago
<slangasek> superm1: ok, queued up
<superm1> thanks
<dave-ubuntu1> anyone home 0_o?
<LaserJock> I'm at home, not sure about other people
<smoser> slangasek, ami-846249f0
<dave-ubuntu1> LaserJock, can you help me set my /usr/share/initramfs-tools/scripts/local-top/cryptroot. file
<dave-ubuntu1> or point me in the right direction.
<slangasek> smoser: which one does that replace?
<dave-ubuntu1> the people in #ubuntu have no clue when it comes to more advanced problems..... my system wont boot
<smoser> eu-i386
<dave-ubuntu1> by the way why is sun java jre 1.0.14 the latest in the repos?
<slangasek> smoser, zul: published to the tracker
<dave-ubuntu1> 1.6.0.16 is out
<TheMuso> slangasek: Hrm I think studio alphas are a bust, due to some weird behavior with the RT kernel. Unless I can find a fix soonish, I'm going to have to say we'll have to pass this time around.
<slangasek> TheMuso: ok; can you please mark the test as failed in the tracker?
<TheMuso> slangasek: sure
 * TheMuso tries i386 as well to see if both arches are affected.
<foxbuntu> mathiaz, ping
<mathiaz> foxbuntu: hi
<foxbuntu> mathiaz, hello, I was wondering if you knew about the mysql-server-5.1 issue yet?
<foxbuntu> ...more specificly that it doesnt install/upgrade from 5.0 properly
<mathiaz> foxbuntu: I know of a couple of mysql-server-5.1 issue
<mathiaz> foxbuntu: under which circumstances? what is the error message?
<mathiaz> foxbuntu: is there a bug?
<foxbuntu> mathiaz, not yet..I wanted to get your thoughts on it and then if its indeed a bug I will gladly file it for you
<foxbuntu> mathiaz, let me get logs for you
<foxbuntu> mathiaz, http://mythbuntu.pastebin.com/m7e507c83
<foxbuntu> mathiaz, this is what I am seeing
<mathiaz> foxbuntu: how are you upgrading the system? apt-get dist-upgrade?
<foxbuntu> yes
<mathiaz> foxbuntu: bug 413789
<ubottu> Launchpad bug 413789 in mysql-dfsg-5.1 "mysql-server has been kept back with dist-upgrading" [High,Confirmed] https://launchpad.net/bugs/413789
<foxbuntu> mathiaz, ah...looks like it
<foxbuntu> mathiaz, your the man :)
<foxbuntu> right on top of it.
<foxbuntu> thats all I wanted :)
<dholbach> good morning
<pitti> Good morning
<lifeless> pitti ping
<lifeless> pitti: bryce: just offhand, would you happen to remember doing a sync-and-discard of our xlib patches ?
<bryce> lifeless, xlib?  not offhand
<pitti> hey lifeless
<tseliot> hey bryce
<bryce> heya tseliot
<lifeless> hi pitti :)
<lifeless> for some reason my dreaded 'not supported by xlib' locale errors are back; I'm investigating.
<lifeless> the patch is still there and in the series, but something's not right.
<pitti> errare linuxum est?
<lifeless> that reminds me, vocab practice time ;)
<slangasek> superm1: the mythbuntu respin did get posted; not sure who's going to be testing those?
<davmor2> slangasek: I'd say I would but I'm a bit busy with all the others :)
 * slangasek nods - well, it'll be some hours before superm1 is around, we'll see what happens
<d3xter> hey guys
<slytherin> Now that udev/devicekit handles storage devices, should hal be uninstalled?
<d3xter> is there any documentation on how to use notify-osd to display messages?
<slangasek> slytherin: it should be marked as a candidate for autoremoval for you when the time comes; in the meantime I wouldn't second guess it :)
<ubuntu> hello
<ubuntu> sorry to ask this here but no one seems to know anything in the regular channel. i'm getting this error on installing xubuntu 9.04 amd64: "Executing 'grub-install (hd0)' failed. This is a fatal error"
<slytherin> slangasek: I am having some problem with the DVD drive getting recognized. I was wondering if hal-storage is interfering with udev.
<ubuntu> at 94% done
<slangasek> slytherin: well you can try removing it for debugging to see if it makes a difference; either way it warrants a bug report
<ubuntu> the md5sum of the cd checks out
<cjwatson> ubuntu: please change your nick to something less generic. That's also a rather generic error message unfortunately; there should be more information in /var/log/syslog or possibly /var/log/installer/debug
<d3xter> is there any documentation on how to use notify-osd to display messages?
<slytherin> slangasek: A bug is already open. I have added info that keybuk asked.
<lg> cjwatson, snippet from /var/log/syslog: http://codepad.org/hkrCzwza
<tgpraveen> d3xter: lots. seee
<lg> cjwatson, similar errors in /var/log/installer/debug
<tgpraveen> .. search google for notify osd development fuideline wiki or something
<tgpraveen> *guideline
<d3xter> tgpraveen: ok, thx
<lg> cjwatson, ok i'll try with karmic then. can you point me to the release you'd like me to try?
<cjwatson> we're not putting much more effort into GRUB Legacy (as in 9.04), but if GRUB 2 still gets it wrong then we'll want to debug that
 * slangasek blinks
<slangasek> "gnome-terminal wants to install a font\n An additional font is required to view this document correctly."
<cjwatson> lg: you might as well go for http://cdimage.ubuntu.com/xubuntu/daily-live/current/, which is very close to what we'll shortly be releasing as Alpha 5
<lg> cjwatson, will do
<slangasek> no thanks, I'm ok with not being able to read the spam
<cjwatson> lg: thanks a lot
<yuanyelele>  Hi, Anybody know where is gsize defined in glib-2.*?
<yuanyelele>  it is referenced some where but I can not find the definition
<lg> yuanyelele, http://library.gnome.org/devel/glib/unstable/glib-Basic-Types.html#gsize
<lg> for glib related questions you may want to try irc.gnome.org/#glib or #gtk
<yuanyelele> well , I cannot find this line "typedef unsigned long gsize;" in any file..
<lg> ah
<yuanyelele> sorry but there are few people in those channels....
<lg> i dont have the headers on hand but.. have you tried to cd into /usr/include and then do a grep -ri "typedef unsigned long gsize" ?
<yuanyelele> yes, it's in glib-1.2, but not in glib-2.0
<cjwatson> it's in /usr/lib/glib-2.0/include/glibconfig.h
<yuanyelele> Oh thank you!
<lg> what an odd spot for the headers
<yuanyelele> The point is why online api does not cite this file?
<Hobbsee> uit
<lg> hmm
<lg> how will i be able to burn a disc from a box with 1 cd drive (while running the live cd)?
<cjwatson> lg: that may be a challenge
<tgpraveen> d3xter: https://wiki.ubuntu.com/NotificationDevelopmentGuidelines
<cjwatson> yuanyelele: the existence of that file isn't part of the advertised API, I assume; what the API documentation says is that if you include <glib.h> then you get gsize
<cjwatson> lg: odd spot> IIRC, it's the architecture-dependent bit of the headers
<lg> ah yes that would explain it
<yuanyelele> Thank you~~
<lg> arg, cant unmount cdrom, says its busy
<lg> ok, got it burnt somehow. gonna try installing. will be back
<d3xter> tgpraveen: thx, i've found this already
<lg> hello
<lg> on another box now. currently installing karmic on the other.
<lg> btw, i like the encryption option in the installer
<pitti> ogra: do you happen to know about a good guide how to setup cross compiling for ARM?
<pitti> ogra: (I already know https://wiki.ubuntu.com/ARM/BuildEABIChroot, that's an excellent thing)
<ogra> pitti, what do you want to cross complie ?
<pitti> ogra: myself nothing, but a friend of a friend wants to do that (he'll give me a call soon)
<ogra> if its a kernel, amitk's blog is great, for all other stuff i'd use a chroot or qemu, else you get into dependency hell
<jjardon> pitti, hal is not more a hard dependency in gnome-power-manager, see http://bugzilla.gnome.org/show_bug.cgi?id=593933
<ubottu> Gnome bug 593933 in general "Get rid of HAL" [Normal,Resolved: fixed]
<pitti> ogra: oh, https://wiki.ubuntu.com/Toolchain/Crosscompilers/ARMEABIToolchain looks promising, too, I'll send this to him as well
<pitti> jjardon: right, I know, but still needed for brightness support on some hardware
<jjardon> pitti, si, the problem is in graphics drivers?
<jjardon> s/si/so
<ogra> pitti, well, you can also use a prebuild toolchain from codesourcery ... but if you do more than kernels it gets hairy
<ogra> since you need to build every piece of the build deps
<slangasek> pitti: step 1) implement multiarch! :)
<pitti> jjardon: yes, and kernel; e. g. many nvidia cards need smartdimmer, and the kernel doesn't provide a standard API for those, so userspace has to hack around
<ogra> slangasek, qemu-static-$arch FTW :) use chroots ;)
<lg> pitti, i've done some cross compiling in the openembedded environment. it seems like it was designed to 'take care of the deps' for you
<jjardon> nvidia closed or open source drivers?
<slangasek> ogra: pff, chroots
<ogra> slangasek, i dont see multiarch->arm happening soon :)
<ogra> or multiarch ppc
<pitti> ogra: right, I think a qemu-arm-static chroot is pretty rad
<lg> cjwatson, got an error installing the latest karmic
<slangasek> ogra: um, it will happen the same time as the rest of multiarch
<ogra> pitti, yeah, sadly still has issues ... and doesnt really help complier speed ...
<slangasek> (which is not in karmic, unfortunately
<slangasek> )
<pitti> jjardon: I don't actually think it matters
<lg> cjwatson, "An error occurred while installing packages: E:Sub-process dpkg returned an error code (1)" etc.
<cjwatson> lg: doesn't sound grub-related; can I see the full logs?
<lg> cjwatson, this was at ~119%
<ogra> slangasek, hmm, how would that work without translation layer if your CPU syscalls differ as much as between x86 and armel
<pitti> jjardon: thanks for your upstream patch, though; so if we really need some day, we could disable support for it
<lg> cjwatson, sure
<cjwatson> lg: *cough* yeah, the progress percentages are apparently a bit broken right now
<cjwatson> ogra: binfmt_misc plus qemu?
<cjwatson> that's the standard handwavy answer for this anyway ...
<ogra> cjwatson, well, so what i do with qemu-arm-static already then
<lg> cjwatson, got the same error again at 126%, but it appeared to have successfully done grub-install
<slangasek> ogra: no, because you don't have to have a full chroot and run all the executables under emulation
<slangasek> so you get about a mumble percent speed-up from being able to run a bunch of stuff natively
<ogra> slangasek, yeah, i know, thats what qemu-arm-static already does ... but it *additionally* ships a wrapper to debootstrap that copies the static binary into a chroot if you build one
<ogra> it registers with binfmt_misc and all that but for a native build env its better to have a clean chroot
<ogra> which is why i added the debootstrrap wrapper script to the package as well
<ogra> -r
<lg> cjwatson, at the end it gave 'installation complete' and now its rebooting. can i still get at the logs?
<cjwatson> lg: they should be in /var/log/installer/ after installation
<lg> ok
<cjwatson> does anyone know where the "Loading, please wait" message comes from while grub is booting the kernel? I'd love to get rid of it, but for the life of me I can't actually find it anyway
<cjwatson> anywhere
<ogra> cjwatson, isnt that initramfs ?
<slangasek> cjwatson: grub 1 or 2?
<cjwatson> slangasek: 2
<Keybuk> cjwatson: top of initramfs
<ogra> /usr/share/initramfs-tools/init
<cjwatson> aha, good call
<Keybuk> wing-commander scott% grep -n Loading /usr/share/initramfs-tools/init
<Keybuk> 3:echo "Loading, please wait..."
<cjwatson> didn't even think to look there
<cjwatson> shall we just have that check the quiet flag?
<lg> cjwatson, on boot  the checkinig root file system failed. superblock last mount time is in the future.... unexpected inconsistency: run fsck manually, root fs is mounted in read-only mode... mantenance shell
<ogra> btw, while i have all people that might be intrested in that here, how about modularizing casper a bit ?
<cjwatson> lg: right, we know about that one - run fsck manually as it directs (you'll need to tell it the device to use), then exit the shell and let it reboot
<ogra> currently all casper-bottom scripts contain all hacks for all falvours we have
<lg> ok
<ogra> *flavours
<Keybuk> ogra: I'd be interested in making casper work with dracut ;)
<ogra> which means a lot of unneeded filesystem acesses on already slow media
<cjwatson> I confess to not really being interested
<ogra> i would like to have a casper-ubuntu, casper-xubuntu etc setup that contains the flavour specific scripts
<ogra> and only dumps in place whats really needed for a live flavour
<ogra> i see 2min boots on armel and see a lot of filesystem accesses i dont really need
<ogra> (2min for the livefs)
<Keybuk> ogra: sounds like a UDS-L spec to me
<ogra> beyond that casper carries a huge amount of old cruft that should really see a cleanup
<ogra> Keybuk, yep, that was my idea
<Keybuk> I'll bring the Proton Pack
<slangasek> Keybuk: do you have some time when you could explain /lib/udev/{pci,usb}-db to me?
<ogra> heh
<ogra> another thing i'd love to do would be to decouple the live squashfs from /lib/modules
<Keybuk> slangasek: don't they just parse pci.ids and usb.ids ?
<lg> cjwatson, on reboot, the session icon is not available :/
<slangasek> Keybuk: yes - why in God's name are they doing this?
<cjwatson> lg: session icon?
<slangasek> Keybuk: i.e., why is it udev's job to import a text database into its environment for use by third-party programs?
<Keybuk> slangasek: to generate comments
<ogra> splitting it in two squashfs mounted stacked ... so we only need one generic file plus one for the modules dir
<lg> cjwatson, on the login screen.
<lg> cjwatson, but i guess this is not the final product yet
<cjwatson> lg: sorry, I'm missing something, what session icon were you expecting?
<lg> cjwatson, well i see a red x in front of the "session:" label so i figure the icon link is bad
<Keybuk> slangasek: basically HAL replacement stuff really
<cjwatson> lg: ah - well, I can't offer help with desktop-level issues, my main interest is that it managed to boot, which it does seem to have done :)
<slangasek> Keybuk: oh?  comments where?  (the reason I care about this is because udev is violating the FHS by assuming /usr is available when it runs this stuff, and I'm trying to figure out how serious it is)
<cjwatson> lg: best just file a bug about that sort of thing
<Keybuk> slangasek: various places
<Keybuk> slangasek: aren't those files in /var/lib/misc? :)
<ogra> cjwatson, btw, whats the status of usplash wrt live images ? i guess we'll keep it there ?
<lg> cjwatson, you want /var/log/installer/syslog?
<Keybuk> they seem to move back and forth between /usr and /var depending on which way the wind is blowing
<slangasek> Keybuk: meh, /var is also allowed to be a separate partition, so it's still an FHS violation
<slangasek> Keybuk: also, for further enjoyment, see strings /lib/udev/pci-db |grep ids
<slangasek> I'm pretty sure that's not the PCI id db
<cjwatson> ogra: I don't know
<cjwatson> lg: yeah
<cjwatson> lg: BTW, anything involving /var/log/installer/syslog is a separate bug from that missing session icon ...
<Keybuk> but you're right that udev shouldn't be accessing files in either of those places
<Keybuk> sure iz buggy
<lg> cjwatson, yes i see. i just thought i would mention it :P
<cjwatson> that's fine
<cjwatson> ogra: live images aren't really a target for the boot performance work, to the best of my knowledge; I don't know about boot experience
<cjwatson> but since the latter kind of depends on the former ...
<lg> cjwatson, http://pastebin.com/f2b7b0677
<ogra> yeah
<slangasek> Keybuk: well, I don't care if udev accesses them, as long as nothing else further up /relies/ on udev having been able to access them ;)  so I'm wondering if it's just cosmetic, or if we need to move these databases to /lib (blech), or if I can persuade someone that this architecture is fubar and things that want text strings should bloody well fetch them elsewhere instead of expecting udev to have it
<Keybuk> slangasek: looks like it's all HALsectomy stuff
<ogra> i just want to know if i need to special case armel somehow ... we now have usplash working
<ogra> and the boot in live as well as instealled systems is slow enough to validate keeping usplash all over the place
<cjwatson> lg: yecch, openoffice.org bug, no idea what that is
<jjardon> pitti, Do you know the video drivers that still not support XBACKLIGHT? maybe we can file bugs for this
<cjwatson> lg: can you please report a bug on openoffice.org, attaching that syslog and pointing to the bit in it where openoffice.org-filter-binfilter fails?
<sgallagh> mathiaz: ping
<cjwatson> lg: oh, wait, there might already be one
<pitti> jjardon: not exactly, but I guess everything except intel and perhaps nouveau
<lg> cjwatson, i got about 3 other errors during the install as well
<pitti> jjardon: Richard would know better, I don't really know this I'm afraid
<lg> cjwatson, oh hmm, i guess they were all from openoffice
<cjwatson> lg: there are a couple of *similar* existing bugs but they aren't quite the same; I think it would be best to report a fresh one
<lg> cjwatson, ok sure
<cjwatson> bug 423588, bug 423249
<ubottu> Launchpad bug 423588 in openoffice.org "package openoffice.org-filter-binfilter 1:3.1.1~rc1-1ubuntu1 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/423588
<ubottu> Launchpad bug 423249 in openoffice.org "package openoffice.org-filter-binfilter 1:3.1.1~rc1-1ubuntu1 failed to install/upgrade: å­è¿ç¨ æ°ç pre-installation èæ¬ è¿åäºéè¯¯å· 1" [Undecided,New] https://launchpad.net/bugs/423249
<jjardon> pitti, ok, I'll take a look. Richard, the g-p-m devel?
<lg> cjwatson, lets see if i can remember my launchpad credentials
<pitti> jjardon: right
<cjwatson> lg: all your dpkg errors were from the installer repeatedly trying to hammer openoffice.org-filter-binfilter into place and failing, at least
<slangasek> Keybuk: ok, so you haven't seen any discussions about this stuff specifically?  any idea where I need to look to chase this up?  (Md said I should post to linux-hotplug, but I'm hoping to get some context first)
<jjardon> pitti, great, I'll ast him then, thank you!
<Keybuk> as in, udev has to have it, because the things further up might not have permission to look it up themselves
<Keybuk> also looks like udev tries to use them to decide things about sound cards
<Keybuk> which is obviously not going to work when /usr or /var are separate
<cjwatson> Keybuk: does http://paste.ubuntu.com/264016/ look potentially OK to you, for the clock problems?
<cjwatson> still need to test that
<slangasek> Keybuk: I don't follow... surely udev could give the further-up-bits the ID instead of the text string, and the file to do their own lookups should be world-readable?
<slangasek> (a root-only pci.ids seems like an uninteresting use case)
<slangasek> /lib/udev/rules.d/78-sound-card.rules> meh, lovely
<Keybuk> slangasek: no, I had to look it up when you mentioned it
<Keybuk> so linux-hotplug would be a good place to start
<Keybuk> slangasek: yes, though oddly udev doesn't do that because the id is in the sysfs tree ;)
<Keybuk> I think it's more than udev matches on this stuff itself
<Keybuk> cf. sound cards
<Keybuk> pitti might know a bit more about this stuff since it probably touches ACLs or DeviceKit
<Keybuk> but it not, linux-hotplig
<Keybuk> cjwatson: that looks right
<Keybuk> cjwatson: though maybe UTC=--localtime in the other case
<Keybuk> cjwatson: since whether hwclock defaults to localtime or utc depends largely on the time of day ;)
<slangasek> pitti: ^^ hi, what can you tell me about this udev madness in connection with HALsectomy? :)
<pitti> slangasek: just reading scrollback
<slangasek> ok :)
<cjwatson> Keybuk: mm, right
<pitti> slangasek: hm, what was the original question?
<cjwatson> Keybuk: (literally, probably!)
<slangasek> pitti: why is udev upstream doing mad things that violate the FHS?
<slangasek> :)
<pitti> slangasek: do you expect a technical answer to that? :-)
<slangasek> pitti: /lib/udev/{usb,pci}-db look in /usr (or /var) for databases and suck that information into their environment - that's an FHS violation, and it needs fixing
<pitti> slangasek: what is it, requiring pci.ids and usb.ids from /usr to work?
<slangasek> yes
<pitti> ah
<slangasek> (separately, our build of pci-db is amusingly broken, and only looks at the usb database)
<pitti> I wouldn't mind having them in /lib
<cjwatson> (I can think of at least one program in the archive which is (a) not explicitly a calendaring application and (b) whose behaviour actually does depend on the phase of the moon)
<pitti> not that it matters much, I suppose; did anyone actually try running ubuntu with a separate /usr?
<Laney> nethack?
<pitti> or, rather, a separate /var
<cjwatson> Laney: that was the one I had in mind, yes :)
<lg> cjwatson, isnt that 423588 the same bug?
<slangasek> pitti: er, I have a separate /usr here.  *both* are supported configurations under the FHS, and cjwatson just did extensive work in jaunty to support split /usr
<cjwatson> lg: that's a preinst failure, but your failure's in the postinst
<Keybuk> cjwatson: I'd probably add --noadjfile to match hwclock.sh stop too
<Keybuk> pitti: yes
<Keybuk> pitti: it's part of my standard test set due to /var/run and /var/lock
<pitti> slangasek: however, even if /usr isn't available on early boot, I understood that a later udevtrigger should coldplug everything again, and thus get the DB populated
<Keybuk> pitti: we don't *do* a later udevtrigger
<lg> cjwatson, ah right, gotcha. filing report now
<cjwatson> lg: so it's technically slightly different although the cause may be the same; I don't know enough about OOo to tell
<pitti> Keybuk: ah, I thought that was kay's explanation
<cjwatson> Keybuk: right
<pitti> anyway, I think we have a bug for that
<slangasek> pitti: nope, even if there was a later udevtrigger, it would happen before !root filesystems were mounted
<pitti> let me look
<Keybuk> pitti: I'm not adding 5s (average udevtrigger time) to the boot just to populate the udev db with silly strings from pci.ids ;)
 * slangasek grins
<cjwatson> Keybuk: though /etc/adjtime written in d-i won't be preserved across reboot anyway
<Keybuk> cjwatson: you right it in the target
<Keybuk> cjwatson: write even
<cjwatson> good point
 * Keybuk will bbiab
<pitti> Keybuk: ah, I think that's why I originally filed bug 372241
<pitti> slangasek: ^
<ubottu> Launchpad bug 372241 in udev-extras "udev-db needs {pci,usb}.ids early" [Undecided,Invalid] https://launchpad.net/bugs/372241
<pitti> time to reopen then?
<slangasek> pitti: sounds like it
<pitti> I reopened it
<pitti> and reassigned to udev
<evand> cjwatson: is there a trick to getting into the grub menu when using kvm SDL?  Neither shift nor escape is working for me.
<pitti> uh, where did Keybuk go
<pitti> slangasek: so, since not even /lib will help us, it seems we should copy them into the initramfs?
<cjwatson> evand: hmm, I'm sure it *did* work
<slangasek> pitti: meh, that appeals to me even less than copying it to /lib
<slangasek> pitti: I still think the architecture is wrong
<pitti> slangasek: but we don't have /lib during initramfs?
<slangasek> pitti: correct
<pitti> slangasek: so what is the actual problem that we have with this?
<slangasek> but IMHO, udev shouldn't be in the business of translating PCI/USB IDs to strings for the benefit of random other parts of the stack
<pitti> seems that we are just potentially missing some ID_ strings?
<pitti> they aren't guaranteed to be available at all
<slangasek> pitti: Keybuk noted that /lib/udev/rules.d/78-sound-card.rules behaves differently as a result of some of those strings
<pitti> if a rule needs them, it needs to call usb_id itself anyway
<slangasek> well, yes, but some of those rules are going to be triggered before the filesystem is there
<cjwatson> there's a comment above those rules as it is saying that they're ugly. maybe now is the time to redesign them
<pitti> slangasek: hm, it would seem more robust to me to change that to use IDs, not strings?
<slangasek> pitti: I agree - but that's not done yet, and I don't know what else upstream was expecting to use this stuff for
<slangasek> pitti: hence, hoping your halsectomy work provided insight
<pitti> so I guess this is a question what we actually expect from udev
<cjwatson> evand: that's a bug, sorry, I'm not sure how to address it immediately
<pitti> if we want reliable ID_* {usb,pci}_id strings, we need to copy the maps into initramfs
<evand> cjwatson: no worries, I can work around it with a live CD
<pitti> if we don't want to guarantee this, we need to fix the udev rules
<slangasek> pitti: oh, heh - also, the rules that use {usb,pci}-db aren't in the initramfs either
<pitti> or, as a compromise, call udevtrigger later on
<slangasek> so those rules only run after we're on the rootfs
<pitti> ah
<pitti> but then the devides are already there
<pitti> and the rules won't be triggered at all
<pitti> would it help to add sth. like udevadm trigger --subsystem=audio to the alsa init script then?
<pitti> bbiab, pizza is ready
<lg> cjwatson, #423673
<slangasek> pitti: I don't remember what it is now, but I think there's another interface, /not/ udevadm trigger, that tells udev to run the new rules
<lg> bug 423673
<ubottu> Launchpad bug 423673 in openoffice.org "openoffice.org-filter-binfilter: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/423673
<lg> cjwatson, there was also a crash of some sound daemon after booting up
<slangasek> pitti: anyway - bug is open now, we can figure it out from here; back to alpha5 with me
<lg> cjwatson, xfce volume daemon closed unexpectedly
<lg> cjwatson, i'm going to get some sleep. i'll idle for a while so feel free to msg me if you need to
<john280z> Running X11, my kernel is 2.6.31-5   how to force upgrade to 2.6.31-9?
<cjwatson> lg: ok, just for the record, anything after grub booting successfully I'm going to suggest that you file bugs :)
<cjwatson> lg: I'm not an XFCE developer or anything
<lg> ah okk
<lg> well then thanks for your help in getting grub booting successfully :]
<hdon> maybe this is a weird place to ask, but how can i get sort(1) to order things like strcmp() does? by default it seems to ignore underscores
<ion> LC_ALL=C sort perhaps
<hdon> i tried -g (--general-numeric-sort) and -n (--numeric-sort) but neither seems to be what i want (and their man page doc strings are a little ambiguous)
<hdon> ion: i'll try
<hdon> ion: that worked, thanks :)
<slangasek> (or LC_COLLATE=C, more specifically)
<hdon> slangasek: also correct :)
<ion> LC_ALL=C is a generic âmake locales not affect this programâ spell. For sort, the LC_COLLATE part is relevant, but for something else, you might want it to print strings in English. Easier to do LC_ALL=C sort, LC_ALL=C the-other-program instead of e.g. LC_COLLATE=C sort, LC_MESSAGES=C the-other-program. YMMV, of course. :-)
<ion> I wonder if LC_ALL=C overrides the LANGUAGES GNU extension?
<slangasek> ion: locale(7)
<ion> Thanks
<hdon> ion: no worries. we generate a symbol table using the C preprocessor to define members of a struct array. one of those steps is sort(1), and it bit me because bsearch() depended on that table being sorted using the C locale ;)
<cjwatson> I just put LC_COLLATE=C in my shell startup files
<cjwatson> though of course I do have to remember about that if I'm writing scripts for other people
<hdon> lol, "bsearch() depended on C locale"
 * hdon sighs
<superm1> slangasek, yeah i saw before i headed to bed, i gave it a quick look and it's looking better.  i'll have a detailed report up on the  tracker later this morning, and hopefully some other guys will have a look later today too
<slangasek> superm1: ok
 * cjwatson is up to five outstanding patches for grub2 and a sixth on its way. hurry up bzr import ...
<seb128> jdstrand, you said that this apparmor profile thing should be easy and not create issues? ;-)
<seb128> jdstrand, couldn't we just allow any /usr/bin binary?
<seb128> it seems suboptimal to have to list every email client, web browser, etc
<slangasek> seb128: it's not really a sandbox then if it's allowed to execute any binary in the path
<cr3> pitti: hi there, do you happen to know of apport symptoms other than "storage" which I could look at?
<seb128> slangasek, well if somebody manage to change /usr/bin you are screwed anyway no?
<pitti> cr3: not right now, sorry; bryce is currently preparing one for X, and the totem package hook has some symptom-like Q&A game for sound
<slangasek> seb128: er, the point is that there are likely to be things in /usr/bin that an attacker could use to achieve arbitrary code execution
<seb128> slangasek, I don't like much having to play catching up with any email client users might be running
<cr3> pitti: ah, so I should definately implement ui_question_something
<seb128> or any web browser they can use
<cr3> pitti: I've already improved apport integration in checkbox last night by providing more details in the reported bug about the test that failed as well as tagging the report accordingly
<cr3> pitti: so symptoms will be my next target for integration
<slangasek> seb128: that's a much easier proposition than trying to pick off all the programs in /usr/bin that it's dangerous to run
<seb128> slangasek, and the issue is trickier for print preview since the command can be set using an environment variable
<seb128> slangasek, ie we can't known in advance if users are going to tweak that
<pitti> cr3: I guess, once they are implemented, checkbox could just call them to figure out why a test is failing?
<seb128> slangasek, well clicking on a url in a pdf is no much different from clicking on an im client, web browser, irc client, etc
<slangasek> seb128: hum, sounds like something of a design flaw in the print preview to me; but I don't know enough about this to really comment intelligently
<cr3> pitti: perhaps, the only problem I can't seem to solve right now is that I would like to pick a symptom based on the current test context. so, if the user was testing audio, I would find it unfortunate to present storage related questions
<seb128> slangasek, are we going to try to lock every desktop application this way or is there a reason we consider evince as weaker
<pitti> cr3: right, that's what I meant; you should then call "ubuntu-bug sound" directly, not have ubuntu-bug ask the user for a symptom
<slangasek> seb128: ultimately, yes, I think the security team wants full apparmor profiles for all the desktop apps :)
<ogra> bah
<seb128> slangasek, ideally we need a better way that listing all email clients in every profile then
<slangasek> seb128: but as for evince, the security team probably looked at poppler's code ;)
<ogra> with the latest apparmor update my usplash always times out on armel
<ogra> it slows down booting massively here
<slangasek> seb128: sure, apparmor has includes (abstractions)
<seb128> slangasek, ok, good, I will discuss that with jdstrand then ;-)
<seb128> I would prefer to have an include @email_clients in evince
<seb128> and this list not in the application but somewhere easier to update
<slangasek> seb128: right - /etc/apparmor.d/abstractions/evince itself is already an abstraction, it just needs to be broken down more with more bits kicked over for apparmor to manage centrally
<cr3> pitti: where in the code do you map the name "sound" to the proper package(s)?
<slangasek> just like /etc/apparmor.d/abstractions/gnome
<slangasek> seb128: btw, so far I've found three programs in my /usr/bin that can be used to run arbitrary code, just by glancing at the list ;)
<pitti> cr3: the symptom script has to figure that out
<pitti> cr3: just like /usr/share/apport/symptoms/storage.py has to figure out whether it's linux, udev, devkit-disks, or gvfs
<seb128> slangasek, urg, I don't discuss apparmor to not be a good thing, it's just trickier than expected to get that profile right there
<slangasek> right, understood
<cjwatson> slangasek: programs> awk perl python?
<slangasek> cjwatson: strace ltrace ksu
<slangasek> setarch
<slangasek> :)
<cjwatson> man
<cjwatson> indeed probably anything with a pager
<cjwatson> env
<cr3> pitti: I thought that if I passed "sound" to ubuntu-bug, it would look for the corresponding file under /usr/share/apport/symptoms but there's no such file. so, how does apport map a name such as "sound" to a package?
<pitti> cr3: it doesn't; someone needs to write a sound symptom script first
<cr3> pitti: heh, thanks for the clarification, at least my understanding seemed to be alright :)
<pitti> cr3: it's not that magic, sorry :/
<cr3> pitti: I'll try to get komputes to contribute such a script, he has a passion for audio
<pitti> nice
<jdstrand> seb128: hi! well, I didn't think the apparmor stuff was too difficult for you, I've fixed all but the last dh issue ;)
<jdstrand> seb128: but seriously, I know what you are getting at
<seb128> jdstrand, oh, it's not "difficult", I just have the feeling we will play catching up for ever
<jdstrand> seb128: slangasek pretty much represented the security team's position on the matter
<seb128> jdstrand, there is always a new email client, etc
<jdstrand> seb128: evince was targetted due to the massive CVE counts in poppler (and xpdf)
<jdstrand> seb128: that is the nature of apparmor profiling I'm afraid
<seb128> jdstrand, I'm wondering if it wouldn't be easier to maintain those list out of evince
<seb128> would avoid to rebuild the software each time we want to tweak the profile
<jdstrand> seb128: sure we can, and probably will once somethng other than evince is using it
<seb128> would avoid to rebuild the software each time we want to tweak the profile, especially after freezes
<jdstrand> seb128: well, we have to rebuild *something* each time
<seb128> well, rebuilding data packages is usually no issue
<seb128> ie we can do that late
<seb128> where rebuilding code can lead the compiler changes issues, toolchain issues, etc
<jdstrand> seb128: apparmor abstractions are built in the apparmor package, which is a binary
<seb128> ok
<jdstrand> maybe we can restructure that, that is an interesting point
<jdstrand> seb128: I did plan to break out some of that into an abstraction some time, but like I said, it was the only one using it so I just put it there
<seb128> jdstrand, anyway I will look at the documentation soon so I can do the change to the profile myself for the next changes
<seb128> I just wanted to have a grasp of what you guys do first and I was on vac
<seb128> thanks for doing the first round of updates and fixing for this one
<jdstrand> seb128: sure, np. I'm glad to help in anyway I can
<jdstrand> seb128: keep in mind the following though: /usr/share/doc/evince/README.Debian
<seb128> jdstrand, the print preview command can be changed by an environment variable not sure how to address that or if we should
<seb128> jdstrand, or if we decide that whoever change that can also tweak the profile
<jdstrand> seb128: well, our take on profiling is a) it must work in the default installation and b) it should work in common and standard practice configurations
<jdstrand> this is for any apparmor profile
<jdstrand> seb128: if people start changing their system radically, we have to draw a line
<seb128> ok, fair enough
<jdstrand> seb128: for example, launching mutt as the email handler in gnome-terminal is supported
<jdstrand> (it is gnome after all)
<jdstrand> seb128: but launching mutt in an xterm or konsole is not, but I adding commented out sections in the profile that people can use if desired
<jdstrand> (due to the reduced security stance)
<seb128> ok
<jdstrand> seb128: I'm happy to add an common previewers
<seb128> jdstrand, I don't think there is any out of evince itself, they just let the option for other desktop and non linux system I think
<jdstrand> seb128: I'm not sure I fully understand. /usr/bin/evince* are confined. if an environment setting make something call them, then everything should be ok. if they honor an environment variable for calling out other stuff, then we may need to tweak the profile if it is a common configuration
<cjwatson> perhaps a long-term approach for evince would be to privilege-separate the PDF handling into a separate process that could be confined separately from the graphical interface
<cjwatson> obviously an upstream kind of thing
<jdstrand> I'd certainly be happy with that :)
<seb128> jdstrand, the print preview comes from gtk which calls evince (default choice)
<jdstrand> seb128: ah, then if the gtk option is changed, evince is not used so no problem, no?
<seb128> jdstrand, but that's a gtksetting and kde could set kpdf or something there
<seb128> jdstrand, well if you run evince under kde and do print preview it might start kpdf to do the preview
<seb128> since gtk will start whatever the setting says to start
<seb128> (I don't think kde tweak that right now though but I didn't check)
<seb128> it's probably not an issue right now
<jdstrand> seb128: we can certainly test that configuration, but using evince instead of kpdf but wanting kpdf as the previewer sounds like an uncommon configuration?
<seb128> I think we should just wait for a potential bug report to see if somebody tweak that value
<jdstrand> seb128: AA profile SRUs are typically no brainers
<seb128> ok, so let's not worry about this one
<jdstrand> seb128: honestly, I've been pretty happy with the number of bug reports. Overall, quite smoothe (I realize you probably weren't happy with the bugs that came in, but I was expecting it ;)
<jdstrand> seb128: please, let me know if I can assist with this at all. I like the idea of a separate profiles data package
<seb128> jdstrand, I'm not unhappy, I just fear that the email and web browser list turns to a catching up game
<seb128> ie epiphany-webkit is not listed there
<seb128> and I guess several other email clients users are running
<jdstrand> seb128: if you've got a list otoh, give it to me and I can add them
<seb128> jdstrand, having those email client and webbrowser lists not in the application would be nice
<jdstrand> seb128: I can move those out
<seb128> jdstrand, I think I will start doing the profile tweaks without bothering you now
<seb128> jdstrand, you can stop watching evince bugs, I will Cc you when needed
<seb128> jdstrand, that would be nice, I think it's going to be useful in other applications over time anyway
<jdstrand> seb128: did you upload ubuntu8?
<seb128> jdstrand, no, alpha freeze in effect
<seb128> jdstrand, I think I changed the target to karmic by mistake though
<seb128> you can do changes to it if you want, I will upload later today
<jdstrand> seb128: ok, let me prepare ubuntu8 and I'll upload it and apparmor with the email clients and browsers pulled out
<jdstrand> seb128: or I can ping you
<seb128> jdstrand, thanks!
<jdstrand> (whichever)
<seb128> jdstrand, feel free to upload I did the only change I wanted to do there
<jdstrand> ok, I will upload
<jdstrand> seb128: np! thanks for the feedback :)
<jdstrand> seb128: btw, once I move the email and browsers stuff out of evince, you can then reassign the bug to apparmor rather than evince, as these things come up
<jdstrand> s/the bug/the future bugs/
<seb128> jdstrand, ok, will do!
<jdstrand> (for email and browsers that is ;)
<jdstrand> seb128: fyi-- the way the evince* profiles are designed is that I created an abstraction/evince file that the profiles defined in /etc/apparmor.d/evince all share
<jdstrand> seb128: as I'm sure you've seen, the evince package ships both the /etc/apparmor.d/usr.bin.evince file and the /etc/apparmor.d/abstraction/evince file
<jdstrand> seb128: /usr/bin/evince* are all set in /etc/apparmor.d/usr.bin.evince
<jdstrand> seb128: as always, feel free to ask me or anyone on the security team if you have any questions
<jdstrand> :)
<seb128> jdstrand, right I've seen there was 2 files but I didn't try to understand the role for each one yet
<seb128> thanks for the explanations ;-)
<seb128> I will start by reading the documentation
<seb128> I will ping you back then if I still have questions
<jdstrand> sounds good
<seb128> but I expect that should be ok once I've read the wiki ;-)
<liw> hrmph, my gnome panels have moved to a different monitor again
<seb128> liw, http://bugzilla.gnome.org/show_bug.cgi?id=562944
<ubottu> Gnome bug 562944 in general "Make use of the randr 1.3 primary output" [Normal,Unconfirmed]
<jdstrand> seb128: regarding bug #423687 can you do 'apport-collect -p evince 423687'?
<ubottu> Launchpad bug 423687 in evince "apparmor breaks print preview in evince" [Undecided,New] https://launchpad.net/bugs/423687
<seb128> jdstrand, what information do you need? just curious
<jdstrand> seb128: essentially 'dmesg|grep audit'
<seb128> ok, I need to break it again
<seb128> how do I undo the aa-complain I did
<seb128> aa-enforce ?
<jdstrand> seb128: yes
<jdstrand> seb128: but it should be in kern.log too
<jdstrand> seb128: so you don't need to 'break it' again
<seb128> jdstrand,
<seb128> [20210.811220] type=1502 audit(1251982341.105:28): operation="exec" pid=25377 parent=25376 profile="/usr/bin/evince" requested_mask="::x" denied_mask="::x" fsuid=1000 ouid=0 name="/usr/bin/evince" name2="/usr/bin/evince//null-e"
<jdstrand> seb128: I think that may be from when it was in complain, not enforcing
<seb128> let me do that on the bug
<jdstrand> seb128: 'cat /var/log/kern.log | grep audit' would be good to see
<jdstrand> seb128: if you don't want it in the bug, you can put it on chinstrap or something...
<seb128> jdstrand, no issue having it on the bug, let me 30s I just finish something else
<liw> seb128, so no solution to the panel thing yet, if I understand correctly
<seb128> liw, not that I know about at least
<liw> seb128, ack, then I'll wait patiently
<mvo> hey liw - sorry that I have not answered your mail yet :(
<liw> mvo, no worries
<seb128> jdstrand, apport-collect crashes
<slangasek> superm1: should I expect mythbuntu amd64 to get testing for A5?
<seb128>     value = validated_values[param.name]
<seb128> KeyError: 'description'
<dpm> pitti: we've got an ubuntu translation meeting in a few minutes and we've got a topic I'd like to ask you a few things about. May I ping you later on when we are discussing it and ask you to shortly join us on #ubuntu-meeting to give us your view? It's about the second point here -> https://wiki.ubuntu.com/Translations/Meetings/2009-09-03 ("Disabling CLI translations for Hebrew")
<superm1> slangasek, yes
<slangasek> ok
<slangasek> superm1: any idea how soon?  I'm expecting everything else to be ready to go in the next hour or so
<superm1> slangasek, i'm looking right now since the other guys wouldnt be able to get to it until later today
<slangasek> alrighty, thanks
<seb128> jdstrand, I've added the 'cat /var/log/kern.log | grep audit' log to the bug let me know if you need something else
<jdstrand> seb128: I just reproduced it-- it is print preview from within evince, correct?
<seb128> jdstrand, right, just run evince on a pdf, go to file, print, click preview
<jdstrand> seb128: ok, easy fix. sorry I missed it. I checked print preview somewhere else which worked
<slangasek> superm1: bug #423233 seems to be private, so I have no idea what failed in your mythbuntu test :-)
<ubottu> Bug 423233 on http://launchpad.net/bugs/423233 is private
<ogra> toomanysecrets
<superm1> slangasek, volume daemon crashed, nothing too big
<superm1> i have a feeling its a duplicate of another bug, but i'll let the retracer decide
<slangasek> ok
<dholbach> Ubuntu Developer Week will start in 25 minutes in #ubuntu-classroom
<zyga> mvo: hello, are you working on app-center
<mvo> hey zyga - yes I implement it, for the design we have mpt
<zyga> I
<zyga> 78o
<zyga> sorry, kids
<mvo> haha
<mvo> np :)
<zyga> I'd like to ask you about something that has been in my mind since I read about the concept
<zyga> the major usability win of app store / itunes is that the user installs applications - not system components
<zyga> and they have a property of being _always_ installable, without any dependencies
<zyga> have mpt or you considered offering something like this on top of the current apt/dpkg infrastructure/
<zyga> this would limit the scope of actions applicable in the "default" interface
<zyga> but would reduce all difficult things (packages depending on libraries, shared data, packages conflicting, replacing one another) to zero
<zyga> I was thinking about having three pieces of data in the store
<zyga> applications
<mvo> zyga: no, that would be possible, but a major change in how to package apps. it would basicly be all lsb apps
<zyga> I don't mean to change packages
<zyga> just the frontent
<zyga> and how to present packages to users
<zyga> imagine this:
<zyga> the user maintains only one thing unless they choose otherwise by enabling true package view
<zyga> the list of applications
<mvo> oh, I see what you mean. I think this was not yet discussed, a interessting idea
<mvo> only present stuff by default that is "safe"
<zyga> to be considered "application" you must be a package with .desktop file (or something like that) and depend on some stuff that can be installed without bothering the user
<zyga> so if I want to use "k3b" I just install that
<zyga> the UI should indicate that K3b needs other "things" but the user should be informed about that more unless he really cares
<zyga> the other two concepts would be "libraries and other packages"
<zyga> and "services"
<zyga> libs and packages would only inform the user about what is truely installed that is not an application package
<zyga> the only UI the user would have is "remove the ones I don't need"
<zyga> the last stuff would be for services once we can define something like that in the system
<zyga> so if I want to install "file sharing for windows aka samba" it would go under services, but that is off the topic
<zyga> the central concept change I was thinking about is "dont manage packages"
<zyga> "manage applications"
<zyga> "show packages with -remote-junk- button"
<mvo> zyga: that sounds interessting (and actually not too hard to implement) - I think it aligns iwth the ideas that mpt has
<zyga> the problem this obviously has is how to integrate "advanced" mode without remaking synaptic
<zyga> and the deep problem of having stuff like virtual packages, conflicts etc
<mvo> yeah, once we enter the realm of "all packages" its going to be tricky
<zyga> (-common packages containig desktop files, alternatives and the rest of things that are "smart")
<mvo> I have not seen a good answer to this yet
<zyga> the only thing I can think of is to add _really_ smart UI for each particular use case (like special stuff for virtual packages, special ui for "related packages like -doc and -dev and recommends etc)
<zyga> and work with debian to simplify :)
<zyga> that's my idea anyway
<zyga> I'd love to hear what you and mpt think about it
 * zyga is looking for plastic doors to my son's car
<zyga> mvo: one more thing
<zyga> mvo: if the app store concept really takes off and gains adoption
<zyga> mvo: we could create a spec of "application" and evangelize everyone about it
<zyga> mvo: _and_ tag packages with X-whatever-is-application
<mvo> zyga: yeah, more meta-data is definitely a win
<zyga> so this can grow smarter/beyond checking for .desktop files and other hacks and being integrated properly with the package manager
<mvo> maybe debtags, I'm not sure what will win
<zyga> I'm not familiar with debtags but anything we can have at the lower layer for everyone to use
<zyga> applications have other concerns like shared system configuration, per user data, migrations, mime types, url scheme integration etc but I realize this is a one-step-at-a-time approach
<zyga> being able to "revert app to default" setting would be a huge step towards PC as consumer electronics vs "unix workstation"
<mvo> revert all apps to default? i.e. remove pkgs/settings that are not a standard ubuntu install?
<zyga> that would be interesting too but i was thinking about "revert this particular app to default state"
<zyga> for example if the user damages configuration
<zyga> or would like to revert to default state, whatever that is
<zyga> this is actually beyond packaging
<zyga> it's also about locating files that applications create that are not "user documents"
<zyga> and being able to manage them somehow
<zyga> maybe this is not something that the app store could sensibly manage but it could be important from usability point of view
<sgallagh> mathiaz: ping
<zyga> mvo: on OSX almost every app stores several files in your $HOME, something akin to xdg-dirs
<cjwatson> Keybuk: wow, yeah, bug 407428 is totally a udev bug
<ubottu> Launchpad bug 407428 in openssh "sshd zombie processes and strange behavior after karmic upgrade" [High,Confirmed] https://launchpad.net/bugs/407428
<zyga> mvo: there is an application that allows you to uninstall other application and get rid of that data at the same time
<Keybuk> cjwatson: udev bug?!
<mvo> zyga: interessting, we would have to have a way to descripe where the app installs stuff
<zyga> mvo: it's possible because many system frameworks require apps to have unique id's (reverse domain + name) and require using that to  access stuff
<Keybuk> neat
<cjwatson> Keybuk: udevd.c:worker_new() blocks a huge pile of signals
<cjwatson> and util_run_program etc. never puts them back
<Keybuk> my god did that bug go right around the entire system ;-)
<zyga> mvo: that's xdg-dirs
<zyga> mvo: (just nobody follows it yet)
<Keybuk> cjwatson: thanks, can you assign them back then :-))
<zyga> mvo: it's really simple stuff like "get preferences for app at pl.suxx.my-app"
<cjwatson> done :)
<Keybuk> cjwatson: so, I have a bug for you
<cjwatson> 15-all?
<zyga> so you have to use that id in many common APIs
<zyga> right now I don't see this becoming viable with so many frameworks but it's something I keep thinking about
 * mvo nods
<zyga> if the package data has something like xdg-dirs-name: foo
<Keybuk> cjwatson: it's a eglibc bug ;)
<Keybuk> http://pastebin.ubuntu.com/264512/
<Keybuk> (it might be a gcc bug too)
<zyga> then we can guess the app keeps a cache and preference in .cache/foo and .config/foo respectively
<zyga> and use that in the UI
<zyga> mvo: again it's not perfect but it gets much closer to being usable without changing everything :-)
<mvo> zyga: I think it needs to be encoded somewhere in the meta-data, guessing is not good enough, but yeah, its a good feature :)
<mvo> zyga: we could add it to the desktop file for now
<zyga> the xdg-dir would be encoded
<zyga> if it was encoded the app store could assume that the app follows xdg-dirs
<zyga> .desktop files are nice because they are package-agnostic and could be integrated upstream
<zyga> what is going to be the primary source of data in the app store?
<zyga> some custom format or regular apt repo?
<mvo> regular apt sources
<mvo> with additional meta-data, initially from desktop files
<zyga> I see
<mvo> hopefully later in a more generic way
<mvo> zyga: thanks for all you ideas :) I need to leave for dinner now, but you should pass them to mpt as well
<cjwatson> Keybuk: I don't think it can be an eglibc bug; the function declaration matches the standard
<Keybuk> cjwatson: well, other than the use of the intermediate typedef
<Keybuk> but I'm not sure that should make a difference
<cjwatson> I don't think it should
<Keybuk> it may well be a gcc bug
<cjwatson> it does look like one
<zyga> mvo: thanks - I'd love to talk to mpt and you more about this
<Keybuk> I'm pretty sure that a function pointer that takes void arguments should be compatible with a function pointer that takes other arguments
<cjwatson> C99 6.3.2.3 says that function pointers are implicitly converted to other function pointers
<cjwatson> in fact it's a rather more general rule than I expected
<cjwatson> let me do a bit more standards-browsing to make sure though
<Keybuk> if the standard says this gcc error is correct, then it's definitely a glibc bug
<Keybuk> because qsort explicitly suggests alphasort() as exactly the kind of function you should pass to it ;-)
<Keybuk> indeed
<Keybuk> since qsort() and alphasort() are both, I think, defined by C99
<Keybuk> and qsort says a good function is alphasort
<Keybuk> and it gives the alphasort prototype as taking dirents
<Keybuk> I think that pretty much guarantees that this can't be invalid C99 ;)
<Keybuk> unless we found a bug in C99 :p
<cjwatson> actually alphasort is mentioned nowhere in C99, and the manual page says it takes const void *
* slangasek changed the topic of #ubuntu-devel to: karmic alpha-5 released | Archive: open, FeatureFreeze | 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
<cjwatson> though glibc appears to differ, it's true
<Keybuk> cjwatson: oh, are those ones posix?
<cjwatson> yeah
<Keybuk> quick testing shows that this is not a typdef issue
<cjwatson> POSIX.1-2008 at that
<Keybuk> gcc doesn't believe that int (*)(const void *, const void *) and int (*)(const char *, const char *) are compatible
<Keybuk> let alone anything more complex
<Keybuk> err
<Keybuk> in fact
<Keybuk> const void *a;
<Keybuk> char *b;
<Keybuk> b = a;
<Keybuk> doesn't quite work
<Keybuk> oh, no, I'm a numpty - that one works
<jcole> good morning everyone
<jcole> ive got no response in #ubuntu or #ubuntu+1... can anyone here point me to the reasoning for not including 64bit flashplayer in the next ubuntu release karmic
<jcole> are there some closed source bits/drivers that depends on the 32 bit version?
<cjwatson> Keybuk: ok, I got some C standards lawyering help
<Keybuk> what do they say?
<cjwatson> Keybuk: function pointers are convertible only if each of their parameters have compatible types (6.7.5.3(15))
<cjwatson> Keybuk: contrary to my assumption, thingy * and void * are not in fact compatible types
<Keybuk> right
<Keybuk> why are thingy * and void * not compatible?
<Keybuk> isn't that the entire point of void * ?
<cjwatson> Keybuk: the reason you can assign one to the other freely is only that there is a special exemption for assignment (6.5.16.1)
<cjwatson> AFAICS anyway
<Keybuk> actually, I think that's true
<Keybuk> I have to cast function pointers if I change void *data to Something *useful
<Keybuk> which means this is a glibc bug, right? :)
<Keybuk> the prototype of alphasort() is wrong
<cjwatson> 6.7.5.1(2) says "for two pointer types to be compatible, both shall be identically qualified and both shall be pointers to compatible types"
<cjwatson> 6.3.2.2 says that there are no implicit conversions for void
<cjwatson> oh, well, it does say you can implicitly convert to void, so I'm not 100% sure
<Keybuk> heh
<cjwatson> but consensus seems to be that gcc is acting within the standard, so I'm inclined to agree that this is a glibc bug
<cjwatson> that just leaves layer 9
<Keybuk> gcc breaks glibc DEATHMATCH
<cjwatson> I wonder if the best way to do this is to get the manpages maintainer to intercede, since his manual page disagrees with glibc :-)
<Keybuk> err
<Keybuk> why?
<Keybuk> you mean the alphasort() man page maintainer?
<cjwatson> right, it's in manpages-dev
<cjwatson> and upstream for man-pages is generally doing a fair bit of bug-filing on the kernel, glibc, etc.
<Keybuk> this must be a recent glibc or eglibc change
<cjwatson> it's in glibc too
<Keybuk> though I think it's glibc, because google says F11 is having these issues too
<cjwatson> I checked git
<cjwatson> one moment and I'll git blame it
<cjwatson> git sha-1 eee6b1432794967d4272394dfed1e2b5cca4be39, http://sources.redhat.com/bugzilla/show_bug.cgi?id=9759 - apparently it was to match POSIX.1-2008
<ubottu> sourceware.org bug 9759 in libc "declarations of scandir, alphasort not POSIX compliant" [Normal,Resolved: fixed]
<cjwatson> http://www.opengroup.org/onlinepubs/9699919799/functions/scandir.html
<cjwatson> so if anything that makes it a POSIX bug ...
<cjwatson> looks like alphasort is designed for use with scandir, and qsort gets screwed
<cjwatson> scandir used to take int (*) (const void *, const void *) but now takes two const struct dirent **
<cjwatson> so in short I have absolutely no idea whose problem this is now. :-)
<jdstrand> seb128: ok, I have committed the changes to the evince tree and abstracted out all the email clients and web browsers. I then added several abstractions to apparmor and went through Ubuntu Software Center and synaptic looks for all gui and cli browsers and MUAs. I think we should be in better shape
<jdstrand> seb128: so that will support the common and even not very common situations
<cjwatson> Keybuk: looks like you get to cast or use a wrapper ...
<tkamppeter> pitti, hi
<Keybuk> cjwatson: disagree
<Keybuk> since qsort() explicitly recommends alphasort()
<Keybuk> and alphasort() explicitly states it's intended for qsort()
<Keybuk> the prototypes should be compatible
<jdstrand> seb128: and now other apparmor consumers can benefit (yea)
<cjwatson> Keybuk: where's this?
<cjwatson> the only thing I see is a SEE ALSO from qsort to alphasort, in POSIX
<Keybuk> qsort()s manpage
<cjwatson> manual pages are written post-hoc :-(
<Keybuk> NOTES
<Keybuk>        Library routines suitable for use as the compar argument include alphaâ
<Keybuk>        sort(3) and versionsort(3).  To compare C strings, the comparison funcâ
<Keybuk>        tion can call strcmp(3), as shown in the example below.
<Keybuk> so?
<Keybuk> I think it's utterly wrong for this to break
<Keybuk> this is a fairly fundamental API
<cjwatson> I agree, but it's a POSIX bug, glibc is just passing it on
<Keybuk> how is it a POSIX bug?
<Keybuk> alphasort() isn't *in* POSIX yet
<cjwatson> yes it is!
<cjwatson> I just gave you the reference
<cjwatson> http://www.opengroup.org/onlinepubs/9699919799/functions/scandir.html
<Keybuk> ah
<Keybuk> well, fix that then
<Keybuk> or patch our glibc to work around it
<cjwatson> I can see if I can raise it as a POSIX defect or something
<Keybuk> indeed
<Keybuk> I'd say that since POSIX does see also this, it's recommending it
<cjwatson> but until then it's best to leave the libc alone I think
<Keybuk> why?
<Keybuk> if I broke something fundamental in an API that was recommended widely
<Keybuk> and pretty widely used
<Keybuk> you would make me revert my breakage
<Keybuk> I don't see this is any different
<Keybuk> glibc has broken behaviour that was previously recommended
<Keybuk> glibc should be fixed now
<cjwatson> because changing alphasort's prototype will mean that it's no longer compatible with scandir; changing scandir will mean that application programmers writing code to POSIX will have to change, etc.
<cjwatson> it's hardly broken, it's just a cast
<cjwatson> we can raise it, but there is no need to panic
<Keybuk> I disagree
<Keybuk> since there's no typedef defined
<Keybuk> it's a workaround for a glibc bug
<cjwatson> a wrapper function is easy too, and perfectly traditional for comparison functions given to qsort
<Keybuk> there should be no need for a wrapper function
<Keybuk> glibc has broken its API
<Keybuk> this breakage should be reverted
<cjwatson> correct. but it's hardly something to get up in arms about.
<cjwatson> a
<Keybuk> well, it is
<Keybuk> because I'm getting build failures
<cjwatson> I agree it's a bug but I think you're overreacting
<Keybuk> and if I change the code to match *our* glibc
<Keybuk> I get build failures on older glibc
<Keybuk> because then the prototypes don't match there either
<cjwatson> that means your change is not sufficiently creative
<Keybuk> in fact
<Keybuk> this breaks jaunty vs. karmic
<cjwatson> changing this will just cause knock-on build failures elsewhere; we need to get the standard fixed
<Keybuk> we can fix glibc in the meantime
<cjwatson> anyway, it's my dinnertime.
<Keybuk> while we wait the necessary 5 years for the standard
<seb128> jdstrand, excellent, thanks
<danielgianni> hi guys, i don?t understand ubuntu event system, example, autofs cdrom automount cdrom but how I get the end of mount event?
<seb128> jdstrand, do you upload the changes or do you want me to do that?
<jdstrand> seb128: I will, I am building and testing now
<seb128> ok, good
<cjwatson> something like http://paste.ubuntu.com/264544/ should be entirely sufficient and work on both old and new
<cjwatson> err, sorry
<danielgianni> HAL seems to me is more confusing than Autofs
<cjwatson> http://paste.ubuntu.com/264547/
<cjwatson> (tested on both karmic and lenny)
<Keybuk> so would a simple 1-line patch to the glibc header file
<cjwatson> which would cause other things to fail to build. if that's your standard, then we have total deadlock; therefore I argue that is not really the most productive standard to apply
<Keybuk> it's the standard that has been in effect since glibc was introduced
<Keybuk> it's the recommended practice in the manpages
<Keybuk> glibc should not break this
<Keybuk> glibc could always bump its SONAME to indicate it's not API compatible anymore ;)
<pitti> slangasek: congrats to alpha-5!
<pitti> dpm: oops, sorry, missed your ping; sure, just ask me if you have questions
<pitti> hey tkamppeter
<pitti> tkamppeter: thanks for the hplip polkit migration!
 * pitti chalks it off at https://wiki.ubuntu.com/DesktopTeam/PolicyKitOneMigration
<tkamppeter> pitti, there a re-upload will come soon, as it FTBFS, it needs now a dependency on policykit-1.
<tkamppeter> pitti, Are both PolicyKits there now in parallel on the CDs?
<cjwatson> Keybuk: for the record, I think it would be entirely reasonable for you to respond to a reported API breakage by saying "hmm, interesting, there are some knock-on effects with just reverting that so I'll need to raise it upstream; in the meantime, here's a workaround"
<pitti> tkamppeter: yes, we are still transitioning
<tkamppeter> pitti, then it is good that I have removed the redundant HP PostScript PPDs from foomatic-db, as they are also in HPLIP.
<sbeattie> pitti: are you okay with the patch in bug 401983, or do you want something different?
<ubottu> Launchpad bug 401983 in apport "apport-cli saves reports for later with a .txt suffix, but ubuntu-bug wants saved reports to have .crash suffix" [Undecided,In progress] https://launchpad.net/bugs/401983
<pitti> sbeattie: nice timing, I was just looking at it
 * pitti is on an apport bug cleanup rave
 * jdstrand considers filing one
 * pitti phears sbeattie's telepathic skillz
<pitti> sbeattie: .apport makes sense, it's more neutral than .crash or .txt
<pitti> sbeattie: in fact, when reading the description I was about to change ubuntu-bug to accept .txt as well, but this is better
<ScottK> pitti: I managed to install bcmwl using jockey from an ISO last night, so whatever it was, I think you fixed it.
<pitti> ScottK: good to hear
<sbeattie> pitti: cool, thanks.
<tkamppeter> pitti, did our new udev rule for the USB printers make it upstream?
<pitti> tkamppeter: no, didn't get to discussing it with kay yet
<pitti> still on my todo list
<jdstrand> seb128: fyi, ubuntu8 uploaded (revno 32)
<davmor2> pitti: didn't the auto codec thing get fixed in totem?
<pitti> seb128: ^ do you happen to know?
<seb128> pitti, no, http://bugzilla.gnome.org/show_bug.cgi?id=591677
<seb128> jdstrand, thanks
<ubottu> Gnome bug 591677 in gst-plugins-base "Easy codec installation is not working" [Normal,Reopened]
<ulaas> libldb-samba4-0
<lordmetroid> Why are some packages consistently being kept back during upgrades?
<lordmetroid> Shall I do an update-manager -d now when alpha 5 has been released, to upgrade from alpha 4?
<LordMetroid> Sorry if I missed the answer, do I need to update my alpha 4 to alpha 5 using update-manager -d ?
<ScottK> LordMetroid: #ubuntu+1 is a better place for that question.
<LordMetroid> I see
<LordMetroid> What is the purpose of this channel?
<ScottK> LordMetroid: Read the topic.
<LordMetroid> Yes but what is the difference between this channel and #Ubuntu+1?
<LordMetroid> #Ubuntu+1 is support?
<ScottK> For people running the development release yes.
<ScottK> This is for doing the development.
<LordMetroid> ok, thanks
<kees> mterry: I hit the rsyslog hang again.  :(  more details in bug 423943
<ubottu> Launchpad bug 423943 in rsyslog "hanging during start" [Undecided,New] https://launchpad.net/bugs/423943
<mterry> kees, for the love of
<kees> mterry: I think I have a viable guess at the cause and a fix this time (without actually having looked at the code)
<mterry> kees, nice.  I'll look at it tomorrow
<kees> mterry: cool
<mterry> kees, (I mean, I looked at your report, I'll look at it in more depth tomorrow.  :))  thx
<kees> mterry: yup, no problemo.  it's just in my VM.  :P
<rgreening_> asac: have you seen this? http://en.opensuse.org/KDE/FirefoxIntegration (you probably have... but just in case not)
<mattfletcher> hello, i've just dist-upgraded my 9.04 install to karmic alpha and i now have two firefoxes installed. 3.5.2 and 3.0.something. what packages do i need to remove to get just the latest?
<mattfletcher> correction, i used update-manager -d, not dist-upgrade
<LordMetroid> mattfletcher, #Ubuntu+1 will probably know
<taavikko> xorg-server 2:1.6.3-1ubuntu3 brought 183_dont_reset_event_time patch, now I have it on my notification area?
<dtchen_> TheMuso: given the bug fixes in the ppa version of pulse, it's worth an FFE. also, i've updated debian/copyright.
<dtchen_> liw: thanks (also to everyone i'm omitting) for the zsync addition on cdimage
<cjwatson> ogasawara: I don't understand why you reassigned bug 423128 to kbd; I asked cr3 to send those bugs to linux instead, because the test in question is "does changing virtual terminals work?", and it's really quite unlikely that the cause of that is that the chvt binary is broken
<ubottu> Launchpad bug 423128 in kbd "kbd package" [Undecided,New] https://launchpad.net/bugs/423128
<cjwatson> ogasawara: it's much more likely that it's because the kernel's virtual terminal subsystem is broken
<cjwatson> ogasawara: I know the bugs are rubbish; checkbox is not being very helpful here :-(
<ogasawara> cjwatson: ahh, got it.  I think I'd only moved 2 bugs so far.
<cjwatson> ogasawara: TBH I suspect there isn't much usable in those bugs - somebody needs to work with Marc to get them improved
<cjwatson> dunno, maybe you guys can extract something from them
<cjwatson> if you *do* find out that it's due to a broken chvt binary then let me know and I'll take it back :-)
<TheMuso> dtchen_: Ok. I am happy to work on that if you haven't started it already.
<dtchen_> TheMuso: i have not started it; feel free :-)
<TheMuso> dtchen_: ok.
<kirkland> does anyone know which signal is being ignored with mask SigIgn: 0x0080
<cjwatson> little-endian, that's 7th bit from the bottom, kill -l says SIGBUS
<HiGuys> Hey Everyone
<HiGuys> Is this the right place to put packaging questions?
<cjwatson> err, and forget my "little-endian" term there, that's probably wilfully confusing in this case
<cjwatson> HiGuys: #ubuntu-motu is probably better for general mentoring
<HiGuys> Ok thanks
#ubuntu-devel 2009-09-04
<diwic> Hello,
<diwic> while trying to build a package with pbuilder it seems like it can't satisfy the libjack-dev dependency
<diwic> how can that be?
<RainCT_> Out of curiosity, how often are apt's Translation-X files updated?
<RainCT_> diwic: Try updating your pbuilder.
<diwic> "pbuilder update"? Tried that.
<diwic> RainCT_: pbuilder-satisfy-depends-dummy: Depends: libjack-dev which is a virtual package.
<diwic> AFAIK, libjack-dev is not a virtual package...?
<c_korn> http://packages.ubuntu.com/search?keywords=libjack-dev&searchon=names&suite=all&section=all
<c_korn> diwic: you are not running dapper by chance ? :)
<diwic> c_kom: I hope not :-) Freshly installed karmic
<diwic> c_korn: sorry I misspelled your name
<diwic> gaah...found it...forgot to enable universe
<LordMetroid> What is Ubuntu doing for so long after one has logged in to one's user?
<LordMetroid> It is annoying as hell to wait after one has logged in
<LordMetroid> Cause in the time it takes to come to the login field, you can go and take a cup of coffee
<LordMetroid> In jaunty when you logged in you got the system served to you
<LordMetroid> Now I have to wait
<billybigrigger> anyone tried vnc sessions in karmic?
<TheMuso> Do such packages as xsplash, indicator-session, and libdbusmenu require feature freeze exceptions to be updated? Yes I know Canonical works on them, but they are new upstream releases after all. (I am looking into sponsoring uploads, and want to be sure an FFE is not required before I do so.)
<ScottK> TheMuso: My understanding was they were to be treated like any other upstream.
<ScottK> Certainly that's what we're doing in Kubuntu.  For Ubuntu I don't know if it's different.
<dholbach> good morning
<superm1> TheMuso, keep in mind new upstream release != new features though
<superm1> (necessarily)
<TheMuso> superm1: I am aware of that.
<dholbach> vorian: can you please please please take a look at bug 386428?
<ubottu> Launchpad bug 386428 in xom "Please merge xom_1.2.1-1 (universe) from debian unstable" [Wishlist,In progress] https://launchpad.net/bugs/386428
<dholbach> ArneGoetje: will scim-anthy stay in main?
<dholbach> if it should go to universe, we wouldn't need a MIR
<dholbach> (for kasumi)
<dholbach> pitti: ^ do you know what the state of the discussion is there?
<dholbach> scim vs ibus?
<ArneGoetje> dholbach: stay in main
<dholbach> ok
<ArneGoetje> dholbach: we may need to switch back to scim if ibus appears to be too buggy and we cannot fix the issues in time
<dholbach> alright
<dholbach> ArneGoetje: there were a bunch of ITPs filed in Debian for new ibus plugins
<ArneGoetje> dholbach: yeah, saw them
<ArneGoetje> dholbach: but it's more important to get the current code into a good shape
<dholbach> right
<dholbach> I was just excited to see things moving so quickly in ibus land
 * nixternal hugs dholbach 
 * dholbach hugs nixternal back :)
<nixternal> good morning sir
<StevenK> ArneGoetje: In regards to the bug, if the upstream doesn't want to remove the .desktop file, we can just NoDisplay=true it
<ArneGoetje> StevenK: yeah
<StevenK> ArneGoetje: But however you want to deal with it is fine
<ArneGoetje> StevenK: I'll poke the package maintainer again
<ArneGoetje> StevenK: I really don't want to carry a delta around
<StevenK> ArneGoetje: Even if it's a one-line delta? :-)
<ArneGoetje> lidaobing: what about bug #420282 ?
<ubottu> Launchpad bug 420282 in ibus "ibus is in "other" category in the menu" [Undecided,New] https://launchpad.net/bugs/420282
<lidaobing> ArneGoetje, I'll fix that in today or tomorrow
<ArneGoetje> lidaobing: thanks
<ArneGoetje> StevenK: ^
<StevenK> Fix it how, though? :-)
<pitti> Good morning
<pitti> dholbach: no, from what I know scim should move to universe, we only keep ibus
<dholbach> pitti: ArneGoetje seems to think otherwise
<pitti> oh really? I thought we discussed that
<pitti> ArneGoetje: we still need scim?
 * StevenK waves to pitti, throwing him a gummy bear
<dholbach> hey seb128
<seb128> hello dholbach
<pitti> hey StevenK!
<ogra> hmm, did pidgin finally move to universe ?
<StevenK> I thought it was supposed to stay?
 * ogra wonders why nautilus-sendto doesnt find it at build time
<ogra> well, n-s ftbfs on armel
<ogra>  pidgin-dev: Depends: pidgin (>= 1:2.6.1-2ubuntu1) but it is not going to be installed
<ogra>               Depends: libpurple-dev but it is not going to be installed
<seb128> arch all-any mismatch there?
<seb128> the new version has just been uploaded yesterday
<ogra> yeah, i missed there was a pidgin upload yesterday
<ogra> given back
<ArneGoetje> pitti: if ibus is too buggy and we cannot fix the issues in time, we'll switch back to scim... that's what we discussed.
<pitti> ArneGoetje: right, but why do we need to keep both in main?
<ArneGoetje> pitti: you want to move scim back and forth?
<pitti> well, I want to make sure that we fix all dependencies, so that it is ready to go to universe
<pitti> ArneGoetje: ATM, something still keeps it in main through a dependency
<slangasek> TheMuso: why is paprefs now pulling in packagekit-gnome?
<slangasek> TheMuso: I now have an extra (and buggy) update notification icon on my taskbar thanks to this; I think I'm going to remove paprefs from my system to get rid of it, but the dependency looks wrong to me anyway
<Ryan52> dholbach, asac, didrocks: could one of you please look at this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-web-photo/+bug/423822
<ubottu> Launchpad bug 423822 in gnome-web-photo "Take screenshot from web does not work." [Medium,New]
<Ryan52> dholbach, asac, didrocks: that ugly hack of a wrapper script around gnome-web-photo instead of linking properly to libxul was probably a bad idea...
<dholbach> asac: can you take a look at it? I don't know enough about it
<mvo> slangasek: I filed a bug about this
<asac> Ryan52: using libxul is no answer for sure either. i cant remember exactly what i did, but most likely i tried to avoid porting it to use the real "standalone glue"
<Ryan52> yes, by "properly linking" I meant using the xpcom glue.
<asac> i dont know for sure how to use gnome-web-photo. please drop instructions how to reproduce in the bug
<Ryan52> honestly, I don't know how to use it either.
<Ryan52> for that, I'm sure dholbach can explain tho :)
<asac> ah thats not your bug ;)
<asac> Ryan52: want to work on it ;)`
<asac> ?
<Ryan52> I'm not an Ubuntu user, and we don't have gnome-web-photo in Debian. I'm just taking care of my shutter users. :)
<asac> what does shutter do then?
<Ryan52> takes screenshots from various places, one of those places being the web, for which it uses gnome-web-photo.
<asac> how
<asac> ?
<dholbach> daniel@miyazaki:~$ gnome-web-photo.real --mode=thumbnail https://daniel.holba.ch/blog bla.png
<dholbach> gnome-web-photo.real: error while loading shared libraries: libxul.so: cannot open shared object file: No such file or directory
<dholbach> daniel@miyazaki:~$
<asac> do you run a command? or link against a lib?
<asac> dont call .real
<dholbach> I guess that's what the problem is right now
<asac> why do you do that?
<dholbach> asac: the other one didn't work either :)
<dholbach> but basically that's how you'd run it
<Ryan52> asac: once gnome-web-photo works, shutter will too, so fix dholbach's problem :)
<asac> Ryan52: .real is not supposed to work
<Ryan52> asac: he said the other one doesn't work either.
<asac> but no hint how
<asac> from what i know the non-real thing sets the LD_LIBRARY_PATH
<dholbach> daniel@miyazaki:~$ gnome-web-photo --mode=thumbnail https://daniel.holba.ch/blog bla.png
<dholbach> Registering '@mozilla.org/module-loader/python;1' (libpyloader.so)
<dholbach> Registering '@mozilla.org/network/protocol/about;1?what=python' (pyabout.py)
<dholbach> <hang>
<asac> so thats different ;)
<asac> and has nothing to do with libxul
<dholbach> I have no idea what happens there tbh
<asac> Ryan52: ^^ dont call .real ;)
<Ryan52> ./share/shutter/resources/modules/Shutter/Screenshot/Web.pm:    system("gnome-web-photo --timeout=$self->{_timeout} --mode=photo --format=$self->{_format} -q $self->{_quality} '$self->{_url}' '$self->{_dest_filename}'");
<Ryan52> from shutter's source code.
<Ryan52> so it doesn't look like shutter is calling .real
<asac> but http://launchpadlibrarian.net/31278228/screenshot_006.png
<asac> dholbach: can you paste the non-real script?
<dholbach> just a sec
<Ryan52> asac: I dunno, I'm just telling you what I know :)
<dholbach> http://paste.ubuntu.com/264842/
<mat_t> pitti: hey
 * Ryan52 thinks there should be a 1.9.1 there..
<asac> yes
<pitti> hi mat_t
<Ryan52> asac, dholbach: am I correct in assuming that neither of you are going to look further into it?
<Ryan52> I guess tomorrow I'll install Ubuntu, meh. -.-
<asac> Ryan52: any help would be appreciated. eventually i hope i would look at it
<dholbach> Ryan52: I'm too busy at the moment to look into it, I'm sorry
<asac> Ryan52: if you cannot do it, just remember to assign the bug to me
<Ryan52> okay, thanks.
<mat_t> pitti: I'm preparing the usplash assets now
<TheMuso> slangasek: Because upstream told me that it required packagekit-gnome. Unfrotunately I don't know much about packagekit, so I added a dep on the package that provided the needed executable that paprefs needs.
<pitti> TheMuso: eww, can we do without PK-gnome, please?
<pitti> we really don't want to propose it as general interface for installing packages
<pitti> PK is not suitable to be a general package installer on Debianish systems
<pitti> and it's painfully slow, too
<mvo> we should discuss this at next UDS, but if we can not get debconf support for PK I guess we need to bite the bullet and provide a PK compatible dbus session interface
<mvo> we have a debconf frontend for aptdaemon, so its not a technical problem (anymore)
<cjwatson> I think upstream said that if we want the former it should be done using the latter
<mvo> oh well
<pitti> mvo: that, and conffiles
<mvo> right
<cjwatson> Joey and I talked with Guillem at DebConf about moving bits of debconf into dpkg; it's still not out of the question that we might be able to get conffile prompts implemented using debconf
<cjwatson> which really does need to happen ultimately
<james_w> for conffiles, would there be an issue with doing the prompting at the end of the run?
<james_w> i.e. are there good reasons why the prompt is done when it is?
<cjwatson> the package isn't configured properly until the conffile is replaced; for instance you often need to replace the conffile before starting a daemon
<cjwatson> this can be pretty importance
<cjwatson> important
<pitti> but debconf is also done at preinst time, so wrt. conffiles this should DTRT?
<pitti> seb128: ah, retracers didn't upgrade yet, so they failed again; upgrading manually and restarting
<seb128> pitti, thanks
<seb128> sorry I've been not very helping on those this week
<pitti> seb128: no problem, just to let you know why you got another set of spam mails
<dholbach> mok0: great session yesterday!
<cjwatson> pitti: yes; but conffiles are postinst-time anyway
<TheMuso> pitti: Right will look Monday, but I guess we have to disable the install feature in paprefs then, or patch it to use apt...
<pitti> TheMuso: what does it want to install?
<TheMuso> pitti: afaik to install things like the bits needed to talk over the network via upnp/zeroconf etc I suspect.
<pitti> TheMuso: we could replace that with a call to gksu synaptics...? (there's a standard invocation for this to install a particular package; let me know if you need it)
<TheMuso> pitti: ok thanks
<seb128> TheMuso, hey, there is a new libcanberra version available in case you didn't notice
<seb128> not sure if you want to do the update
<TheMuso> seb128: Known, and wasn't sure if it was under the GNOME upstrea version umbrella, so just pulled important fixes from it for now.
<seb128> TheMuso, ah ok, I would just do the update it seems mostly bug fix changes
<pitti> does anyone happen to know if latest karmic now enables KMS by default on ATI?
<pitti> tkamppeter: do you have some time to look at bug 422930?
<ubottu> Launchpad bug 422930 in cups "after upgrade, CUPS refuses to use existing PSC-750 'usb' config and creates a new PSC-750-2 'hp' config" [High,Triaged] https://launchpad.net/bugs/422930
<jderose> pitti: I believe KMS is still only enabled for Intel chipsets
<pitti> jderose: ok, thanks
<jderose> pitti: but i haven't tried it, just read it from http://www.ubuntu.com/testing/karmic/alpha5
<pitti> bryce, tjaalton: is it still the plan to enable ati kms by default, as said on https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus ?
<tjaalton> pitti: I'm not sure, bryce has been testing it. AIUI there are performance regressions when it's used
<Riddell> asac: this would be nice to look at, probably for karmic+1 http://lists.opensuse.org/opensuse-kde/2009-09/msg00006.html
<asac> Riddell: yeah. but it has to land upstream first ;)
<asac> in the past suses hacks against ffox were regularly rejected
<asac> but right. i should check and see if i can helkp them with upstreaming this
<tkamppeter> pitti, bug 422930 is most likely called by the USB backend problems of CUPS. Please also upload the current BZR state of CUPS to assure that all fixes are in.
<ubottu> Launchpad bug 422930 in cups "after upgrade, CUPS refuses to use existing PSC-750 'usb' config and creates a new PSC-750-2 'hp' config" [High,Triaged] https://launchpad.net/bugs/422930
<pitti> tkamppeter: current bzr head is already in karmic (I uploaded a bzr snapshot for alpha-5)
<tkamppeter> pitti, OK, thanks.
<taavikko> pitti: I accidentally may have selected "ignore future crashes" in apport, I just can't find the right place to nullify this decision... any help?
<pitti> taavikko: rm ~/.apport-ignore.xml
<pitti> taavikko: or wait until a new version of that program arrives :)
<taavikko> thanks a punch pitti :)
<ogra> dont punch pitti, we need him ;)
<taavikko> hold the thanks then, "no .apport-ignore.xml here..."
<blackxored> greetings
<pitti> taavikko: then you don't have an ignore list
<taavikko> pitti: then apport fails somehow to collect crash (it used to work few times today already, but not anymore? )
<taavikko> arora keeps crashing ( bug 420474 ) and the .crash file kept growing...
<ubottu> Launchpad bug 420474 in arora "arora crashed with SIGSEGV in PL_HashTableLookupConst()" [Undecided,Confirmed] https://launchpad.net/bugs/420474
<taavikko> todays first crash report was 1GiB in size, removed it, next crash, resulted in 276MiB size, now it is 42Mib so little "funny behaviour"
<pitti> taavikko: if it already crashed three times today, it will ignore further crashes today; remove the file in /var/crash if you want to get new ones
<taavikko> pitti: doh, the max-report thingy :)
<taavikko> is there any limitations how big the crash report can be? didn't felt comfotable sending 1GiB
<pitti> taavikko: it's meant to prevent eternal crash loops with programs which restart themselves but crash (e. g. nautilus or devkit-disks)
<ogra> pitti, are you the one making decisions about usplash staying/going etc ?
 * ogra would like what the status is for live images ... do we keep it there ? 
<ogra> *like to know
<pitti> taavikko: it's by and large capped on half of your memory size uncompressed core dump
<pitti> taavikko: but yes, you shouldn't bother sending a 1GB dump..
<pitti> ogra: I thought it was collectively decided at UDS already
<pitti> ogra: since usplash kicks in after a (short) timeout, it should automatically come up on the live CDs AFAIUI
<ogra> i wasnt there
<ogra> ah, cool
<pitti> usplash should start (1) on interactivity (boot password), (2) on fsck, (3) when X takes too long to start
<ogra> pitti, that concept means if my armel system takes 45sec to boot i will have usplash anyway ?
<pitti> ogra: yes; my laptop takes a similar time, so I should see it, too
<ogra> cool
<ogra> so my work wasnte throw away stuff to make usplash work on imx51 :)
<ogra> *wasnt
<Notch-11> hi, i'm trying to "beep" during the boot process, but i can't ear anything... must i load some modules or something else to get beep to work?
<ogra> probably the pcspkr module ?
<ogra> (just a guess)
<pitti> Notch-11: pcspkr is blacklisted, you probably need that
<Notch-11> ogra: yes, my first guess too, but still can't ear the beep
<Notch-11> pitti: with "modprobe pcsprk" should work even if blacklisted, right?
<pitti> Notch-11: yes
<pitti> Notch-11: if you spell pcspkr right, that is :)
<Notch-11> pitti: hehe, both tried :P
<Notch-11> mm pcspkr is not in the initrd, maybe this
<Notch-11> ubuntu pcspkr
<Notch-11> ups
<highvoltage> http://www.urbandictionary.com/define.php?term=jonathan
<highvoltage> (sorry wrong channel)
<Notch-11> nothing, even with the module loaded..
<Notch-11> so what is missing for beep to beep ?
<RainCT> Keybuk: Hey. Does D-Bus on Karmic have some limitation (as in the size of the answer to a call or something like that) impossed which wasn't there  in Jaunty?
<Keybuk> RainCT: not that I know of
<Keybuk> there *are* limits to such things
<Keybuk> but I don't think they have changed
<Keybuk> in fact, the primary limit of D-Bus used to be the length of time a receiver of a message was permitted to take to reply to it until it timed out
<Keybuk> and that's been entirely removed
<ogra> Keybuk, did you see my ping before ?
<Keybuk> ogra: no
<ogra> Keybuk, did you notice that the boot slows down with every apparmor profile thats being adeed (additional reads ... i see a massive impact on armel but suspect it happens on other areches as well, just not as noticeable)
<jdstrand> ogra, Keybuk: that is not accurate any more
<Keybuk> ograyes
<ogra> jdstrand, since when ?
<ogra> i see it on A5
<jdstrand> ogra, Keybuk: or at least not noticably accuate
<Keybuk> though that should be largely fixed in karmic aiui
<Keybuk> I've certainly not noticed apparmor take that long
<Keybuk> (and I made it largely background anyway in my prototype - so services depend on it but not X)
<ogra> for me it's enough to make usplash time out
<RainCT> Keybuk: Weird. We are having problems with Zeitgeist, always getting the generic error message ("may have timeout/disconnected/etc") when fetching more than 140 items in Karmic, but this works fine on Jaunty (and is actually pretty fast). Anyway, thanks for the info :)
<jdstrand> ogra: kees implemented binary caching for the profiles
<ogra> (on armel)
<ogra> jdstrand, after usplash timed out i can slowly count to 5 to see the [ok] appear
<jdstrand> ogra: this is very fast loading, assuming that the cache file exists. if it doesn't already exist, it the cache file must be compiled (done automatically)
<ogra> if it was added after A5 i havent probably tried it yet
<jdstrand> (or if the profile changed)
<ogra> but it is surely noticeable in my A5 installs
<jdstrand> subsequent boots will use the cache then
<ogra> ok, i'll keep an eye on it ...
<jdstrand> ogra: that is certainly odd-- it shouldn't take that long. kees did the implementation so you'd want to follow up with him for problems you are having with it
<ogra> i guess usplash needs a bigger timeout anyway on arm
<ogra> will do ...
<jdstrand> ogra: this feature was added way before A5, so I'm not sure what is going on
<Keybuk> the usplash timeout thing is interesting
<ogra> i'm currently busy with other stuff and will ping him if i have time for tests and measurements
<Keybuk> I just noticed yesterday that there's no support for it in the upstart-based boot
<Keybuk> so technically we need to disable the timeout entirely ;)
<ogra> meaning ?
<ogra> it cant time out at all ?
<Keybuk> right
<ogra> or we just lose ability to change it
<ogra> ah, cool
 * ogra loves that
<Keybuk> no timeout, upstart already knows to kill usplash itself
<Keybuk> (and there's nothing on the console to timeout *to* anyway)
<ogra> heh
<Ryan52> asac_: ya that wrapper script is crap.
<Ryan52> asac_: it thinks it'll find libxul is /usr/lib/xulrunner-addons/
<Ryan52> asac_: changing the 1.9.0 to 1.9.1 in it fixes the problem.
 * Ryan52 will get a package made later, gotta go now
<asac_> Ryan52: thx.
<asac_> Ryan52: if you want you can fix it to use standalone glue ;)
<tkamppeter> pitti: Your nre udev rules (bug 420015) work.
<ubottu> Launchpad bug 420015 in udev "usblp Kernel module needs to be removed and /dev/bus/usb/*/* made accessible for USB printers to work with CUPS 1.4.x" [Wishlist,In progress] https://launchpad.net/bugs/420015
<pitti> tkamppeter: \o/
<pitti> tkamppeter: thanks for testing; committing then
<kees> ogra: hrm, you're sure it's in apparmor it's stalling?  can you check if /etc/apparmor.d/cache has files?
<ogra> kees, on monday ...
<seb128> slangasek, are you going to upload your empathy fix or should I do it?
<slangasek> seb128: not in the next hour or so; if you don't beat me to it, I'll have a look after the meeting :)
<seb128> slangasek, I do it now
<kees> ogra: okay (i'm out on monday, US holiday...)
<ogra> kees, tue. then, my schedule is full today
<kees> ogra: okay
<ogra> i want to do some measuring first so i can come up with some numbers
<dholbach> Ubuntu Developer Week - last day, starting in 16 minutes in #ubuntu-classroom - https://wiki.ubuntu.com/UbuntuDeveloperWeek
<Daviey> \o/
<dholbach> hey Daviey!
<dholbach> waaaah, I have a half-installed grub-common (/usr/sbin/grub-set-default in package grub too) - am I going to die?!?!?!
<cjwatson> bleh
<cjwatson> --force-overwrite it for now
<dholbach> thanks cjwatson
<jdstrand> cjwatson: hmm, bug #423485 doesn't seem to be fixed by the rebuild
<ubottu> Launchpad bug 423485 in valgrind "Valgrind needs to be recompiled for glibc 2.10" [Undecided,Fix released] https://launchpad.net/bugs/423485
<jdstrand>  *** 1:3.4.1-1ubuntu2 0
<jdstrand> valgrind /bin/echo hello
<jdstrand> (very noisy)
<cjwatson> jdstrand: it worked for me - can you try to track it down? does /usr/lib/valgrind/default.supp have 2.10 suppressions?
<jdstrand> # Errors to suppress by default with glibc 2.10.x
<jdstrand> cjwatson: seems to, but I've never looked at this file before
<nh2> hi, how to get an app into that "easy-going" gnome app installer (add/remove software)?
<cjwatson> kirkland,soren: would appreciate it if you could once-over lp:~cjwatson/eucalyptus/discover-nodes
<slangasek> TheMuso: I see nothing in the paprefs package description that explains why it needs to install packages; it's definitely not getting back on my system as long as it has that dep, though
<Lutin> I there anything needed to get the flash plugin to output audio with pulseaudio on karmic ? doesn't seem to work here
<ebroder> Is it OK for package-a to depend on package-b, and package-b to depend on a >= version of package-a?
<ebroder> I don't know whether apt will do the right thing with that or not
<cyber_666_uk> hey - can anyone submit software to the repositories?
<cyber_666_uk> how does that work, do you need to give out your source code?
<slangasek> ebroder: it's generally inadvisable; the package manager has provisions for breaking dependency loops, but it's better to not have them in the first place (e.g., by putting everything in a single binary package instead of splitting it)
<ebroder> Hmm...that might actually be an option. This used to be a one-way dependency pointer until the change I just made, so it was less of an issue :)
<ebroder> It should be fine if apt wants to temporarily break the loop, though. Thanks
<cyber_666_uk> is there a page you can point me to?
<kirkland> cjwatson: looking ...
<kirkland> cjwatson: looks okay by me
<kirkland> cjwatson: i had added the avahi-utils recommends locally here
<kirkland> cjwatson: so i can fix that up on merge
<kirkland> cjwatson: would you like me to merge, and push that to our working tree?
<sgallagh> mathiaz: ping
<mathiaz> sgallagh: hi
<sgallagh> mathiaz: I don't know if you caught the bug update, but I fixed that hang you were seeing in the proxy provider.
<mathiaz> sgallagh: right - I saw something going through
<mathiaz> sgallagh: do you plan to maintain a 0.5.X branch?
<sgallagh> I figured you'd probably want to pull that and the D-BUS fix in and roll another package
<sgallagh> mathiaz: Not at this time, mainly because we're targeting 0.6.0 for Sept. 24th
<mathiaz> sgallagh: understood
<mathiaz> sgallagh: thanks for letting me know
<sgallagh> mathiaz: I wanted to ask something else
<sgallagh> mathiaz: Does the Ubuntu development process have anything like concerted feature test days?
<sgallagh> I'd like to try and get one scheduled for the SSSD if so
<mathiaz> marjo: bdmurray: ^^?
<mathiaz> sgallagh: so yes - we're running TestingDays
<mathiaz> sgallagh: https://wiki.ubuntu.com/Testing/
<mathiaz> sgallagh: https://wiki.ubuntu.com/Testing/UbuntuTestingDay/
<mathiaz> sgallagh: hm - there hasn't be one run for a while now
<sgallagh> mathiaz: Can you possibly look into scheduling one for us?
<mathiaz> sgallagh: we could organize such a day though
<mathiaz> sgallagh: sure - I'll get in touch with the QA team
<sgallagh> mathiaz: Great, thank you!
<sistpoty> hey, congrats bryce!
<bryce> sistpoty, thanks
<sistpoty> bryce: before you leave, any opinion on bug #424354? if testing confirms that my patch works, ok to upload it?
<ubottu> Launchpad bug 424354 in xserver-xorg-video-cirrus "pitch too high for CL5446 at 1360x768" [Undecided,New] https://launchpad.net/bugs/424354
<bryce> sistpoty, wow that's an oddball bug
<bryce> sistpoty, but if that patch solves it, yeah I wouldn't have a problem seeing that go in for -cirrus.  Looks properly conditionalized to only affect the specific chip
<sistpoty> bryce: ok, thanks... I'll take care to forward it upstream as well then
<bryce> sistpoty, so yes, if testing confirms it works, feel free to upload, but please be sure to check launchpad after a couple weeks in case there are any regression bugs reported
<bryce> great
<sistpoty> bryce: sure, iirc I'm still subscribed to -cirrus bugs (iirc there aren't many people with real cirrus cards out there *g*)
<bryce> hehe
<sistpoty> and the 4 mb versions seem to be extremely rare, still haven't managed to get one via ebay :(
<cjwatson> kirkland: I think it's awaiting an FFE (there's a bug), but otherwise yes please
<cjwatson> unless somebody wants to process that :)
<kirkland> cjwatson: i was just going to commit to the upstream project for now, and wait for soren to push a package upload
<cjwatson> ok, if that's cool with upstream
<moldy> hi
<moldy> can i safely delete/bzr ignore the .upload files dput creates, or is the information in them important for something?
<cjwatson> you can safely delete them; the log file causes dput not to upload the same thing again should you run it again on the same .changes
<moldy> cjwatson: ok, thank you
<moldy> i just created my first ppa and tried to upload some packages
<moldy> i got an error e-mail saying "Unable to find distroseries: unstable"
<moldy> what's the right way to correct this?
<cjwatson> don't put "unstable" in the top line of your changelog - use "karmic" or whatever
<sistpoty> moldy: use one of ubuntu (karmic, jaunty, intrepid, ...) in debian/changelog
<moldy> sistpoty: ah, ok, thank you
<sistpoty> np
<moldy> and you too, cjwatson :)
<cjwatson> that should really be in https://help.launchpad.net/Packaging/UploadErrors
<cjwatson> (it isn't)
<cjwatson> maybe you could suggest that to them
<sistpoty> imho a ppa should accept $whatever except releases
<cjwatson> the top line of the changelog tells it which release to build for and against
<cjwatson> so that could only work if you reinvented the wheel to tell it some other way
 * sistpoty thought that was the distribution field in the changes file
<moldy> what's the right way to suggest that, cjwatson?
<cjwatson> moldy: there's a link at the bottom of the page for giving feedback
<cjwatson> sistpoty: which is generated from the top line of the changelog
<moldy> cjwatson: ah, right
<sistpoty> cjwatson: yep, but changing that wouldn't mean I'd hand out a ticket to upload a ppa package to ubuntu :)
<sistpoty> would mean that I wouldn't even
<cjwatson> oh, you mean that it should accept something that is not the same as Ubuntu release names
<sistpoty> yes
<cjwatson> I thought you meant it should accept *anything*
<cjwatson> yes, I agree - there's a pretty old bug about the replay attack there
<sistpoty> iirc it's fixed nowadays (I filed it after siretart discovered it)... but you never now ;)
<sistpoty> know even
<moldy> it might also be nice if dput would check this client-side
<sistpoty> same is true for revu. the .changes file is there for the pleasure of revu admins but gets stripped for storage purposes (iirc)
<sistpoty> moldy: partially agree... otoh I couldn't upload to unstable then (ok, agreed I can't right now myself, and even if I could, I should test the package really on unstable)
<cjwatson> I can upload to unstable and occasionally do so from Ubuntu (after testing on unstable, of course)
<cjwatson> usually due to forgetting which window I'm in but ...
<moldy> ok, one should make it configureable if one did it
<cjwatson> it doesn't really bother me, in order to actually break something in unstable you have to upload to the wrong place as well as having the wrong distribution target
<cjwatson> so there's no real safety reason for a client-side check
 * sistpoty wonders what would happen if he'd put multiple values in the Distribution field of a .changes file and would upload that
<Daviey> the intertubes would melt.
<sistpoty> Daviey: let's see, I'm just testing revu with it :)
<Daviey> *BOOM* :)
<cjwatson> sistpoty: there's a bug about that ;-)
<cjwatson> "it gets complicated"
<sistpoty> heh
<cjwatson> https://bugs.launchpad.net/soyuz/+bug/235064
<ubottu> Ubuntu bug 235064 in soyuz "Implement multi-release support for packages" [High,Triaged]
<sistpoty> nice, thanks for the pointer cjwatson
#ubuntu-devel 2009-09-05
<jdstrand> cjwatson: fyi, heading out for the day (and long weekend). I did find out a few things on bug #423485 if you want to llok at it more
<ubottu> Launchpad bug 423485 in valgrind "Valgrind needs to be recompiled for glibc 2.10" [Undecided,Triaged] https://launchpad.net/bugs/423485
<jdstrand> cjwatson: if not, I can look at it next week
<Ryan52> asac: I can't figure it out.
<Ryan52> asac: it seems there's support for the XPCOM stuff from reading the source code, it's just linking/compiling/something wrong.
<Ryan52> asac: messing with configure for a while (could just edit the .m4 and autoreconf, because something else's broken..) proved useless.
<Ryan52> asac: tho I did pop in a karmic live cd and reproduced the problem finding libxul (or whatever the message was) when running gnome-web-photo, so my results match up with the bug reported not dholbach.
<Ryan52> asac: anyways, if you could give me a hint, maybe.. :)
<Ryan52> asac: everything I do I get undefined references.
<slangasek> pitti, ArneGoetje: are these language-support-translations-* packages meant to be demoted to universe?
<slangasek> pitti: er, you're dropping the cupsys transitional packages that are still used on upgrade from hardy?
<pburleson> Not sure if this is the right place to ask, but I think it is: how do I find out what configuration and make options were used to generate an Ubuntu binary package?
<pburleson> I need to deploy new version of Proftpd and I wanted to make sure I used the same configuration parameters the normal Ubuntu package is built with
<Ryan52> pburleson: usually by looking at it's debian/rules file.
<pburleson> in the source package?
<Ryan52> yes.
<pburleson> thank you
<Ryan52> tho for some packages, it requires knowledge of debhelper/CDBS/etc.
<pburleson> oh, fun
<YokoZar1> jcastro: Is this you: http://video.linuxfoundation.org/users/canonical  ?
<jcastro> YokoZar1: no, I have no idea how that got on there
<YokoZar1> jcastro: well it's a good outlet as I got an email from a Wine dev who didn't see it until it was there
<asac> Ryan52: how are you trying to link now?
<melvin> Hi. The run dialog isn't working  after yesterdays update. is it a known problem?
<melvin> and pulseaudiu doesn't sound out anything
<melvin> Error MEssage from teh Run dialog: "Unable to load file '/usr/share/gnome-panel/glade/panel-run-dialog.glade'"
<fta> cjwatson, fyi, the new zlib in karmic is causing me some troubles: http://paste.ubuntu.com/265545/
<moldy> hi
<moldy> when uploading to my ppa, i get File <UPLOADED_FILE> already exists in <LOCATION>, but uploaded version has different contents.
<moldy> but i don't really understand why
<moldy> am i forced to bump the version number?
<fta> moldy, you're sending a source package with the same .orig.tar.gz name but not the same content (different md5/sha). See -sa vs -sd
<moldy> fta: hm, ok, i think i begin to understand :)
<asac> i added the chromium zlib log fta gave me to the bug 402178
<ubottu> Launchpad bug 402178 in libpciaccess "gzopen64 implicitly converted to pointer" [High,Fix released] https://launchpad.net/bugs/402178
<moldy> fta: i am changing the source along with the ubuntu package... i guess the solution is to just delete the package from the ppa and upload it again
<fta> moldy, no
<fta> moldy, just redo your source package with -sd instead of -sa
<moldy> fta: will try that, thanks
<moldy> fta: hm, same results
<fta> moldy, either you don't include the .orig.tar.gz in the dsc (as i said), or you have to reuse the exact same tarball already in the archives
<fta> moldy, this question is more for #ubuntu-motu btw
<moldy> hm, maybe i included the orig.tar.gz by accident
<moldy> fta: ok, thank you
<moldy> hm, the thing is, i am using -sd, but orig.tar.gz still seems to end up in the dsc...
<james_w> moldy: -sd controls the .changes file
<james_w> the .orig.tar.gz always has to be in the .dsc
<james_w> for the checksum
<moldy> ok, i see. but then i still don't understand why i get that error e-mail
<james_w> well, it applies to all the parts, not just the .diff.gz
<james_w> so if you are re-using a version number that is in Ubuntu or in your PPA then you will likely see it
<moldy> hm, the error message only complains about the orig.tar.gz
<james_w> well, you uploaded the orig.tar.gz then
<james_w> -sd should have stopped that, but maybe you didn't upload what you expected to
<moldy> hm, i will re-check this
<moldy> when you're talking about -sd, you are talking about dpkg-buildpackage?
<james_w> yeah
<moldy> ok, the dput output said it uploaded the .dsc, the .diff.gz and the .changes
<moldy> ... but i still get that error e-mail :(
<moldy> now both for the .orig.tar.gz and the .diff.tar.gz
<asac> siretart: would you mind to join #ubuntu-mozillateam for a while ;) ... on ffmpeg.
<pitti> slangasek: language-support-translations-*> please leave them for now, they will be removed once the new language-selector is uploaded
<pitti> slangasek: cupsys transitional packages> eww, forgot; will re-add them
<james_w> moldy: ah, I remember it's comparing the checksums, even though you don't upload it
<james_w> moldy: use the same .orig.tar.gz that is in the archive when building
<james_w> but still use -sd
<moldy> james_w: ok, will try that, thank you
<moldy> james_w: will just bumping the version number also work? i'm beginning to think it's the easiest solution
<moldy> james_w: now it complains that orig.tar.gz is missing "in upload or distribution" :) i'm giving up, trying to see if another version number works
<hyperair> is anyone noticing underruns when something is playing sound, and something else interrupts it?
<ion> My guess would be is that pulseaudio expects a lower latency than it can actually achieve, because rtkit isnât able to provide that for it, because the kernel patch isnât added to Ubuntu yet.
<ulaas> hi .whats wrong with libldb-samba4-0
<ulaas> will evolution-mapi see some love before karmic release?
<donri> why software-store over gnome-packagekit? if something is wrong with it, would it not be better to fix it? ubuntu specific things required? is that really a good thing?
<Ryan52> asac: I dunno, I just messed around for a while...I don't really have a clue what I'm doing when it comes to this XPCOM glue stuff :)
<cjwatson> fta: I thought that's what mvo was fixing; if he broke it, best check with him rather than me
<fta> cjwatson, ok
<slangasek> pitti: ok.  btw, those uninstallable gnome langpack packages are the current cause of Ubuntu DVD build failures
<cjwatson> anyone have any idea where bug 70317 ought to be fixed?
<ubottu> Launchpad bug 70317 in ubuntu "constant kernel errors about unknown multimedia keys" [Undecided,New] https://launchpad.net/bugs/70317
<slangasek> jelmer: bug #424626> anything I can do to help with getting the new version into karmic, then?
<ubottu> Launchpad bug 424626 in bzr-svn "bzr-svn breaks https:// urls?" [Undecided,New] https://launchpad.net/bugs/424626
<slangasek> cjwatson: either udev or the kernel
<slangasek> (depending on whether the key presses are already recognized - kernel - or not - udev)
<cjwatson> if I reassign it to udev, won't Scott just tell me that some console package should be figuring out the keyboard in use and installing a udev rule? :-)
<cjwatson> (and he might have a point, unless udev already has keyboard stuff in it ...)
<slangasek> udev does have keyboard stuff in it
<slangasek> /lib/udev/keymaps
<cjwatson> ah, does it now - that's new since I last looked
<slangasek> part of the halsectomy :)
<cjwatson> the current iteration of the report is on 9.04 so it may predate that
<slangasek> I don't think there are /currently/ any keymaps in place for non-laptop keyboards (I see now this is a Microsoft wireless keyboard), but no reason there can't / shouldn't be
<slangasek> OTOH, if these are "power status messages" that shouldn't register as keys at all, then it may yet be a kernel bug
<cjwatson> well, I've learned something today, thanks
<cjwatson> reassigned the bug
<slangasek> :)
<LaserJock> you guys happen to know what might cause having to resume twice after suspend in order to get it to actually resume?
<slangasek> LaserJock: double suspend event handling
<slangasek> possibly because of buggy hotkey configuration
<LaserJock> I noticed that at least some of my laptop's function keys no longer work
<LaserJock> but I'm somewhat hardware-illiterate as almost always Ubuntu just works on my hardware
<LaserJock> slangasek: what would be a likely package to look for bugs of this kind?
<slangasek> LaserJock: https://wiki.ubuntu.com/Hotkeys/Troubleshooting
<LaserJock> slangasek: awesome, thanks
<LaserJock> with xev, if I press a keyboard key should I expect 2 events? like one for pressing down and one for releasing?
<slangasek> yes
<slangasek> (if it's a key that's passed via X)
<LaserJock> ok
#ubuntu-devel 2009-09-06
<Lutin> ScottK: you'll need to ACK the sync request for edje too, otherwise we still have a rdep on libeina-svn-01
<ScottK> Lutin: I did that one too.
<ScottK> Lutin: I guess I missed the bug when I was looking through the list.
<ScottK> It's in binary New right now.
<Lutin> ScottK: great, thanks
<pabs3> anyone know who to contact about the webserver on packages.ubuntu.com being down?
<YokoZar> What's the name of the new volume applet?  I want to report a bug on it
<hyperair>  gnome-volume-control-applet, if i'm not mistaken
<hyperair> wait lemme dpkg -S it
<hyperair> package is gnome-media
<YokoZar> hyperair: thanks
<YokoZar> ArneGoetje: I have a package that went from producing a .ttf to a .otf on a minor version upgrade.  Is this due to a build tool changing or the package itself?  I was originally going to just drop teh .ttf and link to our system-provided one, but now it's a .otf and I'm not sure
<cumulus007> Hi, I'm wondering if it's possible to translate the text shown in the slideshow during the installation of Ubuntu 9.10
<cumulus007> I found a bug about this issue: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/425008
<ubottu> Ubuntu bug 425008 in debian-installer "[karmic] alpha-5, translation template is out of date, does not include new slideshow strings or encryption option" [Undecided,Invalid]
<cumulus007> never mind, I found the solution :)
<ArneGoetje> YokoZar: whether it's .ttf or .otf doesn't matter that much. TTF is a subset of OTF. fontforge can handle both formats. In fact, most modern .ttf fonts are actually OTF fonts if they use the GSUB or GPOS tables. However, the filename extension doesn't matter. Maybe the .ttf has been renamed to .otf to make clear that the .ttf is actually a OTF. :) Whatever, it's still the same font.
<Stenudd> Hello, having problem open the QT Designer file(.ui) for the gnome-panel clock applet, running ubuntu 9.04 and installed QT 4 Designer. It says it's not a valid file..
<Stenudd> Someone know anything about this?
<Stenudd> Invalid ui file: The root element is missing.
<hyperair> Stenudd: it's not a qt designer file.
<hyperair> Stenudd: it's a gtkbuilder file.
<hyperair> Stenudd: you open it in glade-3
<Stenudd> hyperair, Thank you :)
<Stenudd> hyperair, I'll try that, i thought it was strange it be in QT Designer, 2.24 files was in glade with the extension .glade
<hyperair> Stenudd: well glade is deprecated, and gnome things will never use qt.
<Stenudd> ^^
<hyperair> well at least not without lots of flames and developers jumping ship
<Turl> fta: hi, may I PM you?
<Ryan52> asac: okay, I'll fix it the easy way I guess, just so that it's fixed for now.
<TomaszD> hello Ubuntu devs, it's that time of the year again. I've been doing this for the past 4 years and I'll probably keep doing this until someone fixes this once and for all, but it would seem that Ubuntu-specific applications have translation problems, again. update-manager has an incomplete translation template, as well as gnome-app-install. computer-janitor basically doesn't have a translation template as the interface is all new, but no new tem
<TomaszD> plate, the new "Logic" submenu in Games is left untranslatable, the "ibus" package is in main, but there is no translation template available...
<TomaszD> and this is just from a few moments of test driving it
<TomaszD> I have reported these issues
<TomaszD> but I'm trying to bring a general issue to light, and it's that not many people care too much about whether we have translatable apps or not.
<TomaszD> in a unique twist of irony, the language-selector app does not make use of any translations, despite being fully translated in launchpad, I forgot about this thing
<slangasek> TomaszD: missing translation templates should generally be reported as bugs against the packages in question
<TomaszD> slangasek, I have done so already
<slangasek> ok
<slangasek> hmm, seems update-manager has quite a large set of bugs, no wonder that one hasn't been addressed :/
<TomaszD> what I'm trying to point out is the lack of some sort of mechanism, a procedure that would prevent this from happening
<slangasek> no such mechanism is possible in the general case
<TomaszD> well, at least when a new package enters main, make sure you have the template in launchpad, something like that is possible
<TomaszD> otherwise I do understand how all this works
<slangasek> update-manager has a template, the problem is a bug in not getting the .pot properly regenerated
<TomaszD> I am aware of that, only a part of the UI is available for translation
<slangasek> computer-janitor confuses me, I'll have to look at that - I do remember it having i18n support
<TomaszD> yes, it did have that support
<TomaszD> now there's just a template in lp from the previous version
<TomaszD> there should be a person or two assigned for strictly this, get ubuntu devel once in a while, check all installed applications for translation problems, report to the authors in question instead of going through the bug channel which is like drinking from the firehose, often people forget about these issues
<slangasek> the bug channel is the correct way to report it to the authors
<TomaszD> before every release I come here crying and begging to fix my reported bugs about the templates, without this it's usually too late, there are always more important problems to fix
<slangasek> TomaszD: do you know David Planella?
<TomaszD> slangasek, no.
<slangasek> he's the Ubuntu Translations Coordinator; I think he might be a useful contact for you to have in escalating these issues
<slangasek> https://launchpad.net/~dpm
<TomaszD> yeah, I just found him
<TomaszD> ah, a fellow GNOME translator, there's always an overlap
<pvl1> hi everyone, im new to linux development, and I wanted to know how can I access something like Microsofts virtual keys using C++? i want to be able to read keyboard input
<Turl> pvl1: have you tried std::cin ?
<pvl1> nope, but i thought that std only returns chars?
<Turl> it reads from the keyboard
<Turl> http://augustcouncil.com/~tgibson/tutorial/iotips.html
<pvl1> hm, i guess ill try that, but also, idk if its the same include scheme in linux as in XP. for example if i want to include the std, id do #include<iostream>, but idk if the path environment variable is set
<slangasek> it doesn't "read from the keyboard", it reads the standard input; but this is not a channel for Linux development questions
<pvl1> well i specifically plan to use ubuntu, so i thought it was an ubuntu specific question
<pvl1> should i go to a linux devel chat?
<Turl> slangasek: I'm no c++ guru :P
<Turl> pvl1: you might try a C channel
<Turl> c++, sorry
<pvl1> hm, ill go look for one, thank you tho, ill stilll look into std cin tho
<Turl> pvl1: #c++
<pvl1> thnx
<TomaszD> slangasek, while you're on a roll, you could also check out usb-creator, which has been broken for a while now as well https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/419069
<ubottu> Ubuntu bug 419069 in usb-creator "Restore translatable strings from GtkBuilder files" [Undecided,New]
<nick125> Good afternoon. Would this be the appropriate place for someone looking to help out with Ubuntu development? I'm trying to find a place where I can help out.
<lifeless> hi
<lifeless> yes, or #ubuntu-motu
<lifeless> what sort of things do you want to do?
<nick125> Perhaps work on some Ubuntu applications, preferably written in Python/PyGTK.
<lifeless> most applications we ship are written by upstreams - projects like Gnome, KDE and so on
<lifeless> if you want to improve those applications, thats cool - but the best forum to do that in is the upstream project itself
<mahfiaz> is it possible to manage launchpad translations oldfashioned way using svn?
<nick125> lifeless: I was thinking of applications that don't necessarly have an upstream.
<lifeless> mahfiaz: thats more a question for #launchpad
<lifeless> nick125: uhm, I'm not really aware of any
<mahfiaz> lifeless, thanks for the tip, I'll give it a try
<nick125> lifeless: Ah well. I guess I should find an upstream that needs help...do you know of any?
<lifeless> many :)
<lifeless> probably best to pick something you have an interest in or use yourself
<nick125> I just have plenty of freetime and I need to get back into software development, so I'm pretty open :)
<mahfiaz> nick125, is there a specific range, where you feel yourself confident, like networking/user interfaces/kernel code/something else?
<nick125> mahfiaz: I'd probably go higher-level, so probably UIs. I'm most experienced in Python, but I'm willing to learn.
<mahfiaz> nick125, do you use ubuntu for your regular computing?
<nick125> Yes, I do.
<mahfiaz> and you haven't yourself stumbled on something you don't like?
<mahfiaz> I am no system programmer, but I quite frequently file bug reports about missing or misbehaving features on programs
<nick125> mahfiaz: I haven't found that much I haven't liked....perhaps I'm just used to things acting weirdly :)
<mahfiaz> for example, pidgin has a nice plugin called "integration with evolution", which syncs IM contacts to evolution contacts, but ends up with several contacts in evolution, if contact's name isn't its address
<mahfiaz> also, in evolution there is no easy "merge contacts" button
<mahfiaz> there is no such button at all
<mahfiaz> totem's handling of streams and other web content is a pain, it is unbearable at best
<mahfiaz> rhythmbox crashes every time it has to play wma, when crossfading is enabled
<mahfiaz> and on several other occassions too
<mahfiaz> gtk is damn slow, when it has to show list of > 1000 elements, like it happens in rhythmbox jamendo view or just with enormous collection
<mahfiaz> ubuntu's language support dialog exits without a notice, when dpkg is locked
<TheMuso> mahfiaz: Have you considered filing bugs for these issues you have found?
<mahfiaz> I have filed some
<mahfiaz> this was not moaning, just to give nick125 some ideas :)
<nick125> Hmm....have you filed a bug for the language support dialog? I can probably take a crack at that one :)
<mahfiaz> no, I haven't
<mahfiaz> I'll post a link back here soon, wait a second
<mahfiaz> nick125, I checked it, it works now
<mahfiaz> gives a nice error message
<Turl> what's IBus, might I ask?
<mahfiaz> it says about itself: IBus input method framework
<mahfiaz> nick125, I think this was a false positive about the gnome-language-selector, this may have been caused by a upgrade of libc6 or something else,
<nick125> Ah, quite possible.
#ubuntu-devel 2010-09-06
<pfifo> I noticed that the livecd is using aufs, and that i cannot mount anything with unionfs. Has ubuntu stopped supporting unionfs? Should I start using aufs in my own projects?
<dholbach> good morning
<bilalakhtar> good morning dholbach !
<dholbach> hi bilalakhtar
<ogra> TheMuso, i would like to see the fix mentioned in bug 631362 merged in pulse, any objections from your side ?
<ubottu> Launchpad bug 631362 in pulseaudio (Ubuntu Maverick) "Include several configuration files" [Medium,Confirmed] https://launchpad.net/bugs/631362
<ogra> (we need to be able to do arch specific configs on some arm platforms)
<tkamppeter> Anyone around who could do an update on the seeds for Maverick?
<cjwatson> tkamppeter: what sort of change?
<micahg> kdevelop's i386 packages have been pending publication for 3 days now
<cjwatson> they're in NEW, I'll process that in a moment
<micahg> cjwatson: ok, thanks :)
<tkamppeter> cjwatson, I have introduced putting PPDs in compressed archives in foomatic-db. The ready-made PostScript PPDs are already in such archives as there seed changes where not needed. This saves several MB on the desktop CDs. To save another 18 MB in the installed system I have also a replacement of the Foomatic XML data by a compressed PPD archive, but this needs replacing the requirement of foomatic-db-engine and foomatic-db by the requir
<tkamppeter> ement of foomatic-db-compressed-ppds in the seeds. This makes also the listing of all printer drivers ("lpinfo -m", adding printer with s-c-p) significantly faster. I have discussed this change with pitti last week.
<micahg> doh, it says that on the main build page for the version :-/
<cjwatson> tkamppeter: changing the seeds is premature by a couple of hours, since I'm only just processing foomatic-db-compressed-ppds through the NEW queue ;-)
<tkamppeter> cjwatson, and pitti found it a good idea, and he has helped me to put the correct dependencies into the packages.
<tkamppeter> cjwatson, OK.
<cjwatson> sure - it needs to wait until foomatic-db-compressed-ppds is published, but I can make the change then
<cjwatson> is there any remaining case where foomatic-db-engine and foomatic-db should be listed?
<tkamppeter> cjwatson, no, end users do not need these two packages any more. Now these packages appear only in build dependencies of other packages.
<cjwatson> ok
<cjwatson> micahg: processed
<tkamppeter> I have taken care of that by modifiying also the gutenprint and ptouch-driver packages where I have also replaced Foomatic XML data by compressed PPD archives.
<micahg> cjwatson: thanks, sorry, I shouldn't have bothered you for that
<tkamppeter> cjwatson, thanks already now.
<cjwatson> ivoks_away: is anything happening with bug 527195?  I've promoted a couple of its dependencies, following approved MIRs
<ubottu> Launchpad bug 527195 in pacemaker (Ubuntu) "[MIR] pacemaker" [Undecided,Incomplete] https://launchpad.net/bugs/527195
<cjwatson> tkamppeter: done your seed changes
<tkamppeter> cjwatson, thank you very much.
<cjwatson> hm, I seem to have accidentally made this my archive admin morning
<G> ttx: can I assume that bug 619302 got SRU approval?
<ubottu> Launchpad bug 619302 in qemu-kvm (Ubuntu) "kvm -initrd 'file' dumps core if 'file' does not exist" [Low,In progress] https://launchpad.net/bugs/619302
<happyaron> cjwatson: hi, could you have a look at this FTBFS, it seems due to cannot find libopencc-dev. https://edge.launchpad.net/ubuntu/+source/ibus-pinyin/1.3.10-1/+build/1948578
<cjwatson> happyaron: I don't need to look at it :)
<cjwatson> happyaron: I promoted opencc to main, but ibus-pinyin will have tried to build before that was committed to the archive - it just needs to be retried in an hour or two
<happyaron> cjwatson: oh, thanks
<happyaron> cjwatson: will the builder retry it automatically?
<cjwatson> happyaron: no, I'll retry it when it's appropriate
<cjwatson> well actually it might
<happyaron> thanks
<tkamppeter> cjwatson, I have a question to the seed changes. Will they also affect Kubuntu, Xubuntu, Edubuntu, and especially the netbook editions? Especially on netbooks saving 18 MB on the installed system would be nice.
<Riddell> tkamppeter: only if you're changing the platform.maverick seed
<cjwatson> tkamppeter: yes.
<cjwatson> (the change was in platform.maverick/desktop-common)
<cjwatson> Ubuntu Studio needed to have the change copied over manually; I've done that
<cjwatson> but the others will pick it up naturally
<ttx> G: no.
<G> ttx: it's okay, I was thinking about the wrong bug anyway :)
<cjwatson> ScottK: why can't all the stuff in kubuntu-meta/README.Kubuntu.update be done by the update script?
<Riddell> cjwatson: it should be, neither of us have spent the five minutes it would take to do it yet
<cjwatson> maybe we should just take the opportunity to make it a new seed collection.  the current implementation is fundamentally wrong because it causes LP to want to put all the kubuntu-mobile packages in main
<Riddell> that would also seem sensible
<ogra> doko, !
<persia> cjwatson, Riddell: so, last week we talked about having kubuntu-mobile be a separate seed collection (I filed some of the relevant bugs), and it does require a LP change that would have had to be rolled out today.  The feedback I received all seemed to indicate it would be better to just do MIRs for the kubuntu-mobile stuff (and I think most of them are filed).
<cjwatson> what LP change?
<persia> cron.germinate
<cjwatson> I suppose
<cjwatson> yes, if you wanted Task fields
<persia> bug #626543 was the bug to make kubuntu-mobile go in universe.  MIRs were bugs #627138 and 626583
<ubottu> Launchpad bug 626543 in kubuntu-meta (Ubuntu) "kubuntu-mobile should be built against universe" [Undecided,New] https://launchpad.net/bugs/626543
<ubottu> Launchpad bug 627138 in kubuntu-mobile-default-settings (Ubuntu) "MIR kubuntu-mobile-default-settings" [Undecided,New] https://launchpad.net/bugs/627138
<ubottu> Launchpad bug 626583 in plasma-mobile (Ubuntu) "MIR plasma-mobile" [Undecided,New] https://launchpad.net/bugs/626583
<ogra> doko, do you have any idea about OO.o on armel ?
<doko> ogra: yes, somehow. working on this
<ogra> awesome :)
<bilalakhtar> mvo: around?
<mvo> hey bilalakhtar, yes
<bilalakhtar> mvo: Whenever you have time, could you please endorse https://wiki.ubuntu.com/BilalAkhtar/MOTUApplication ?
<bilalakhtar> There is a week before the meeting, so you can endorse on any day
<bilalakhtar> I just informed you beforehand
<mvo> thanks, will do
<bilalakhtar> mvo: I should thank you!
<ivoks_away> cjwatson: i'm waiting for aproval of cluster-glue (bug 527142)
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/527142)
<cjwatson> ivoks: I realise that, but it would be worth responding to the concerns about pacemaker in the meantime, would it not?
<ivoks> cjwatson: of course
<alexvalavanis> Hi there (new to IRC, so please forgive mistakes!)
<ttx> ScottK: sorted out the cobertura-maven-plugin FTBFS situation.
<alexvalavanis> Can anyone advise how to perform a merge from Debian experimental?
<alexvalavanis> MoM doesn't seem to cover it
<alexvalavanis> and there's no lp:debian/experimental/* branch on Launchpad bzr access
<ttx> alexvalavanis: yes there is...
<cjwatson> you can always do it by hand - save diff from common-base version to current Ubuntu to a file, unpack current Debian, selectively apply patches from file
<ttx> lp:debian/experimental/tomcat6
<ttx> https://code.launchpad.net/debian/experimental/+source/tomcat6
<alexvalavanis> @ttx I can't seem to find the branch I wanted: https://code.launchpad.net/debian/experimental/+source/inkscape
<alexvalavanis> Is there a delay between a debian upload making it into bzr on Launchpad?
<ttx> alexvalavanis: hmm, indeed
<alexvalavanis> Thanks, cjwatson.  I thought about a manual merge, but I figured there was too much scope for me messing it up!
<ttx> alexvalavanis: should be in, there must be some import issue
<alexvalavanis> weird.  So do the Bazaar branches normally sync immediately?
<alexvalavanis> The debian/experimental/inkscape upload was made 3 weeks ago
<tjaalton> tkamppeter: re bug 612578, no change after backporting cups 1.4.4 from maverick
<ubottu> Launchpad bug 612578 in cups (Ubuntu) "Printing fails unless the IPP's are purged, but fails again after "some time"" [Undecided,New] https://launchpad.net/bugs/612578
<Riddell> mvo: is there a GUI in Ubuntu Desktop to change /etc/update-manager/release-upgrades from lts to normal ?
<mvo> Riddell: yes, its in software-properties-gtk
<mvo> Riddell: under "updates/Release upgrades"
<Riddell> mvo: fooey, that's something I need to add to the kde UI then
<shadeslayer> Riddell: IIRC theres also a option in synaptic
<mvo> shadeslayer: its the same dialog they both use
<mvo> Riddell: ok, should be trivial :)
<shadeslayer> mvo: right.. didnt know that :)
<ScottK> ttx: Cool.
<ScottK> cjwatson: I'm glad to adjust the kubuntu-mobile stuff as needed.  How it is now is just the best I knew to do in the time I had.
<cjwatson> if it's all going into main, then it can stay as it is pending that, I think
<cjwatson> if kubuntu-mobile is going to stay in universe, then it needs to be a separate seed collection which as persia says would require a Launchpad change
<Riddell> mvo: any idea what the mysql-server-core error is here? http://muse.19inch.net/~jr/tmp/upgrade/main.log
<mvo> Riddell: what is the md5sum of that file /var/cache/apt/archives/mysql-server-core-5.1_5.1.49-1ubuntu7_i386.deb ?
<Riddell> mvo: cad2c149aa7c9521d7794c4589f4cd2c  /var/cache/apt/archives/mysql-server-core-5.1_5.1.49-1ubuntu7_i386.deb
<Riddell> mvo: hmm, which does seem to be incorrect
<mvo> Riddell: hm, so fs corruption :/ ?
<Riddell> mvo: maybe, I'll try the upgrade again
<mvo> Riddell: iI doner if you can copy it to some other place and do a binary diff on it (compared to a downloadied one)
<mvo> Riddell: it might be a bit-flip error
<cjwatson> Keybuk: bug 603760 et al: I can easily add /var/run/sendsigs.omit.d/ support to sendsigs, but I don't really feel like playing whack-a-mole to move everything over to that directory, and having /var/run/sendsigs.omit and /lib/init/rw/sendsigs.omit.d/ seems wilfully confusing.  Would you object to a new mounted-libinitrw.conf job in mountall that just does 'exec mkdir -p /lib/init/rw/sendsigs.omit.d'?
<ubottu> Launchpad bug 603760 in sysvinit (Ubuntu) "Nobody creates /lib/init/rw/sendsigs.omit.d (dup-of: 541512)" [Undecided,New] https://launchpad.net/bugs/603760
<ubottu> Launchpad bug 541512 in sysvinit (Ubuntu) "open-iscsi shutdown failure due to missing dir" [Undecided,New] https://launchpad.net/bugs/541512
<cjwatson> that seems like the easiest fix
<Riddell> mvo: bug 631708 FYI
<ubottu> Launchpad bug 631708 in software-properties (Ubuntu Lucid) "no way to change distro upgrade prompt policy in KDE UI" [Undecided,New] https://launchpad.net/bugs/631708
<Keybuk> cjwatson: such things are boot critical path
<Keybuk> (anything run in a mounted-* is)
<cjwatson> Keybuk: do you have an alternative suggestion?
<mvo> thanks Riddell
<dupondje> https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/631548 => bluetooth seems completely broken ...
<ubottu> Launchpad bug 631548 in gnome-bluetooth (Ubuntu) "bluetooth-properties crashed with signal 5 in g_object_newv()" [Undecided,New]
<seb128> dupondje, do you have empathy installed?
<seb128> dupondje, it's likely a known issue for users who remove empathy
<dupondje> GLib-GIO-ERROR **: Settings schema 'org.gnome.Bluetooth' is not installed
<seb128> right
<dupondje> ii  empathy                                           2.31.91.1-0ubuntu2                              GNOME multi-protocol chat and call client
<seb128> ls /usr/share/glib-2.0/schemas?
<dupondje> $ ls /usr/share/glib-2.0/schemas
<dupondje> gschemas.compiled                                            org.freedesktop.Telepathy.Logger.gschema.xml  org.gnome.Empathy.gschema.xml  org.gnome.gcalctool.gschema.xml        ubuntu-artwork.gschema.override
<dupondje> org.freedesktop.gstreamer-0.10.default-elements.gschema.xml  org.gnome.brasero.gschema.xml                 org.gnome.Evince.gschema.xml   org.gnome.Nautilus.Sendto.gschema.xml
<seb128> oh, I didn't get that update yet
<seb128> sorry I was confusing with another bug
<seb128> dupondje, we will fix it
<dupondje> lets hope :) cause I see bluetooth crashes quite some time :)
<Chipaca> apachelogger: ping
<dupondje> thanks for the fast fix seb128  :)
<dupondje> it works, but another thing in the properties view: 'Cannot start 'File sharing'-preferences ... any idea ?
<dupondje> also https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/630543 :) but thats not a big issue
<ubottu> Launchpad bug 630543 in gnome-bluetooth (Ubuntu) "bluetooth-applet no longer offers option to turn off bluetooth" [Undecided,New]
<seb128> dupondje, you're welcome
<dupondje> always cool to see such good response :)
<seb128> dupondje, not sure about this one
<seb128> I've seen logs with permissions errors
<seb128> it could be something else in the stack or a linux issue
<seb128> I will check that later
<seb128> gtg for dinner
<seb128> see you ;-)
<dupondje> njoy :)
<goruka> hi guys, i tried out the beta because 10.04 worked poorly for me, and it seems i can't use the nvidia driver with the xorg version that comes with 10.10 beta.. any hints?
<goruka> (nvidia driver says xorg is too new)
<beuno> goruka, try a support channel, #ubuntu+1
<goruka> ah cool, thanks!
<apachelogger> Chipaca: pong
<Chipaca> apachelogger: hi
<Chipaca> apachelogger: well... I said it as a comment on #375145, dunno if you've read it yet
<Chipaca> apachelogger: but: sorry to read your comment there. Sad that it probably means we're not getting u1 in kde in m or even close. Sad that we couldn't work together. What went wrong?
<apachelogger> Chipaca: in theory it should be working (except that the ubuntu-sso-client misses a kwallet backend), wasnt able to test because of brokenness in maverick
<apachelogger> what's most importantly missing is a maintainer though
<apachelogger> as for what went wrong: general communication problem && moving target && brokenness now and then
 * apachelogger would be happy to chat about that at UDS, if he gets sponsored that is ^^
<ricotz> slangasek, hello, could you have a look at https://bugs.edge.launchpad.net/ubuntu/+source/lxc/+bug/630030
<ubottu> Launchpad bug 630030 in lxc (Ubuntu) "Sync lxc 0.7.2-1 (universe) from Debian unstable (main)" [Undecided,New]
<flixil> Hello. I'm trying to mix branches of software like I used to do in debian. I'm using lucid and I'm trying to mix with the newest in maverik but I cannot access them change lucid for maverik in /etc/apt/sources.list   What is the name I should use?
<flixil> Thanks
<flixil> Oh shit sorry I mispelled maverik and it's maverick. Now it works :)
<YokoZar> Blast, dput via sftp is throwing an exception and I can't upload a new ia32-libs
<cjwatson> try ftp
<YokoZar> cjwatson: doesn't work for ia32-libs on my internet connection
<YokoZar> I think I figured it out it was a bad dput.cf  because the launchpad blog instructions were missing a step ;)
<YokoZar> need to change "incoming = /" to "incoming = ubuntu"
<YokoZar> which I believe doesn't break ftp, so it would be a nice default
<Laney> YokoZar: is it "Exception AttributeError: "'NoneType' object has no attribute 'close'" in <function terminate at 0x2695938> ignored"?
<YokoZar> Laney: Yup
<Laney> I get that with every upload
<YokoZar> Laney: just after "open failed"
<Laney> but they still work
<YokoZar> Laney: I think the "open failed" part is more important
<Laney> yes, likely
<Laney> I see no other errors
<YokoZar> Laney: hmm good to know the exception is unrelated to the open failure I suppose
<TheMuso> ogra: I have other pulse changes to make, so sure I'll get it in.
<mwhudson> hi, i've found a packaging bug that's been inherited from debian
<mwhudson> should i report it to bugs.debian.org as well as launchpad?
<lifeless> yes
<mwhudson> does the package importer import uploads from sid?
<mwhudson> or just squeese?
<cjwatson> both
 * mwhudson urlhacks
<cjwatson> code.launchpad.net/debian/+source/PKG should link to them
<mwhudson> cjwatson: actually no, https://code.edge.launchpad.net/debian/+source/python-defaults hides the sid branch a bit
<cjwatson> well, link to something that links to it
<mwhudson> yeah
<cjwatson> that presentation is a bit of a bug anyway
<mwhudson> it probably works ok for ubuntu
<cjwatson> given that sid is the principal upload target for Debian developers, and the principal source for Ubuntu merges
<cjwatson> it's wrong both ways
<cjwatson> it was OK briefly in lucid when we were doing most of our merging from testing
<cjwatson> but the rest of the time we merge from unstable, and certainly want to know what's going on in unstable
<cjwatson> the problem is that LP really doesn't model testing/unstable particularly well, I suppose
<mwhudson> cjwatson: i meant code.launchpad.net/ubuntu/+source/PKG is probably ok
<cjwatson> right
<mwhudson> but yeah, launchpad models ubuntu ok and debian poorly
<cjwatson> I realised that partway through but reckoned what I said still made sense more or less :)
<mwhudson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595826 fwiw
<ubottu> Debian bug 595826 in python-minimal "python-minimal postinst script should specify complete python path" [Important,Open]
#ubuntu-devel 2010-09-07
<highvoltage> does Unity have an upstream website (or web page) currently?
<persia> highvoltage, apt-cache show points at https://launchpad.net/unity
<highvoltage> persia: I saw that, not quite marketingy enough, but I guess it will do :)
<persia> Maybe ask the ayatana folk?
<beuno> highvoltage, there is no other page than the launchpad one
 * beuno waves at persia 
<highvoltage> thanks, beuno
<persia> hey beuno
<persia> There's the announcement press release, and video of some presentations, if one is desperate :)
<dholbach> good morning
<ion> hi
<dylan-m> good night :P
<dholbach> night dylan-m! :)
<asacv> guys ... wget with http proxy does not work in lucid?
<asacv> i have env set ... even tried tweaking /etc/wgetrc
<asacv> wget -> fails to resolv host ... curl works -> debootstrap fails
<dholbach> asac, in some cases I found that HTTP_PROXY vs http_proxy makes a difference
<asac> hmm ... let me try dholbach
<asac> nope
<asac> how can such a basic feature be broken :)
<quadrispro> hi guys
<quadrispro> any main's sponsor around?
<quadrispro> bug #625327 needs a bit of love
<ubottu> Launchpad bug 625327 in libmtp (Ubuntu) "Sync libmtp (main) 1.0.3-4 from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/625327
<soren> quadrispro: I just put an ACK in the comments, unsubscribe main sponsors, and subscribe ubuntu-archive, right?
<quadrispro> soren, yes, it is
<soren> quadrispro: done.
<quadrispro> thanks soren !
<soren> quadrispro: Sure.
<quadrispro> soren, you should set mark it "Confirmed", I think
<quadrispro> s/set//
 * soren does so
 * quadrispro thinks soren rocks
<cjwatson> lool: linaro-image-tools depends on uuidgen-runtime, which isn't in the archive.  Was that meant to be uuid-runtime?
<cjwatson> lool: and why the explicit dependencies on Essential util-linux, e2fsprogs, and coreutils?
<ogra_cmpc> smells like someone copied the jasper deps
<ogra_cmpc> iircd linaro used jasper in the very beginning
<ogra_cmpc> -d
<ogra_cmpc> i guess thats a leftover ... when they stopped using jasper that wasnt cleaned up (jasper needs these deps to resize the rootfs on first boot)
<lool> cjwatson: Crap, I fixed the deps in the shell script but not in control; sorry about that
<lool> cjwatson: Fixing that now
<cjwatson> if jasper has the same, then it is buggy too ...
<cjwatson> lool: thanks
<lool> I didn't think of checking whether any where Essential
<cjwatson> jasper has uuid-runtime not uuidgen-runtime; and it has versioned dependencies on the Essential packages, which exempts it from the lintian check
<cjwatson> so no, not obviously a copy of jasper
<soren> I always forget.. Is it only essential packages that don't need to depended on or can I skip required packages, too?
<cjwatson> only essential
<lool> We never used jasper, it's not from jasper it's from the ensure_command line in the linaro-media-create script
<soren> cjwatson: Thanks. Do you happen to know the rationale for this? Perhaps that'll help me remember.
<cjwatson> required packages are removable without complaint
<soren> cjwatson: I see.
<cjwatson> also, Priority: required is the transitive closure of Essential, including shared library packages which it's usually easy to remember that you have to depend on
<cjwatson> actually, I think strictly the transitive closure under Depends of Essential is a subset of Priority: required, but anyway
<cjwatson> also, there's a footnote in the policy manual about why depends are omitted on Essential, which may be a useful alternative way to think about it
<cjwatson> http://www.debian.org/doc/debian-policy/footnotes.html#f8
<ogra_cmpc> lool, asac used jasper for quite some time
<ogra_cmpc> lool, for the jasper setup scripts to avoid duplication
<ogra_cmpc> (not for the resize stuff)
<soren> cjwatson: Thanks! That's very helpful.
<lool> cjwatson: I have an upload ready, but I need to sort out some bzr stuff before I push it; will upload later today when james_w is up
<cjwatson> ok
<cjwatson> kirkland: could eucalyptus be reuploaded to use libavahi-core7-udeb, so that we can NBS out libavahi-core6-udeb?
<soren> We've attempted to use udd for working on libvirt. I think we may have done it wrong... So, we checked out lp:ubuntu/libvirt. Hacked on it, used dch to update the changelog, debcommit to commit changes as we went along.. Eventually, I ran dch --release, debcommit --release, bzr bd -S and uploaded.
<soren> ..but once the upload was processed and imported, the branch we were working on got moved out of the way and a pristine one was put in its place.
<soren> ("pristine" as in "consisting exlusively of stuff put there by the importer")
<soren> Am I supposed to merge the two and push?
<soren> I tried looking at wiki.u.c/DistributedDevelopment/Documentation/, but I didn't feel any smarter afterwards.
<soren> Oh!
<cjwatson> this usually happens if the tag is not what it expected
 * soren just spotted the merge proposal.
<cjwatson> sometimes the right thing to do is to push --overwrite the branch you wanted, if the import doesn't add anything new, but do check things like tags carefully
<cjwatson> and possibly check with james_w :-)
<soren> cjwatson: I guessed it might be a tag mismatch, but I tried "bzr mark-uploaded" on my local branch, and it said it was already tagged.
<soren> cjwatson: Hm... This seems like it's my fault, actually. There's a diff between the two.
 * soren didn't think that was possible when using "bzr bd -S" to build the source package.
<cjwatson> soren: mm.  I must say that I generally build the source package *then* commit+tag, just in case.
<soren> cjwatson: I /may/ have done that.
<cjwatson> you should be able to merge the imported branch into your more detailed branch, and push that.  (Doing it that way round may result in a more obvious history.)
<soren> cjwatson: Anyways, the problem turned out to be a file that was added.
<soren> cjwatson: The importer gave it one id, my local branch gave it another => conflict.
<soren> Exact same name, exact same contents.
<cjwatson> you may want to check with james_w, then; that sounds like an importer bug
<soren> That's the plan when he turns up :)
<Riddell> alf__, slangasek: what's the status of qt4-qws ?
<alf__> Riddell: Hi! Current plan is to have it in PPA for this cycle. We are also in contact with upstream so that for Lighthouse they will hopefully have a different soname for the UI libs and all other libraries are the same.
<Riddell> hmm ok, I'll reject it from new queue
<alf__> Riddell: wasn't it already rejected? :)
<Riddell> alf__: yes, and re-uploaded
<alf__> Riddell: hmm, I wasn't aware of that, can you give me a minute to see what is going on?
<Riddell> alf__: I reuploaded it because asac still wanted it in the archive
<alf__> Riddell: ok, feel free to remove it, thanks!
<lool> cjwatson: Pushed new linaro-image-tools (0.2) fixing the deps; sorry about that
<cjwatson> that's ok
<mdz> cjwatson, Keybuk, sabdfl, TB in 5, agenda is up at https://wiki.ubuntu.com/TechnicalBoardAgenda
<Keybuk> cjwatson: I got your e-mail about Plymouth, but my peril-sensitive glasses engaged when I tried to read it
<smoser> cjwatson, i'm looking at bug 632096 (the bug i opened to modify euca to use grub rescue images rather than grub-mk-rescue).
<ubottu> Launchpad bug 632096 in eucalyptus (Ubuntu) "eucalyptus-nc is missing dependency on grub-pc" [Undecided,New] https://launchpad.net/bugs/632096
<smoser> i'm looking at grub-mkrescue, and it uses '--embedded-boot' of 'boot.img', which is not in the iso9660 filesystem itself. i'm not sure if i absolutely need it or not, but I don't see a way to get it via isoinfo.
<cjwatson> smoser: you don't need it if all you need is the equivalent of core.img
<smoser> well i need to build a booting iso, (or floppy). I'd prefer ISO, just because i can kind of invision the loader being larger than would fit into my floppy.
<smoser> so, sorry to be ignorant, but all i know is coming from man pages and the grub-* scripts.
<cjwatson> you don't need it for CD booting either
<cjwatson> /boot/grub/i386-pc/eltorito.img in the image is fine for that
<cjwatson> the --embedded-boot stuff is for the purpose of creating a hybrid CD/USB/floppy image
<smoser> well, that is ideal for me... the stuff i currently have would make a cdrom just as it would make a floppy, the only difference is the floppy gets the size set to 2880K.
<smoser> if i have to live with making a floppy one way (using core.img) and cdrom another, then i can, it just seemed nicer with the hyprid.
<smoser> am i sort of stuck with that ?
<cjwatson> I think you probably are for now, sorry
<smoser> thank you cjwatson
<tkamppeter> Anyone can help me with an update problem? Bug 631617? How have the Conflicts/Replaces/Provides on foomatic-db and foomatic-db-compressed-ppds to be set so that an update from Lucid (or older) to Maverick works?
<ubottu> Launchpad bug 631617 in update-manager (Ubuntu) "Can't update to 10.10 beta from ubuntu 10.04 LTS with kubuntu-desktop" [High,Triaged] https://launchpad.net/bugs/631617
<Riddell> tkamppeter: let me look
<Riddell> tkamppeter: I think I fixed that yesterday by removing hpijs-ppds, ijsgutenprint and foomatic-db-gutenprint from the kubuntu seeds
<Riddell> tkamppeter: does that sound like the right thing to have done?
<tkamppeter> Riddell, yes, these three packages should really not be in any seeds.
<Riddell> tkamppeter: great, I'll close the bug
<cjwatson> Riddell: the user says ubuntu-desktop, not kubuntu-desktop, so I don't understand how a change in kubuntu-desktop could have helped
<cjwatson> perhaps mvo needs to look at this one
<Riddell> the bug title says kubuntu-desktop
<cjwatson> the log says: 2010-09-06 16:17:13,123 ERROR Dist-upgrade failed: 'Can not mark 'ubuntu-desktop' for upgrade'
<cjwatson> although kubuntu-desktop appears to also be installed
<mvo> I have a look
<cjwatson> ibus-pinyin was also broken, which I believe to be fixed now
<cjwatson> and python-mako
<cjwatson> (likewise)
<cjwatson> so I'm sure those weren't helping
<jibel> cjwatson, the problem was that kubuntu-desktop and ubuntu-desktop were both installed, that k-desktop wants to upgrade foomatic-db and u-desktop wants to install foomatic-db-compressed-ppds which both conflicts.
<jibel> cjwatson, I've just tried in a VM and foomatic-db is now removed and replaced by foomatic-db-compressed-ppds.
<tkamppeter> jibel, Riddell, cjwatson thanks.
<mvo> jibel: nice, thanks a bunch
<cjwatson> jibel: yay
<Keybuk> huh, there's a Mumble client for iPhone in their GIT repo
<cjwatson> james_w`: I may have said this before, but remind me to buy you a drink for sync-helper.py at some point
<cjwatson> StevenK: ... and you, since I just noticed you wrote it to start with and apparently I'd been misattributing it.  sorry!
<james_w`> cjwatson: much easier isn't it?
<cjwatson> looks like both
<cjwatson> yeah, I'm trying to get into the habit of just doing them daily
<Keybuk> kk, let's see whether this builds
<StevenK> cjwatson: It's both, I started it, james_w` made it better.
<Daviey> Hi, would an AA be able to publish eucalyptus 1.6.2-0ubuntu30.4 to proposed?
<lamont> how in the hell do I get Network Mangler to quit editing /etc/hosts?
<mycae> Hello. I am having some problems with cowbuilder (lucid).  I am getting "Package cowdancer is not available, but is referred to by another package"
<mycae> This appears to have happened to a couple of other users, but I can't find the solution.
<mycae> http://irclogs.ubuntu.com/2010/04/30/%23ubuntu-devel.html
<tyarusso> mycae: cowdancer appears to be in universe.
<mycae> but universe is in my /etc/sources.list.
<mycae> I have lucid-backports enabled -- could this be causing it?
<tyarusso> Maybe, but I kind of doubt it.  What's the relevant section of the logs page you posted?
<mycae> search for either "cowdancer" or "kkszysiu"
<tyarusso> um, not found...
<mycae> kkszysiu logs on and has the same question; however I cannot figure out if he actually resolved it or not.
<tyarusso> sure you got the right link?
<mycae> http://irclogs.ubuntu.com/2010/04/29/%23ubuntu-devel.html
<mycae> I just cut and pasted that from firefox
<tyarusso> You had /30 before :)
<mycae> ah
<mycae> yes, i was wondering if it rolled over to the next day.
<tyarusso> mycae: It looks like the answers consist of a) check which sources are defined *within* cowbuilder, and b) make sure you know how to use cowbuilder - xnox walks through a few steps.
<mycae> I use cowbuilder under debian, but its usually rather automagic.
<mycae> ok, so missing pbuilderrc appears to have been the candidate. Maybe I should file a bug in cowbuilder.
<mycae> not the most obvious error  :(
<Iraqi> ...................Ubuntu Version ...............10.10................beta ...... Is NOT support support HP Pavilion tx2645ee.... When running is west side not showing image correct I think this menu side so no thing see it and Auto restart so ................. bye bye
<mterry> lool, asac, doko: Heyo, fellow MIRers.  Looking for guidance on bug 527142, starting around comment #11.  I'm inclined just to approve, as the server team will hopefully be on top of any library changes...
<ubottu> Launchpad bug 527142 in cluster-glue (Ubuntu) "[MIR] cluster-glue" [Undecided,Incomplete] https://launchpad.net/bugs/527142
<manjo> superm1, I was planning on returning your port replicator today
<superm1> manjo, i'm here, feel free to swing by
<superm1> hopefully you got some good results from it?
<manjo> superm1, you mentioned in your email that you were not able to boot the 6410 ?
<superm1> manjo, no i wasn't, i can show you in person here when you come by
<manjo> hmmm I was able to boot the 6510 with those boot options .. not sure what is going on
<superm1> might be a little different of a problem on the 6410
<manjo> you get the same panic ?
<superm1> i dunno, i don't have a port replicator to see with the options :)
<manjo> :) ah
<manjo> superm1, I will be there @4 is that ok ?
<superm1> yeah that should be fine, my evening plans were foiled by this rain, so i'll be around for a few extra hours
<manjo> superm1, I am booting todays amd64 iso, but getting buffer io err on dev sr0 ... so looking into what is going on
<manjo> superm1, do you have any important info on this laptop? can I erase the HDD ?
<superm1> manjo, feel free
<manjo> ok
<superm1> i think today's ISO should have a lot of the grub-installer fixes and partman fixes that cjwatson put together last week too, so you might be able to get through a full install now
<manjo> yeah we did a lot of back and forth on installer last week and he emailed me saying todays iso should have those fixes he worked on
<manjo> superm1, ok installing on your laptop with UEFI disk
<manjo> keeping fingers cross that all the issues have been resolved wrt to grub-installer & partman
<lool> mterry: Commented in the bug
<manjo> hopefully cjwatson fixed all uefi install issues :)
<superm1> manjo, if i remember right that should be the discrete model too, so you might be able to find out if there are issues with nvidia gfx driver and having no vbios after install too
<manjo> great :)
<mterry> lool, thanks, reading
<manjo> cjwatson, superm1 failed to install grub-efi package failed to install into /target/
<mneptok> hrmf. an upgrade on x86-64 Karmic complains about lftp not being in the repos.
<manjo> cjwatson, bug 632642 opened for grub-efi not able to install on /target/
<ubottu> Launchpad bug 632642 in grub2 (Ubuntu) "[MAVERICK] Dell 6510 - grub-efi package failed to install into /target/" [High,New] https://launchpad.net/bugs/632642
<manjo> superm1, ^
<tkamppeter> Ridell, ping
<tkamppeter> Riddell, ping
<superm1> manjo, what's up with all those intel ips errors in the logs?  i was seeing that on another system too
<superm1> stuff like intel ips 0000:00:1f.6: MCP power or thermal limit exceeded
<manjo> superm1, looking ...
<manjo> superm1, can I keep the 6510 for this week ?
<manjo> superm1, I will return the port replicator @4
<superm1> manjo, either that or we can trade 6410 for 6510, we can discuss when you swing by
<manjo> superm1, ack
<superm1> manjo, http://pastebin.com/EjnxcBMv might get you fully installed (it's a dirty hack, it looks like there is a depends/conflicts/replaces problem with grub-efi otherwise)
<superm1> if you apply it to /usr/share/grub-installer/grub-installer before ubiquity gets to the phase it runs  grub-installer
<manjo> superm1, super, let me try that ...
<smoser> cjwatson, i would guess you're not around, is that correct ?
<manjo> smoser, no I think.. I pinged him earlier with no response
<smoser> its like its 11:00 pm for him or something, and he doesn't think he should be working :)
<manjo> yep go figure!
<manjo> superm1, looks like that hack worked
<superm1> manjo, as in the install finished, or it boots?
<manjo> superm1, its past the grub installer
<superm1> ah cool
<manjo> superm1, now waiting on "installing system"
<manjo> superm1, install done
<manjo> superm1, heh does nothing on reboot, blank screen ...
<manjo> superm1, error: unknown filesystem.
<manjo> grub rescue>
<superm1> i think the prefix is getting set wrong, i just saw that same thing on another system that can actually boot using noexec=off
<superm1> because the prefix seems to be set to (hd1,gpt1)/boot/grub, when it should actually be (hd1,gpt2)/boot/grub
<superm1> and root is set to hd1,gpt1, when it should be hd1,gpt2
<manjo> can I fix that on the fly ?
<superm1> maybe, manually reseting the variables might work, but i think it then needs to still parse the right configuration file
<manjo> superm1, can you add these comments to http://launchpad.net./bugs/632642
<ubottu> Launchpad bug 632642 in grub2 (Ubuntu) "[MAVERICK] Dell 6510 - grub-efi package failed to install into /target/" [High,New]
<superm1> well this part is probably a separate bug
<superm1> but i'll mention it
<manjo> ok
<EagleScreen> is it necessary to have four entries for memtest in maverick?
<EagleScreen> I think this will confuse people
<Riddell> tkamppeter: pong
<EagleScreen> four entries in grub
<tkamppeter> Riddell, it is about bug 631617: In comment #10 tarekeldeeb tells that he gets "E: Couldn't find package foomatic-compressed-ppds". The package I have named foomatic-db-compressed-ppds, can it be that you have mistyped in a seed?
<ubottu> Launchpad bug 631617 in update-manager (Ubuntu) "Can't update to 10.10 beta from ubuntu 10.04 LTS with kubuntu-desktop" [High,Fix released] https://launchpad.net/bugs/631617
<Riddell> tkamppeter: there's no printing bits in the kubuntu seeds directly now, only in the common platform.maverick/desktop-common seeds
<Riddell> tkamppeter: I think it's more likely he mistyped it
<Riddell> tkamppeter: there's no rdepends for foomatic-compressed-ppds
<tkamppeter> Riddell, thank you, I have added a comment to the bug now.
<SpamapS> hrm, if using bzr-buildpackage on a native package, shouldn't it skip the part about getting a .orig tarball?
<james_w`> SpamapS: yes
<SpamapS> ah, --native
<james_w`> SpamapS: mkdir - p .bzr-builddeb/ && echo -e "[BUILDDEB]/nnative = True" > .bzr-builddeb/default.conf && bzr add .bzr-builddeb/default.conf
<SpamapS> james_w`: I'd say native packags are the exception, not the rule, so I don't mind remembering to do --native for this one package. :)
<james_w`> SpamapS: that's per-package
<SpamapS> right now I see that
<SpamapS> james_w`: couldn't you just read debian/source/format ?
<james_w`> SpamapS: yes
<SpamapS> want a wishlist bug as a reminder? ;)
<james_w`> bug 586617
<ubottu> Launchpad bug 586617 in bzr-builddeb "use debian/source/format to figure out if package is native" [Medium,Triaged] https://launchpad.net/bugs/586617
<SpamapS> sweet
<james_w`> have one thanks ;-)
<SpamapS> james_w`: have I thanked you for bzr-builddeb lately btw? ;)
<SpamapS> if not.. thanks :)
<james_w`> I take complaints as thanks, it makes things easier ;-)
<SpamapS> how very orwellian of you
<Riddell> YokoZar: I see you're into Wine, are you going to fix bug 621694 ?
<ubottu> Launchpad bug 621694 in wine1.0 (Ubuntu Maverick) "Faulty dependencies." [Undecided,Triaged] https://launchpad.net/bugs/621694
 * micahg thought YokoZar was Wine in Ubuntu
#ubuntu-devel 2010-09-08
<cjwatson> superm1: as you say, the prefix problem should be a separate bug
<persia> lamont, Thanks for trying the fpc/armel bootstrap again.  Do you have any recommendations on how we could ensure that the test-builds match your experiences on the buildds?
<cjwatson> manjo: could you please test the server CD in preference to the desktop CD right now?
<cjwatson> I think I've asked this before
<manjo> cjwatson, yep... I was tring to get the desktop installed coz I had something else I needed to do wrt drm ...
<cjwatson> manjo: it's harder to get the desktop CD to work in general, and while it does need to happen and I welcome the bug reports, given time constraints it's essential to address the shorter critical path for the server CD
<cjwatson> this is not me trying to dodge your reports, but I really want to know whether the fixes I've made so far are sufficient for server
<manjo> cjwatson, ack
<manjo> cjwatson, will do it and comment on the bug report ... is that ok ?
<manjo> cjwatson, was going to grab a quick dinner with wife atm
<manjo> cjwatson, do I need to use that hack that I posted on the bug report ?
<manjo> ie if that fails on normal install
<cjwatson> not for d-i-based installations, no
<manjo> ok
<superm1> cjwatson, on maverick, actually just trying to apt-get install grub-efi runs into that same problems
<cjwatson> superm1: do you have grub-pc installed on the same system?
<superm1> cjwatson, well i was just trying from a live disk, so yes, it's installed already
<cjwatson> indeed.  they conflict
<cjwatson> ubiquity needs to take special care to deal with that
<cjwatson> cf. bug 349835 and bug 353273, which you may remember - essentially the same thing I think
<ubottu> Launchpad bug 349835 in ubiquity (Ubuntu) "Preseeding grub2 causes ubiquity installation to fail" [Undecided,Fix released] https://launchpad.net/bugs/349835
<ubottu> Launchpad bug 353273 in ubiquity (Ubuntu) "Ubiquity crashes when trying to preseed grub2 instead of grub" [High,Fix released] https://launchpad.net/bugs/353273
<superm1> oh yeah, i do recall those
<cjwatson> I think it's fixable in much the same way, but will fake up a test environment for it before committing anything
<manjo> cjohnston, installing server right now, 90% done (and angry wife)
<manjo> cjwatson, ^
<cjohnston> no love :-(
<manjo> cjohnston, I keep typing your nick sorry
<manjo> cjohnston, hitting tabs :)
<cjwatson> type one extra letter before the tab ;-)
<sbeattie> mathiaz: in your last upload/merge of whois, you seem to have managed to lose the separate mkpasswd package, without a conflicts/replaces.
<manjo> yep need to practice 3 letters + tab
<cjwatson> sbeattie: seems to be the same in Debian
<sbeattie> cjwatson: the mkpasswd bit I think was an ubuntu-specific change.
<sbeattie> (mkpasswd as a separate package)
<cjwatson> ah
<YokoZar> Riddell: Yeah I got a whole host to tackle
<sbeattie> It got separated out sometime in the lucid cycle, and is published that way; thus people upgrading from lucid that have mkpasswd get an install failure.
 * sbeattie goes to file a bug.
<manjo> cjwatson, server install is complete ... but cannot boot from HDD... error: unknown filesystem grub rescue>
<manjo> cjwatson, but I need to run, keep wife happy
<cjwatson> ok, that'll be the same as the desktop one.  could I have a separate bug for that when you have a moment?
<cjwatson> (and that one *does* belong on grub2)
<manjo> cjwatson, will do when I head back from dinner
<superm1> cjwatson, i already split it up, bug 632775
<ubottu> Launchpad bug 632775 in grub2 (Ubuntu) "grub-install (EFI) is not properly setting the prefix" [Undecided,New] https://launchpad.net/bugs/632775
<cjwatson> ah right
<cjwatson> thanks
<superm1> sure np
<manjo> cjwatson, so add to that bug ?
<cjwatson> if you have anything new to add, sure
<cjwatson> logs would be good
<manjo> ok.. nothing new ...
<manjo> heading out... laters
<cjwatson> well, there are no logs in that bug right now
<cjwatson> if you have logs, that would be new
<cjwatson> (from an install that wasn't having grub-efi installation problems)
<manjo> yep
<cjwatson> it's not obvious from the grub-install code :(
<cjwatson> oh, duh, I guess I know
<cjwatson> I think this is going to need something a bit like http://bazaar.launchpad.net/~vcs-imports/grub/grub2-bzr/revision/2465, only for EFI
<cjwatson> specifically the bit that handles a partition-only prefix "drive"
<cjwatson> the alternative is hardcoding the entire prefix device, which is seriously undesirable
<cjwatson> then the EFI grub-install will have to find the partition number for /boot/grub and hardcode that but make sure to leave out the drive
<sbeattie> mathiaz: the whois bug is bug 632791, for the record.
<ubottu> Launchpad bug 632791 in whois (Ubuntu) "upgrade fails: trying to overwrite '/usr/bin/mkpasswd', which is also in package mkpasswd 5.0.6ubuntu1" [Undecided,New] https://launchpad.net/bugs/632791
<superm1> cjwatson, what would be the problem with something simpler like http://pastebin.com/tYSjjyXN ?  that way you are just searching for the right UUID without having to hardcode drive or partition number, just letting serach.fs_uuid find it. is the worry boot delay then?
<cjwatson> superm1: it's good to avoid UUID searching (which is slow and requires embedding a configuration file) if possible, yes
<cjwatson> pastebin.com is slow
<cjwatson> probably all the junk in its framing
<cjwatson> if /efi and /boot/grub are on the same drive, then we can make use of the fact that EFI has a call to retrieve a device handle for the loaded image (i.e. GRUB itself)
<cjwatson> which tells us the drive and then we just need to fill in the right partition number
<superm1> ooh pastebinit does work with paste.ubuntu.com, i'll just use that instead from now on
<cjwatson> something like http://paste.ubuntu.com/490082/ (against upstream so paths are a bit different) in combination with a change to grub-install
<superm1> ah i see
<cjwatson> probably something like http://paste.ubuntu.com/490089/, all this totally untested
<cjwatson> extra comma in the grub_partition sed
<cjwatson> 's/^[^,]*,//; s/)$//'
<cjwatson> anyway, that should be the structure of it - but bedtime for me
<lamont> persia: there's a tarball on kakadu in my home directory... that and a bbg3 board should be sufficient for reproducing things
 * persia renews the wish that any of the available imx51 HW was based on that revision of the babbage.
<lamont> yeah.
<lamont> anyway, sleep for me.
<mwhudson> persia: can you explain babbage board versions to me?
<mwhudson> i've googled and completely don't understand the few things i find :)
<persia> mwhudson, Note that the following is gleaned from a variety of hearsay.  it is likely to be incomplete, and may well be inaccurate.
<mwhudson> persia: noted
<persia> My understanding is that there were several revisions of a reference board produced by freescale.
<persia> some of these were released to customers and partners, as bbg 1.0, 2.0, 2.5, 3.0, possibly more.
<persia> I think there were even two different versions of bbg 1.0, although I'm less sure of that.
<persia> I know of two devices in current retail that appear to be based on these reference designs: the Sharp Netwalker and the Genesi Efika.MX
<mwhudson> ah ok, so they were never sold to random passers by in the same way that say the beagle is?
<persia> I believe the Netwalker was based on 2.0 and the Efika.MX was based on 2.5, but that's as much of a guess as any surety.
<mwhudson> and they're all based on imx.51 chips right?
<persia> Freescale has also announced a development program, such that certain folks can purchase a bbg 3.0 at a price roughly equialent to a Netwalker + an Efika.MX.
<mwhudson> (is that a chip or a chip family)
<persia> But I've heard rumours of availability issues there.
<persia> Yes, they are all versions of a reference motherboard for the i.MX51 SoC.
<mwhudson> ok
<mwhudson> are i.mx51s particularly nice in some way?
<persia> The beagle is kinda special: Ti helped design a reference board, but the board design is open, so anyone can make them and sell them.  I don't believe TI actually sells them directly.
<persia> i.MX51x is a chip family, I think.  I don't know the disctinctions between versions.  Could be revisions, could be extensions, etc.  Unlikely to make a difference running Ubuntu, as we have little to no software that would take advantage of extensions.
<persia> The i.MX51x series is particularly nice in a number of ways, and insufficient in a number of other ways.  I'd have to recommend comparing Freescale's datasheets with those of some of their competitors.
<mwhudson> http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=IMX51_FAMILY actually seems *reasonably* helpful on that front
<persia> But that gets into the same sort of mess that one hits in comparing, say, Freescale powerpc vs. IBM powerpc, or AMD vs VIA for IA32.
<mwhudson> it seems that you'd mostly likely be running ubuntu on a 515
<mwhudson> persia: weeeeeeeeeeeeeell the fact that it's a SoC does make some difference there?
<mwhudson> though i guess intel and amd use different socket
<mwhudson> s
<persia> Kinda, sorta.
<persia> So it's comparison of CPU+chipset+some peripherals vs. just CPU+socket (with chipset competition per-socket)
<mwhudson> mm
<persia> So more like powerpc than IA32, just because the powerpc market has similar tendencies towards vertical consolidation.
<mwhudson> ok, anyway, i have sucked up a little bit more (noted as possibly inaccurate) information, thanks
<mwhudson> right
<persia> So, today, if you want an ARM device, your choices are limited to beagle (low specs), the imx51 devices noted above (note that there is currently no imx51 kernel in Ubuntu), or some other devices that run Android which could conceivably be hacked to run Ubuntu.
<mwhudson> was it the i.mx51 series that had some earlier versions that had bugs in their neon support?
<persia> My recommendation is to wait, unless you're up for kernel maintenance.
<mwhudson> well
<mwhudson> i'm getting a beagle xm in the mail soon :)
<persia> I heard something about that, but I think there was a kernel patch that made it less bad.  I'm unsure.
<mwhudson> ok
<persia> beagle XM isn't bad, just be aware it's a low-spec platform :)  Makes a handy project box, server, very lightweight client, etc.
<mwhudson> yeah, it's just for testing and such
<persia> And you may well find lots more folks with deeper knowledge than I on #ubuntu-arm.  I know I've seen folks from a few SoC vendors and ODMs there, as well as the usual free software folk.
<mwhudson> given that i, you know, work for this organization with an arm focus now
<persia> Heh.  I'm not going to complain about more ports users :)  I just want to be sure folk understand that low-spec devices are low-spec, and that even really cool acceleration stuff and great ISAs don't completely make up for 512MB RAM and relatively slow clocks.
<persia> Especially because I keep hearing about devices that will be released "Real Soon Now" that don't have those limitations.  1GB+, 1GHz+, etc.  Mind you, I've been hearing that for well over a year now.
<mwhudson> even *i've* been hearing that for a few months
<nigelb> lucidfox: I'm having a busy day, but I just dropped by to say: AWESOME blog post!
<lucidfox> nigelb> Thanks!
<vish> lucidfox: you should have ended it with "Based on a real life story!" :D
<lucidfox> vish> Hehehe
<lucidfox> I don't generally like naming and shaming, though
<vish> lucidfox: yup.. but me having watched the whole events transpire from beginning to end .. it was really pretty well written ;)
<chrisccoulson> is there anybody available who knows about the process for creating language packs (specifically how the mozilla translations are imported)?
<chrisccoulson> i need to get bug 632760 fixed
<ubottu> Launchpad bug 632760 in language-pack-pt (Ubuntu) "Language variants don't work in Firefox because the language codes are separated with an underscore rather than a hyphen in chrome.manifest" [High,Triaged] https://launchpad.net/bugs/632760
<micahg> chrisccoulson: are you sure this is a langpack issue and not an upstream one?
<chrisccoulson> micahg - the upstream xpi's use a hyphen
<chrisccoulson> launchpad is mangling them on import
<cjwatson> you might try lp:langpack-o-matic
<chrisccoulson> cjwatson, thanks
<cjwatson> (are you sure it's on import into launchpad, not export into language packs?)
<chrisccoulson> cjwatson, well, i'm not sure really
<chrisccoulson> i still don't know how this stuff works ;)
<cjwatson> noticing things like this in 'import' in lp:langpack-o-matic:
<cjwatson>         locale = tar.split('.')[0].replace('-', '_')
<chrisccoulson> heh :)
 * cjwatson looks at the langpack export
<dpm> chrisccoulson, there is also more background info on http://is.gd/f0syl - Arne used to upload the xpis manually into LP from upstream, and then langpack-o-matic does the rest
<chrisccoulson> dpm, thanks
<theGuest_> good morning everyone! are you guys aware of bug 624251 in gparted?
<ubottu> Launchpad bug 624251 in Baltix "Please sync GParted version 0.6.2 from Debian unstable - current package in Ubuntu 10.10 beta contains 2 important bugs" [Undecided,New] https://launchpad.net/bugs/624251
<cjwatson> theGuest_: sure, I can look at that
<cjwatson> thanks
<theGuest_> cjohnston, thanks!
<theGuest_> cjwatson, hm autocomplete...
<cjwatson> chrisccoulson: I don't think it's on the LP side, since LP just feeds langpack-o-matic .po files
<cjwatson> chrisccoulson: you might try lp:~arnegoetje/rosetta/po2xpi-arne too - I believe that src/rosetta_xpi_to_sources is what langpack-o-matic calls
<cjwatson> chrisccoulson: and there's definitely a bunch of stuff there that's working with chrome.manifest
<chrisccoulson> cjwatson - thanks, just looking there now
<cjwatson> (BTW I have no operator privileges for langpacks - I just conveniently happen to have a login on that machine)
<cjwatson> james_w`: would you mind looking into why the lp:debian/sid/gparted import is out of date?
<Daviey> james_w`, Are you about?
<Daviey> cjwatson, Perhaps you could help if you have a moment... I encountered a deb src 3 issue yesterday. and seems james_w` also discovered it a few weeks ago.  Essentially, it doesn't do what it says on the tin - regarding overriding binaries.  There is a pretty minimal patch that fixes it, what do you think if i were to cherry pick it for Maverick dpkg? http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff_plain;h=4d2b04f
<cjwatson> Daviey: yes, that's fine to cherry-pick
<Daviey> rockin', thanks cjwatson
<doko> seb128: any idea about #632594
<seb128> bug #632594
<ubottu> Launchpad bug 632594 in xorg-server (Ubuntu) "xvfb 1.9 and/or metacity not working on the buildds" [High,Confirmed] https://launchpad.net/bugs/632594
<seb128> no
<seb128> didrocks, ^?
<seb128> not sure who touched it recently but I've no clue about it
<seb128> I'm using compiz for years and never really touched it
<ricotz> seb128, do you have a moment, gssdp and gupnp need a rebuild against g-i 0.9.3
<didrocks> metacity is working here
<didrocks> not sure why buildds have issues
<doko> just want to have a working xvfb again :-/
 * didrocks looks about what changed in metacity
<seb128> could be an xorg issue as well
<seb128> ricotz, no change rebuilds?
<ricotz> seb128, yes, but gupnp could also be synced from debian
<seb128> ok
<seb128> could you open bugs about that?
<didrocks> doko: nothing in metacity from what I can see of, even not change to codebase (just removing some deprecated patch)
<didrocks> last version isn't in bzr. fixing this (but no big change on it too)
<ricotz> seb128, ok, there are 3 more sync request of packages which depend on these two, i hope they make it in too
<seb128> ricotz, can you open one bug and summarize the changes required in it?
<seb128> didrocks, doko: could be an #ubuntu-x issue rather then
<persia> I thought the dbus-not-available-during-builds was a dbus-change.  I can't find it right now, but I thought I remembered an email from Keybuk about it a couple months back.
<ricotz> seb128, i filed these two bugs - https://bugs.edge.launchpad.net/ubuntu/+source/gssdp/+bug/633019 - https://bugs.edge.launchpad.net/ubuntu/+source/gupnp/+bug/633020
<ubottu> Launchpad bug 633019 in gssdp (Ubuntu) "Rebuild against gobject-introspection 0.9.3 needed" [Undecided,New]
<seb128> ricotz, thanks
<seb128> I will deal with those today
<ricotz> seb128, syncing gupnp 0.13.5-1 from debian/experimental might be worth it, very few changes
<seb128> ok
<seb128> I will review those
<bilalakhtar> zul: ping, ping, ping! A major regression!
<bilalakhtar> Bug #626723
<ubottu> Launchpad bug 626723 in apache2 (Ubuntu Maverick) "init script resets isig flag in an incorrect manner" [High,In progress] https://launchpad.net/bugs/626723
<ricotz> seb128, these are the request which depend on these two - https://bugs.edge.launchpad.net/ubuntu/+source/rygel/+bug/630528 - https://bugs.edge.launchpad.net/ubuntu/+source/gupnp-av/+bug/630510 - https://bugs.edge.launchpad.net/ubuntu/+bug/630524
<ubottu> Launchpad bug 630528 in rygel (Ubuntu) "Sync rygel 0.7.7-1 (universe) from Debian experimental (main)" [Undecided,New]
<bilalakhtar> zul: What would be the right way to go? If I go ahead and make that call mild, then bug #582963 will have to be reopened
<ubottu> Launchpad bug 582963 in Ubuntu Server papercuts "SSL pass phrase dialog can't read input" [Medium,Confirmed] https://launchpad.net/bugs/582963
<Daviey> bilalakhtar, zul won't be online for another 1-2 hours.
<Daviey> cjwatson, Are you doing AA work today?
<Daviey> cjwatson, Would you be able to look at the upload to lucid-proposed, eucalyptus 1.6.2-0ubuntu30.4.  The other AA doing today is kirkland.  It's his upload, so might be bad karma for him to ack it himself. :(
<cjwatson> yep, was going to do it last night but ran out of day
<cjwatson> Daviey: duplicate vgextend in util/wrappers.conf - can you confirm that that's harmless?
<Daviey> cjwatson, I believe it's harmless  - it's a whitelist, but if you'd rather be certain i can test it.
<Daviey> I imagine kirkland did test it before uploading.
<cjwatson> no, that's fine, I checked the code and agree it's harmless
<Daviey> great
<cjwatson> accepting
<Daviey> \o/
<Daviey> thanks.
<Daviey> bilalakhtar, Looking at that bug, It would be unfortunate if a fix to an issue the desktop is seeing breaks server.  Would it be possible to see if the isig flag is actually required, it what seems to be stty or plymouth?
<bilalakhtar> Daviey: Well, I have unassigned me
<Daviey> bilalakhtar, Is that from fear of stepping on zul's toes?
<Daviey> bilalakhtar, Ah, guessing you timed out.
<Daviey> bilalakhtar_,, Is that from fear of stepping on zul's toes?
<bilalakhtar_> Daviey: nope!
<Daviey> oh good.
<ricotz> chrisccoulson, hello, i want to propose a sru including this mentioned fix in this bug - https://bugs.edge.launchpad.net/ubuntu/+source/gnome-session/+bug/491940
<ubottu> Launchpad bug 491940 in ltsp (Ubuntu) "Patch for LTSP clients to properly reboot/shutdown" [Undecided,Confirmed]
<ricotz> chrisccoulson, do you had any concerns about this fix?
<chrisccoulson> ricotz, yes
<chrisccoulson> it's wrong for a start
<chrisccoulson> the patch touches the wrong function
<chrisccoulson> (i keep getting asked about this patch btw)
<chrisccoulson> and i don't think it's SRU worthy really
<ricotz> but a patch for this problem is really needed
<ricotz> is there another approach to fix this?
<chrisccoulson> ricotz, see https://bugs.edge.launchpad.net/ubuntu/+source/gnome-session/+bug/491940/comments/11
<ubottu> Launchpad bug 491940 in ltsp (Ubuntu) "Patch for LTSP clients to properly reboot/shutdown" [Undecided,Confirmed]
<chrisccoulson> i've mentioned this a number of time already, and the current patch still hasn't addressed it
<ricotz> i see
<ricotz> chrisccoulson, are you aware if this problem still exists using maverick?
<chrisccoulson> yeah, i suspect it's still an issue in maverick
<ricotz> ok, currently i am using this patch which does its job because without it is quite annoying
<ricotz> thanks
<chrisccoulson> ricotz, the patch doesn't work from the session dialog though (gnome-session-save), as that code path will never be executed
<chrisccoulson> and that applies for anything else in gnome-session that might call the shutdown code
<chrisccoulson> (i'm not sure if there is anything that does that though - i know clients can end the session, but i'm not sure if they can shutdown or not)
<ricotz> chrisccoulson, i am using lucid with the maverick ltsp packages including this patched gnome-session, this makes it possible to use the session-indicator for shutdown/restart/logout
<ricotz> chrisccoulson, i am not near these computers now
<zul> morning
<mkarnicki> Hi guys, I have a puzzle for you, but you can't use gcc/g++ to check that! Use your brains :)
<mkarnicki> int a = 2; char b; b = 'A' + (a-- != 1) ? 0 : 1; // what is the value of a and b after running this
<mkarnicki> Remember, don't use the compiler :)
<G> zul: morning
<cjwatson> kirkland: are you able to boot i386 generic-pae kernels in kvm at the moment?
<cjwatson> (both host and guest are i386)
<cjwatson> trying to figure out what might have regressed
<diwic> Keybuk, or anyone else who is an upstart expert, is it possible to write an upstart job saying "start on (starting rc RUNLEVEL=[06]) and (no pulseaudio processes), i e, to make it start when *both* conditions are fulfilled? https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/592016/comments/20
<ubottu> Launchpad bug 592016 in pulseaudio (Ubuntu Maverick) "[Maverick] Sound is always muted on startup; unmuting makes the volume at lowest level" [High,Confirmed]
<Keybuk> diwic: no, it's not possible
<Keybuk> for a start, you mean "started" rc
<kadu> Hi =]
<diwic> Keybuk, hmm, it says "starting" here, in /etc/init/alsa-mixer-save.conf, is that a bug then?
<kadu> hi everyone
<kadu> i want to getting started to help in development of ubuntu
<kadu> how i can start?
<fagan> kadu: thats in #ubuntu-app-devel
<Keybuk> diwic: no, it's not a bug for alsa-mixer-save
<Keybuk> read "man starting" and "man started"
<ion> fagan: No
<kadu> thx fagan.. sorry
<kadu> i found this irc channel on ubuntu site... thx
<bilalakhtar> Daviey: look at that stty / apache bug again, and see my comment
<diwic> Keybuk, okay, I'll just write a pre-start script that waits for pulseaudio to terminate then
<Keybuk> I do something similar
<Keybuk> look at the plymouth-stop.conf
<Keybuk> err, no, I don't think I mean that one
<Keybuk> hmm, there is one in there somewhere which does a similar "lock out"
<Keybuk> though maybe I never shipped it ;-)
<manjo> cjwatson, I see the fix was commited 2 hrs ago, will it make it in todays server iso?
<cjwatson> manjo: the server ISOs are built before I wake up in the morning
<cjwatson> check the timestamps :)
<cjwatson> nothing I do in a given work day will be there until the next day's server ISO build
<bilalakhtar> robbiew: heh, I saw your comments on that apache bug
<robbiew> :)
<bilalakhtar> robbiew: The bug is not fixed yet, the only thing that has happened is that its workaround has been placed in the archive
<manjo> cjwatson, ack
<robbiew> bilalakhtar: ah, ok...but it's clearly not an upstart bug, right?
<manjo> cjwatson, would be nice if you had the power to kick off the build :)
<bilalakhtar> robbiew: ah no no
<bilalakhtar> robbiew: The bug wasn't even concerning upstart
<bilalakhtar> It was apache coming in between and resetting stty flags
<bilalakhtar> But getting the workaround in means the reopening of bug #582963
<ubottu> Launchpad bug 582963 in apache2 (Ubuntu) "SSL pass phrase dialog can't read input" [High,Triaged] https://launchpad.net/bugs/582963
<cjwatson> manjo: I do, but it's usually better if I put energy into fixing more bugs rather than babysitting manual builds?
<bilalakhtar> robbiew: Did you poke scott to look at it?
<robbiew> bilalakhtar: yep ;)
<manjo> cjwatson, :) yep
<cjwatson> I normally only run manual builds around release times or when something has failed
<robbiew> more like nudged
<robbiew> heh
<bilalakhtar> robbiew: tell him its fixed
<robbiew> I did ;)
<bilalakhtar> well I found the workaround after hours of digging
<bilalakhtar> and if I knew zul was going to apply the workaround directly, then I wouldn't have waited for him to fix it!
<bilalakhtar> robbiew: ^
<robbiew> bilalakhtar: lol
<Keybuk> bilalakhtar: apache should use plymouth to ask for the SSL passphrase, surely?
<bilalakhtar> Keybuk: hey!
<cjwatson> ttx: I'm looking at the lvm2 package, and trying to decide whether I want to ask for an FFE to pull in a new upstream version
<bilalakhtar> Keybuk: yes it should
<bilalakhtar> robbiew: Keybuk: I will be off
<cjwatson> ttx: the main thing, really, is a fix for bug 621951 - I *think* I may be able to take that in isolation, though I'm not certain
<ubottu> Launchpad bug 621951 in lvm2 (Ubuntu Maverick) "udevd-work[674]: kernel-provided name 'dm-5' and NAME= 'mapper/main-server1a--lu cid-cow' disagree, please use SYMLINK+= or change the kernel to provide the prop er name " [Medium,Triaged] https://launchpad.net/bugs/621951
<cjwatson> ttx: there are a bunch of fixes listed in the upstream WHATS_NEW file, but all sorts of other stuff as well.  I feel bad about our lvm2 version being rather old, but at this point I'm leaning towards backporting just the udev rule patch and doing a proper job of it in natty, rather than risking breaking eucalyptus or something insanely complicated a few weeks from release.  Do you agree?
<ttx> cjwatson: agreed.
<ttx> lvm2 is something I'd rather touch in alphas
<ttx> cjwatson: so if that fix can be isolated, I think that would be the way to go
<SpamapS> ttx: I'm still a little bit confused as to what to do about the mysql kill -9 bug
<SpamapS> ttx: we need to establish a standard place for admins to look when an upstart service doesn't stop immediately
<ttx> SpamapS: link?
<SpamapS> bug 620441
<ubottu> Launchpad bug 620441 in mysql-dfsg-5.1 (Ubuntu Maverick) "MySQL upstart stop job does not cleanly shutdown mysql" [High,Triaged] https://launchpad.net/bugs/620441
<SpamapS> ttx: personally I think its fine to just wait 5 minutes and then kill -9 mysql
<SpamapS> but the users of MyISAM tables definitely disagree
<ttx> SpamapS: they say you shouldn't send SIGKILL... but if you shut down the process will be killed anyway
<SpamapS> ttx: kill -9 corrupts myisam tables
<SpamapS> if there are any recent writes .. the table is likely toast.. data will be lost
<SpamapS> IMO, this is part of life with MyISAM
<ttx> SpamapS: i suspect shutting down with the process still running is no better
<ion> Perhaps people should use, you know, reliable databases. :-P
<SpamapS> ttx: if you halt the box, yes, you'll still kill -9, but on upgrade, for instance, it will just fail to stop.
<ttx> SpamapS: how did this work before the upstart conversion ?
<SpamapS> ion: InnoDB is perfectly reliable.. and I agree, people should use it. MyISAM is a dinosaur and quite worthless. :-P
<SpamapS> ttx: try for 20 seconds then fail.
<SpamapS> ttx: from what I see, if pre-stop exits, no matter what the return code, the service gets stopped
<ttx> SpamapS: any way we can replicate that ? At least nobody would be shouting "regression"
<ttx> i see no solution that would please everyone
<SpamapS> agreed
<SpamapS> My thinking was to simply log the warning that mysql timed out waiting for shutdown and had to be forcibly killed
<SpamapS> but that brings me to.. whats the best way to log things in upstart jobs.. to which nobody has replied
<ttx> let's ping the experts
<ttx> Keybuk, slangasek, cjwatson: ^
<cjwatson> not I
<SpamapS> ttx: also sent a message to ubuntu-devel that hasn't seen any responses
<SpamapS> also.. if pre-stop causes a process to die, hopefully it doesn't get respawned.
<jdstrand> Keybuk: hey. I'm the reporter of the 'stty sane'/SIGSTOP bug. I also reported bug #627055, which is where X seemingly gets a SIGSTOP out of nowhere (eg, when user's are typing)
<ubottu> Launchpad bug 627055 in mesa (Ubuntu Maverick) "[needs-packaging] Wayland" [Wishlist,Triaged] https://launchpad.net/bugs/627055
<jdstrand> Keybuk: it hits infrequently, but frequently enough that I have some users that have lost data as a result
<jdstrand> Keybuk: so my question is, are there still issues with /dev/console on up to date lucid where a user's keyboard input could trigger a SIGSTOP?
<jdstrand> uhm
<jdstrand> ubottu got that wrong
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<SpamapS> ttx: I suppose the best thing to do now is to raise the kill timeout..
<jdstrand> bug #627055
<ubottu> Launchpad bug 627055 in xorg-server (Ubuntu) "[lucid] X received SIGQUIT" [Undecided,Confirmed] https://launchpad.net/bugs/627055
<jdstrand> that's the one
<ttx> SpamapS: right, that's an easy band-aid
<cjwatson> oh, hey, that's interesting
<cjwatson> so I requested that bug from ubottu on #ubuntu-meeting, and it didn't reply
<cjwatson> or actually it sort of did
<cjwatson> 16:28 <ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/483001)
<ubottu> Launchpad bug 483001 in grub2 (Ubuntu Maverick) "grub-pc needs some help in uec instances" [High,Confirmed]
<cjwatson> and that's the next one I asked for!
<cjwatson> 16:32 <ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/623609)
<ubottu> Launchpad bug 623609 in grub2 (Ubuntu Maverick) "grub-pc needs some help in uec instances" [High,Confirmed]
<jdstrand> Keybuk: I might mention that the affected systems boot with 'quiet' but not 'splash', if that makes a difference
<cjwatson> so the bug appears to be that when it hits "could not parse data", it sometimes gets its input and output out of sync?
<SpamapS> ttx: or we can just wait forever in pre-stop.. but that brings me back to upgrades failing.
<SpamapS> tho I guess the upgrdes would have failed w/ the old method too
<slangasek> SpamapS: yeah, why are they using myisam tables? :)  logging in upstart jobs, hem, you can use logger for this sort of thing, there's nothing built into upstart that lets you do arbitrary logging
<SpamapS> Right, I'm kind of looking for an upstart job writer's guide.
<SpamapS> But really, I think the key is just to raise the kill timeout to 300. 5 minutes should be long enough for normal activities to cease and buffers to flush... and not too long for a normal restart/halt to wait
 * ogra glares at https://edge.launchpad.net/ubuntu/+source/linux-ti-omap4/2.6.35-903.11/+build/1951233
<ogra> why the heck are we calling pkgstriptranslations in a kernel build ?
<ogra> does it do anything beyond what it's name suggests ?
<sladen> ogra: isn't the whole point that pkgbinarymangler is generic, you can just run it over any package and its component pieces will either just do the right thing, or do nothing at all
<ogra> right, i just dont get what translations we are stripping from a kernel
<ogra> i bet it couls save some buildd time to not call it
<ogra> *could
<sladen> ogra: mostly likely, none!  But other bits of pkgbinarymangler may be doing things
<ogra> ah, so its only a sub-process
<ogra> pkgbinarymangler in itself is likely needed for dbgsym
<manjo> superm1, I can grab some lunch and be at your office ... when is a good time ?
<manjo> superm1, let me know when I can swing by
<ogra_cmpc> cjwatson, or kirkland, can one of you let linux-ti-omap4 out of NEW (caution, there is a new headers package that wants to go to universe)
<apw> that _wants_ to go there but should not
<ogra_cmpc> :)
<dobey> if i want to get a change in for a package I don't already have upload rights for, what's the quickest way to that? i've already filed a bug and attached a debdiff for it :)
<ScottK> dobey: Yes.  That or find someone who does that owes you a favor ....
<geser> dobey: and also subscribed ubuntu-sponsors to the bug?
<micahg> would someone be able to push banshee-community-extensions through new?
<dobey> geser: i have now :)
<superm1> manjo, i'm here irght now, so you can come by
<manjo> superm1, will be around at 4?
<superm1> manjo, that's fine
<manjo> ok
<tkamppeter> Hi, can someone upload my fixed Jockey package? I have fixed bug 574396 and bug 604698. The fixes are important to support manufacturer-supplied printer drivers.
<ubottu> Launchpad bug 574396 in jockey (Ubuntu Lucid) "Jockey very slow when searching/downloading/installing printer drivers from OpenPrinting" [Undecided,New] https://launchpad.net/bugs/574396
<ubottu> Launchpad bug 604698 in jockey (Ubuntu) "Automatic printer driver download should support signed packages" [High,Fix committed] https://launchpad.net/bugs/604698
<cjwatson> ogra_cmpc: done
<ogra_cmpc> cjwatson, oh, thanks !
<neeraj> When I am running debuild command, then my package is building with any error. Now when i tried to throw the build log in a file using debuild > log.txt, then its giving debuild: fatal error at line 1340:
<neeraj> dpkg-buildpackage -rfakeroot -D -us -uc failed
 * neeraj ??
 * neeraj got gc. Wandering whether his ques was answered or not
<Chipaca> neeraj: what happens if you debuild 2> err.txt ?
<neeraj> Chipaca: debuild 2>err.txt created blank file. build process was successful
<tkamppeter> OdyX, hi
<neeraj> can I add new folder while creating patch using quilt?
<OdyX> neeraj: afaik yes
<neeraj> I mean till now I was just editing file using quilt
<neeraj> hmm.. but I am unable to find any cmd on man http://linux.die.net/man/1/quilt :(
 * neeraj I am able to create new file. edit automatically creates one if its not present
<cjwatson> just make the directory and add the files inside it
<cjwatson> you don't need to add the directory separately
<neeraj> cjwatson: ok. thanks for the pointer. :)
<cjwatson> neeraj: the only thing to note is that quilt won't remove the empty directories when you pop the patch that created them
<cjwatson> this usually doesn't matter
<neeraj> Actually I manually editied some file in various folder of one package.(which was formed by combining more than one package.) Now debdiff command is showing all changes, but new deb files are nt..
<Riddell> cjwatson: how come kubuntu-mobile images successfully include plasma-mobile?  I thought there was an issue where it needed to be moved to main or launchpad have its cron changed
<SpamapS> is there a way, with bzr-buildpackage, to get it to generate the deb src 3.0 quilt packages and commit them rather than commit changes to the source files?
<SpamapS> err. I mean quilt patches
<cjwatson> Riddell: Launchpad would need to have its cron job changed if kubuntu-mobile were split into a separate seed collection with the aim of leaving kubuntu-mobile in universe
<cjwatson> Riddell: you might see from http://people.canonical.com/~ubuntu-archive/component-mismatches.txt that kubuntu-mobile and plasma-mobile are in the list of things to be promoted to main
#ubuntu-devel 2010-09-09
<nigelb_> james_w`: ping?
<james_w`> hi nigelb_
<nigelb_> \o/
<nigelb_> james_w`: just letting you know that its our month for package training :)
<nigelb_> I managed to get one class, though we need a few more
<ajmitch> nigelb_: what do you plan to teach us?
<james_w`> nigelb_: nice, thanks :-)
<nigelb_> ajmitch: I plan to find people who can teach us :p
<nigelb_> subtle difference
<james_w`> nigelb: I'm can give a session on something, which is how I usually reduce my workload when it is my turn :-)
<nigelb> james_w`: \o/
<nigelb> james_w`: emmet has agreed too done and I need to poke maco again
<nigelb> so, one more and we've filled the schedule except for 9th Sep
<james_w`> you rock
<nigelb> :)
<james_w`> that's tomorrow
<persia> How badly do you need one today?
<persia> depends where you are :)
<nigelb> (its today for me)
<nigelb> persia: If you can do one or find somone to do it, I owe you big time ;)
<james_w`> oh yeah :-)
<persia> If you've a bundle of clamouring students, I'll spend an hour documenting something, but I'd rather not plan a proper session that would be unattended.
<persia> Alternately, I'd be more than glad to spend an hour doing Q&A on "How can I review Debian RC bugs to make sure they are closed in Maverick?"
<nigelb> tumble weed's session had very poor attendance, so I'm not sure about bundle of students :(
<persia> Yeah.  Generally students like advance notice, so they can plan the time :)
<nigelb> Since we have 5 Thursday's this month, we'll just take an off today :p
<ajmitch> persia: you actually use the rcbugs page?
<nigelb> Precisely why we need that class :p
<persia> ajmitch, Sadly, only about 6 weeks a year, but during those six weeks, very much so.
<persia> Basically, once we hit final freeze, I try to spend time closing as many of them as possible, as we *know* those are critical issues.
<persia> (plus it typically smooths the FFe process when one can point at an RC bug in Debian showing why it's important)
<ajmitch> persia: right, I've been meaning to get to it asap, I checked that it's looking at maverick now & that there aren't many comments yet
 * ajmitch did manage to break it the other day, too
<persia> break it?  How?
<ajmitch> because the quick & dirty code that I had for multiple ubuntu releases wasn't very robust
<robert_ancell> StevenK, do you know about bug 251709?
<ubottu> Launchpad bug 251709 in rdesktop (Ubuntu) "rdesktop works bad with several keyboard layouts" [Undecided,Confirmed] https://launchpad.net/bugs/251709
<StevenK> robert_ancell: Only vaguely. What about it?
<glatzor> tkamppeter, morning. Is there a way to map packages to printer drivers in Ubuntu yet? I was just looking at the sessioninstaller bug and was wondering if there have been some changes recently.
<glatzor> tkamppeter, https://bugs.edge.launchpad.net/ubuntu/+source/sessioninstaller/+bug/612140f sessioninstaller
<ubottu> Launchpad bug 612140 in sessioninstaller (Ubuntu) "session-installer crashed with AttributeError in InstallPrinterDrivers() when setting up a printer" [High,Fix committed]
<robert_ancell> StevenK, I think you applied the path initially.  It looks like the patch causes a lot of problems and a lot of people are asking it to be removed.  I'm not sure if it's trading one set of problems for another though
<StevenK> robert_ancell: I didn't even write the patch, I just sponsored it. Since then I've not had time to investigate.
<tkamppeter> glatzor, no, Red Hat's idea to add tags based on each supported printer device ID to Red Hat's RPM is not yet ported to DEB. AFAIK it not even reached RPM upstream yet.
<sabdfl> update-initramfs: Generating /boot/initrd.img-2.6.35-20-generic
<sabdfl> .: 6: Can't open /scripts/casper-functions
<sabdfl> but will it blend?
<sabdfl> s/blend/boot/?
<glatzor> tkamppeter, so it would be best to disable the call to PackageKit in the gnome print manager
<tkamppeter> glatzor, if the patch fixes session-installer to at least not trigger Apport it is OK, the unneeded PackageKit call does not need significant time. Not patching s-c-p now avoids the risk of regression and keeps the deviation to upstream lower.
* spm changed the topic of #ubuntu-devel to: LP down/read-only 0800-1100 UTC | FeatureFreeze in effect! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<tkamppeter> OdyX, hi
<tkamppeter> Hi, can someone upload my fixed Jockey package? I have fixed bug 574396 and bug 604698. The fixes are important to support manufacturer-supplied printer drivers.
<ubottu> Launchpad bug 574396 in jockey (Ubuntu Lucid) "Jockey very slow when searching/downloading/installing printer drivers from OpenPrinting" [Undecided,New] https://launchpad.net/bugs/574396
<ubottu> Launchpad bug 604698 in jockey (Ubuntu) "Automatic printer driver download should support signed packages" [High,Fix committed] https://launchpad.net/bugs/604698
<wzssyqa> can somebody help to rebuild ibus-sunpinyin?
<persia> In what way do you need help?
<wzssyqa> persia: it is FTBFS because of lack of dep, now it can build sucessfully
<wzssyqa> persia: https://edge.launchpad.net/ubuntu/+source/ibus-sunpinyin/2.0.2-0ubuntu1
<persia> wzssyqa, Oh, heh.  Then certainly this is the place to ask.
<persia> The way such a thing is usually requested is "Could someone please give-back ibus-sunpinyin on all architectures?"
<persia> I've just done so.
<wzssyqa> persia: i see
<wzssyqa> persia: i have wait for it several days.....
<robert_ancell> slangasek, I'm looking at the differences between our version of cdrdao, you have listed "Add armv7l target" but I can
<robert_ancell> 't fine any change for that
<slangasek> robert_ancell: that's not me who listed this
<slangasek> robert_ancell: it may be that this was a no-change rebuild with the toolchain targeting armv7 by default; but perhaps you want to check with JamieBennett to be sure
<robert_ancell> slangasek, ok, thanks.  I'm guessing it's nothing, because there doesn't seem to be any delta
<persia> Made more confusing because there's no matching prior changelog entry to which that might refer.
<robert_ancell> ah, I found it - it's one of those confusing packages that has a modified source tarball.  I'll convert it into a patch
<amitk> seb128: who is the best person to update powertop with a patch?
<seb128> amitk, not sure, pitti? he will be back monday if that can wait
<cjwatson> sabdfl: hm, I thought we'd fixed all the bugs of that form.  can you  fgrep -r '. /scripts/casper-functions' /usr/share/initramfs-tools  to find out where that is?
<cjwatson> sabdfl: (it probably will boot if that was the only error, but even so!)
<amitk> seb128: ok, we can wait till monday, thanks
<ogra> amitk, do we have a wikipage or something about the kernel options that need to be enabled for powertop to work ? i'd like to have it working in the ubuntu kernels
<ogra> (and i know that iotop and powertop moaned for me in the past about missing kernel features)
<amitk> ogra: there isn't an explicity page I know of, but the patch that we're trying to push to ubuntu should make powertop work on omap HW
<ogra> ah, k
<amitk> and others implementing cpufreq and cpuidle
<ogra> i hope it applies on omap4 too :)
<amitk> the other options should already be enabled
<amitk> ogra: it will since they use the same PM arch, but we can't verify since we don't have omap4 HW
<amitk> you can try it from amitarora's ppa though
<ogra> we dont have PM enabled on omap4 yet
<sabdfl> cjwatson: /usr/share/initramfs-tools/scripts/casper-bottom/46disable_census:. /scripts/casper-functions
<ogra> HW lacks full support yet
<sabdfl> and thanks for the reassurance :)
<tkamppeter> glatzor, mvo, the patch in bug 612140 did not help. It only reveals another problem.
<ubottu> 'Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable\nResponse headers:\n---\nconnection: close\ncontent-type: text/html\ndate: Thu, 09 Sep 2010 08:57:43 GMT\nstatus: 503\ntransfer-encoding: chunked\nvary: Accept-Encoding\nvia: 1.1 wildcard.edge.launchpad.net\n---\nResponse body:\n---\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\r\n<html 
<cjwatson> sabdfl: what does 'dpkg -S /usr/share/initramfs-tools/scripts/casper-bottom/46disable_census' say?  I don't have that file here
<cjwatson> actually I can probably check the archive for that ...
<cjwatson> doesn't seem to be in the archive
<cjwatson> sabdfl: if you could put a copy of that file somewhere, I can advise on fixing it in-place
<Laney> it's that canonical-census thing
<cjwatson> ah, it's in partner
<cjwatson> yep, that's the breakage I expected
<cjwatson> sabdfl: move the '. /scripts/casper-functions' line down to below the 'esac', and rerun 'update-initramfs -u'
<cjwatson> and poke pitti :-)
<ricotz> seb128, i have an updated cairo 1.10.0-1ubuntu1 package in my staging ppa, perhaps you can have a look later when everything is up again
<seb128> ricotz, I was going to upload that when launchpad is back
<seb128> ricotz, thanks for your work, you might want to be on #ubuntu-desktop or tell people before starting changes
<seb128> ricotz, it seems you often duplicate work we are doing
<glatzor> tkamppeter, ups. I will have a look at it
<sabdfl> thanks colin!
<tkamppeter> glatzor, mvo, next session-installer bug reported: bug 633913.
<ubottu> Launchpad bug 633913 in sessioninstaller (Ubuntu) "session-installer crashed with ModifyInternalError in _install_printer_drivers()" [High,New] https://launchpad.net/bugs/633913
<tkamppeter> Anyone can upload Jockey for me?
<didrocks> cjwatson: thanks for the sync
<luboss> hello
<luboss> I'm not sure where to ask. I think this is the right place
<luboss> I'm very curious how ubuntu devs generate Packages index files in repository from deb packages. I know there is dpkg-scanpackages, but this is somehow very trivial. Another less used tool is apt-move but this doesn't seem to do the right job either.
<persia> luboss, This isn't a bad place, but it won't necessarily get you the best answer.
<persia> The short answer is that we don't: we rely on the Soyuz component of launchpad to do it for us.
<persia> The longer answer is buried in the Soyuz source.  That said, many of us use a wide variety of techniques for short-term, personal, or other archives.
<persia> Someone in #launchpad might be able to give a more detailed answer.
 * ogra_cmpc thinks apt-ftparchive is the current tool of choice for local archives
<ogra_cmpc> (though i'm personally using dpkg-scanpackage too for that task)
<penguin42> is there anyway to update an ia32-libs in a ppa?   The 'source' is I think just a big tar of bins which makes it awkward
<persia> penguin42, It's the same as one would do anywhere: it's kinda bandwidth intensive.
<persia> I haven't looked into it in detail, but it may well be possible to use the new recipe build feature to have launchpad do that automatically daily or something.
<penguin42> recipe build ?
<luboss> thank you both persia and ogra_cmpc, I will study those
<persia> penguin42, http://blog.launchpad.net/cool-new-stuff/launchpads-build-farm-improvements but you may find more from asking the LP folks
<penguin42> Thanks
<JohnHeikkila> hello
<kenvandine> cjwatson, i have another gwibber upload in lucid-proposed that needs accepting, but it is from a re-opened bug which ubuntu-sru is already subscribed
<kenvandine> cjwatson, can you please look at it?
<kenvandine> cjwatson, it fixes a pretty significant bug which will likely also reduce the number of requests gwibber makes to facebook, so hopefully getting us back down below our allocation
<doko> cjwatson: could you promote https://edge.launchpad.net/ubuntu/+source/openjdk-6b18/6b18-1.8.1-2ubuntu1/+build/1950520 ?
<doko> or do I have to seed it?
<cjwatson> kenvandine: done
<kenvandine> cjwatson, bug 595265
<kenvandine> thx
<kenvandine> :)
<ubottu> Launchpad bug 595265 in gwibber (Ubuntu Lucid) "Can not add Facebook account as add button not displayed after authorisation." [High,Fix committed] https://launchpad.net/bugs/595265
<kenvandine> you rock!
<kenvandine> man i hope that helps with the allocation!
<kenvandine> so many people keep just giving work arounds that really don't help... they just get lucky
<tkamppeter> Anyone can help me on a package dependencies/upgrade problem (bug 633987)?
<ubottu> Launchpad bug 633987 in foomatic-db (Ubuntu) "foomatic-db-compressed-ppds holds back ubuntu-desktop" [Undecided,New] https://launchpad.net/bugs/633987
<cjwatson> doko: that's fine, component-mismatches lists it (once I fixed it, anyway - the web page is mostly blank right now)
<cjwatson> doko: promoted
<doko> cjwatson: thanks, the arm assembler interpreter wasn't ready for maverick
<doko> in b20
<cjwatson> I had to peer at madison-lite output for a bit before I worked out what was going on, yes :)
<primes2h> g. afternoon ara
<ara> hey primes2h
<primes2h> ara: I'm testing Ubuntu One... Do they changed the way to sign in in U1?
<primes2h> http://testcases.qa.ubuntu.com/Applications/UbuntuOne#Ubuntu%20One%20existing%20user,%20initial%20setup
<primes2h> now it appears a window, no Browser anymore.
<ara> yes, you are right. in that window you get a link to "manage account"?
<primes2h> s/do/did
<primes2h> s/changed/change
<primes2h> I think testcase should be updated.. Could I?
<ara> sure, go ahead
<tkamppeter> Hi, can someone upload my fixed Jockey package? I have fixed bug 574396 and bug 604698. The fixes are important to support manufacturer-supplied printer drivers.
<ubottu> Launchpad bug 574396 in jockey (Ubuntu Lucid) "Jockey very slow when searching/downloading/installing printer drivers from OpenPrinting" [Undecided,New] https://launchpad.net/bugs/574396
<ubottu> Launchpad bug 604698 in jockey (Ubuntu) "Automatic printer driver download should support signed packages" [High,Fix committed] https://launchpad.net/bugs/604698
 * penguin42 is looking at a bootchart trying to understand a ~30 second boot hang my maverick box has gained
<penguin42> it looks like the only non-sleeping thing for those 30 seconds is lvm  - which is sleeping on io
<sabdfl> tkamppeter: are there any issues in a recent cups that are causing widespread "printer warning" blockages?
<sabdfl> clan and my printer stopped working recently, i want to know if i should dig into it or just wait for another update :)
<dobey> could i get someone to poke at https://bugs.edge.launchpad.net/ubuntu/+source/pyinotify/+bug/633405 ? :)
<ubottu> Launchpad bug 633405 in pyinotify (Ubuntu) "Raises empty OSError when inotify_init fails" [Undecided,New]
<ricotz> seb128, ok, sorry about the duplication
<seb128> ricotz, no worry
<manjo> cjwatson, thanks for all the hard work you put in to make 10.10 install on UEFI based system. I was able to install the x64 desktop image on my intel weybridge, intel will show case Ubuntu running on UEFI based system at the IDF next week.
<manjo> superm1, ^
<tkamppeter> OdyX, hi
<tkamppeter> sabdfl, I do not know about such "printer warning" blockages?
<tkamppeter> sabdfl, can you tell me more? Which printer do you have? What exactly happened? What did you try to print? Are there bug reports?
<cjwatson> manjo: fantastic
<cjwatson> manjo: thanks for all the testing thus far
<manjo> cjwatson, ++beer
<superm1> manjo, ooh great to hear.
<mdz> mvo, if you're around, I think tkamppeter would appreciate some apt guidance in bug 633987
<ubottu> Launchpad bug 633987 in foomatic-db (Ubuntu) "foomatic-db-compressed-ppds holds back ubuntu-desktop" [Undecided,Incomplete] https://launchpad.net/bugs/633987
<mvo> mdz: thanks, I have a look, I am debugging a software-center issue currently but I can check it out after that
<tkamppeter> mvo, mdz, I have explained in the bug what I want to have and with which measures I tried to get it. Probably for most people it actually works.
<james_w> didrocks: found the cause
<didrocks> james_w: really? great!
<james_w> didrocks: it's the rename handling again
<didrocks> james_w: urgh, any way to bypass it?
<james_w> didrocks: I'm trying to figure out a fix. If it's not easy I can do a terrible hack to make it work in this one case
<didrocks> james_w: take your time, still fixing other things and testing
<james_w> great
<sabdfl> tkamppeter: pebkac
<mdz> tkamppeter, there's nothing too unusual about my system; I perhaps have a few extra packages installed
<sabdfl> i changed the dhcp settings, both of our printers had been setup with fixed ip address configs
<mdz> tkamppeter, the only package on my system which depends on foomatic-db is ubuntu-desktop
<mdz> so I would expect this problem to affect others as well
<ScottK> Affected me too.
<sabdfl> tkamppeter: do you know why autodetected printers would use fixed ip addresses rather than avahi ones?
<seb128> tkamppeter, mvo, that's what aptitude says
<seb128> The following packages have unmet dependencies:
<seb128>   foomatic-db-compressed-ppds: Conflicts: foomatic-db but 20100906-0ubuntu1 is installed.
<seb128>                                Conflicts: foomatic-db-hpijs which is a virtual package.
<tkamppeter> mdz, what should happen is that ubuntu-desktop gets replaced by the new version which depends on foomatic-db-compressed-ppds instead and the conflict would make foomatic-db uninstalled.
<mdz> tkamppeter, yes, I would expect that too
<seb128> ubuntu-desktop depends on foomatic-db
<tkamppeter> sabdfl, susyem-config-printer usually prefers Avahi-based URIs.
<mdz> seb128, ahh, well spotted
<mdz> seb128, oh, no, that's the old version
<mdz> 1.204 depends on foomatic-db, 1.205 depends on foomatic-db-compressed-ppds
<seb128> let me try to apt-get update
<seb128> I did upgrade yesterday evening
<mdz> so the correct solution is to remove foomatic-db, install foomatic-db-compressed-ppds, and upgrade ubuntu-desktop
<mdz> but apt decides to hold back ubuntu-desktop instead
<tkamppeter> sabdfl, which printer model do you ghave? Which is the dnssd-based URI and which the fixed-IP-based one?
<mvo> probably because of rdpends on foomatic-db
<mdz> mvo, a test removal found no other reverse deps on my system
<mdz> there could be recommends or suggests but no other depends
<tkamppeter> mdz, mvo, do I perhaps need a versioned dependency somewhere?
<ScottK> I think you need a transitional package.
<cjwatson> my untested suspicion is that your conflicts are overly *strict*
<cjwatson> and that weakening to breaks might help
<cjwatson> it's a pain to test this kind of thing
<cjwatson> having to leave foomatic-db in the archive for other purposes probably doesn't help
<cjwatson> ScottK: tkamppeter said a few days back that foomatic-db was still needed for build-dependencies
<cjwatson> I didn't catch the details
<seb128> $ grep-available -s Package -F Recommends foomatic-db
<seb128> Package: foo2zjs
<seb128> Package: foomatic-filters
<seb128> Package: min12xxw
<tkamppeter> ScottK, with a transitional package I have the problem that I do not want to remove foomatic-db from the distro, it will continue to exist but only be used as build dependency.
<ScottK> OK
<sabdfl> tkamppeter: Xerox Workcenter 6400X
<sabdfl> adding a printer with system-config-printer, i see two detections of the same printer
<sabdfl> one is "AppSocket/JetDirect network printer via DNS-SD"
<sabdfl> the other is Host: 192.168.1.10 Port 9100
<tkamppeter> seb128, in foomatic-filters (4.0.5-0ubuntu3) I have already removed the Recommends
<sabdfl> interestingly, they both have an IP address in brackets in the selctbox
<sabdfl> one is correct, the other is a 169.254.84.167, which I don't recognise
<tkamppeter> seb128, in min12xxw (0.0.9-3ubuntu3) foomatic-db is only recommended as alternative if foomatic-db-compressed-ppds is not there.
<seb128> ok so dunno
<cjwatson> 169.254.0.0/16 is avahi
<tkamppeter> sabdfl, which of the two is selected by default?
<SpamapS> It might make sense to filter out 169*'s with identical MAC addresses to routable IP's
<SpamapS> Just means it got broadcasted while the printer was still negotiating an IP with the DHCP server most likely
<SpamapS> or maybe the printer retains its' 169.254 address to allow communication with devices that don't receive an IP
<tkamppeter> seb128, foo2zjs (20100728-0ubuntu1) recommends only foomatic-db-engine, not foomatic-db.
<cjwatson> somebody should try -o Debug::pkgProblemResolver=true on a failing machine
<cjwatson> mvo: hmm, it seems confusing to be using quilt in apt-xapian-index, given that it's a native package?
<mvo> cjwatson: feel free to drop it, I don't mind much. I was using it to organize the patches better, but upstream (enrico) is usually quick to apply them anyway
<cjwatson> yeah, mostly looking at bug 267330
<ubottu> Launchpad bug 267330 in apt-xapian-index (Ubuntu) "update-apt-xapian-index crashed with OSError in getmtime()" [Medium,Confirmed] https://launchpad.net/bugs/267330
<enrico> mvo: which reminds me to remind you, apt-xapian-index it's in collab-maint :)
<cjwatson> I certainly see some obvious places where pitti's fix was incomplete
<cjwatson> as it happens I was going to work on that bug in collab-maint ;-)
<mvo> enrico: oh, thanks. I'm probably too cautious
<neeraj> Hi, I was creating patch using quilt and then I had make changes in various Makefile.am and configure.ac file. Now, the problem is that I can make all changes in these using quilt edit, but I am not sure how the autorunconf file will be called while applying patch.
<Riddell> ogra: where's your ARM build failure chart?
<ogra_cmpc> chart ?
<ogra_cmpc> oh, the table ... one sec
<ogra_cmpc> Riddell, http://qa.ubuntuwire.org/ftbfs/
 * neeraj got dc again. Not sure whether his query was answered or not.
<cjwatson> neeraj: run autoreconf inside 'quilt shell' (you might want to make a separate patch just for that, and remove junk like autom4te.cache before exiting the shell)
<Riddell> ogra_cmpc: thanks.  it's looking good
<ogra_cmpc> Riddell, well, there is koffice still
<neeraj> cjwatson: ok thanks. Trying that.
<manusheel> cjwatson: Thanks for the pointers.
<cjwatson> enrico: does http://paste.ubuntu.com/491108/ look OK?  this matches a fix already in plugins/apttags.py
<cjwatson> enrico: if you don't mind, I can roll a 0.40 with that
<enrico> cjwatson: it looks good
<enrico> cjwatson: if you're in a hurry you can roll a 0.40. If you're not in a hurry, there's [...]
<enrico> cjwatson: #595916 and #594675 to which I have to dedicate an afternoon
<enrico> cjwatson: but it won't be this week or the next one, I fear, so feel free to do 0.40
<cjwatson> hmm.  I'll have a look at those but may not know the code well enough
<james_w> didrocks: I think I've got it
<cjwatson> thanks
<didrocks> kaoh, great!
<didrocks> james_w: great :)
<SpamapS> when using bzr-buildpackage with 3.0 quilt format packages, is there a way for it to generate the "xxxver changes" patches and commit those on debcommit?
<SpamapS> that would be a pretty awesome feature actually. :)
<enrico> cjwatson: #595916 looks like a Xapian python API change (should ping ojwb)
<enrico> cjwatson: #594675 is a tricky one that requires laying out a migration path, which I do have in mind already, let's write it to the BTS
<cjwatson> I think I'm probably best just getting the immediate job done for now, then
<enrico> cjwatson: ok
<didrocks> james_w: do you have a patch I can test?
<james_w> didrocks: just polishing and committing
<didrocks> james_w: great, thanks!
<james_w> didrocks: tip of bzr-builddeb should work for you now
<didrocks> james_w: grabbing it, should I set some PYTHONPATH and such?
<james_w> didrocks: you can use BZR_PLUGINS_AT to run it from an arbitrary directory
<didrocks> james_w: trying that
<superm1> manjo, okay mine got fully installed too, so just need to figure out those nx problems
<james_w> BZR_PLUGINS_AT=builddeb@/tmp/builddeb bzr mu ...
<james_w> something like that
<manjo> superm1, great news, cheers to cjwatson ... yep ack on NX
<cjwatson> superm1: huh, wasn't that the one that wouldn't boot?
<cjwatson> superm1: did you use noexec to work around it or something?
<superm1> cjwatson, i've got both a 6410 and 6510 - noexec works on the 6510, not the 6410
<cjwatson> superm1: right, I tried noexec on mine and it made no difference.  docking station is due to arrive in a couple of days, I think ...
<james_w> didrocks: there's a test failure, which isn't a good sign, but it's in a case completely unrelated to yours, so you should be ok for this one branch. I'll work on the failure after lunch.
<didrocks> james_w: worked wonderfully well, thanks :)
<superm1> cjwatson, cool.  if you'd like me to do any other instrumentation with mine in the interim, i'll be glad to
 * didrocks now building unity-place-applications
<didrocks> james_w: thanks for working on it so quickly!
<neeraj> for running autogen.sh function using quilt, will $quilt shell aclocal, $quilt shell autoconf, $quilt shell automake --add-missing and quilt shell rm -rf autom4te.cache is sufficient?
<cjwatson> you should use 'autoreconf -i' rather than running all those by hand
<cjwatson> and I'd recommend running 'quilt shell', running successive commands at the shell prompt it gives you, and then exiting that shell
<cjwatson> if there's already an autogen.sh in the package, use that rather than autoreconf
<neeraj> Ok. there is not autogen.sh, should I add quilt shell autoreconf -i \
<neeraj> > && rm -rf autom4te.cache
<cjwatson> run quilt shell
<cjwatson> press enter
<cjwatson> run the commands
<cjwatson> type exit, then press enter
<cjwatson> (the above will include autom4te.cache in the patch because && is scoped wrongly)
<neeraj> cjwatson: ok :)
<SpamapS> hmm.. can dh_autoreconf run an autogen.sh ?
<SpamapS> yes.. apparently it can
<SpamapS> you don't have to use quilt for autoreconf'ing it seems
<neeraj> hmm.. sorry for my ignorance  but can you please elaborate? Do i have to make changes in some file or run dh_autoreconf?
<juliank> neeraj: Use dh_autoreconf as documented in dh-autoreconf(7)
<neeraj> ok. in the quilt files, there alocal.m4. I guess I had to remove it?
 * neeraj don't want to redo all steps from scratch. Can he run quilt shell and add rm -rf ?
<neeraj> ok. may be I don't..
<manjo> superm1, do U have that pastebin of the panic ?
<superm1> manjo, http://paste.ubuntu.com/486907/
<manjo> superm1, thanks, on the intel weybridge with UEFI 2.1 NX support Active, we are able to boot and64 kernel normally
<kenvandine> cjwatson, do you have any tips on how to get around this error:
<kenvandine> dpkg-source failed for libdbusmenu_0.3.13-0ubuntu1.dsc [return: 29]
<kenvandine> tried on multiple boxes, both lucid and maverick
<kenvandine> can't get a source package that can be extracted with dpkg-source
<kenvandine> tedg can't either
<smoser> Keybuk, around ?
<smoser> i'm wondering the difference between 'optional' and 'nobootwait' to mountall.
<smoser> i can't think of an expected difference between them if the device was not present at boot.
<smoser> anyone know ?
<mneptok> is it possible to use btrfs for /boot in Maverick (yet)?
<smoser> i think is see the difference now. optional will still hold up boot.
<cr3> is it more common for a project to have the directory doc/example (singular) or doc/examples (plural)?
<mdeslaur> cr3: a quick non-scientific study of my /usr/share/doc directory says examples is more popular, 275 vs. 12
<cr3> mdeslaur: I've also found section 12.6 in the debian policy manual: http://www.debian.org/doc/debian-policy/ch-docs.html
<cr3> mdeslaur: "Any examples (configurations, source files, whatever), should be installed in a directory /usr/share/doc/package/examples."
<mdeslaur> cr3: well, there you go...unless you only have one single example...then what? :)
<cr3> mdeslaur: my project doesn't necessarily need to map to debian packaging policy, I might as well use that as a policy
<achiang> what is the proper way to update a package to a new upstream release when autotools are involved? (specifically, i'm looking at libx11)
<achiang> i was thinking of: untar upstream.tar.gz, cp -a oldver/debian upstream/  and then see what happens from there...
<achiang> oh, except after unpacking upstream.tar.gz, it won't have the autotools artifacts
<achiang> oops, i meant to ask that in #ubuntu-packaging
<zyga-gone> lucas, ping
<manjo> why can't I name my machine with I install maverick ? or am I missing something ?
<manjo> I don't see a box where I can enter system name
<manjo> Maverick seems to set the system name based on my user name ... for example manjo-laptop
<penguin42> manjo: Older ones used to give you that as a default during the install screen as you filled it in but let you change it - is that no longe rthe case?
<manjo> penguin42, you man change it after the install ?
<penguin42> manjo: No, during - on lucid and previous as you typed in the username on a fiield below it it filled in the hostname box and you could edit it
<manjo> penguin42, I want to set the system name when I enter my user name etc ... like I did in lucid...
<theGuest> manjo, bug 628087
<ubottu> Launchpad bug 628087 in ubiquity (Ubuntu) "Maverick ubiquity lacks option to change computer name" [Low,Confirmed] https://launchpad.net/bugs/628087
<manjo> yep it does not let me in Maverick... unless I am missing something
<manjo> theGuest, thanks .. did not want to open a dup in that case
<manjo> design team is making my head ache :)
<manjo> I have 3 machines at home, now eachone will be called manjo-laptop... what a PITA
#ubuntu-devel 2010-09-10
<kklimonda> manjo: it's pretty easy to change that
<manjo> kklimonda, yeah edit files ..
<penguin42> kklimonda: Careful, I've just noticed there are host specific peripheral settings in gconf
<penguin42> (although bizarely the only thing under periphers->keyboard->host-major is the default seetting of numlock)
<kklimonda> penguin42: but they should still work after hostname is changed.
<penguin42> kklimonda: I just wonder what other settings are actually keyed off hostname
<kklimonda> penguin42: It's not really a good idea to do that.
<kklimonda> penguin42: if any application uses host in its settings then bug report should be filled imo
<penguin42> kklimonda: It is in an envrionment with a networked home directory; you want peripheral config to be local to where you are logged in
<kklimonda> penguin42: then they should be stored somewhere local imo
<penguin42> admittedly those environments are rarer these days
<kklimonda> penguin42: and in those environments you don't use a shiny graphical installer anyway.
<penguin42> probably true
<penguin42> can someone with a vague knowledge of gnome eyeball some code in mango-lassi for me - it looks broken to me, I just can't understand why it only segs on one of two machines
<JakeTripplJ> hay
<Kano> hi cjwatson
<Kano> i would suggest executing dpkg-reconfigure -phigh console-setup in casper after setting the locale
<Kano> and when you use your installer then too
<Kano> otherwise the console font is incorrect for the locale
<Kano> then you can not see umlauts for example when you boot with german settings live
<mvo> doko: do you mind if I upload a python-central crash fix? or do you want to review first (is there a vcs to use?)
<doko> mvo: no, please go ahead
<mvo> thanks doko
<cjwatson> kenvandine: libdbusmenu_0.3.13-0ubuntu1.dsc extracts fine for me.  can you help me get a test case so that I can understand your problem?
<cjwatson> mneptok: btrfs /boot> no, held up on licensing
<cjwatson> kenvandine: hm, well, somebody seems to have solved the problem since there's a libdbusmenu_0.3.13-0ubuntu1.dsc in the archive now
<seb128> cjwatson, I think he remade the tarball
<seb128> the one on https://edge.launchpad.net/dbusmenu/+download didn't work for him
<cjwatson> ok
<seb128> cjwatson, do you know how the ddeb service works?
<seb128> ie where the collector is running?
<cjwatson> not really
<seb128> I think I figured it out
<seb128> the service seems stucked since yesterday, could be due to the launchpad downtime
<seb128> I will just restart it and see
<cjwatson> enrico: it looks like apt-xapian-index 0.39 was never released.  should I just append my change to the 0.39 changelog, and mark it UNRELEASED in git?
<mvo> cjwatson: I just commited the "apt-cdrom looks into .disk for calculating the ident string" change, do we need to worry about backward comatibility? I guess not as it was never really working with usb-sticks anyway?
<cjwatson> mvo: can you point me at the commit and I'll have a look?
 * Daviey screams.
<Daviey> .. and sobs
 * hyperair gives Daviey a strange look
 * soren pats Daviey on the head
 * davmor2 passes Daviey a cookie and tells him to eat it, life will be better afterwards
<Daviey> \o/
<soren> That's more like it.
<davmor2> Daviey: now get back to work and fix that issue :P
<Daviey> yes sir!
<cjwatson> enrico: (I'm ready to commit a fix for the xapian api change as well, once I know the answer to that question :-) )
<tkamppeter> mdz, hi
<Kano> cjwatson: did you get my notice about the wrong fonts in console
<mdz> tkamppeter: hi
<mvo> cjwatson: here is the commit http://bazaar.launchpad.net/~ubuntu-core-dev/apt/ubuntu/revision/1796 (sorry for the delay, I was at lunch)
<cjwatson> damn you for EATING
<cjwatson> hm, is access() a reliable test for that then?
<tkamppeter> mdz, it is about bug 633987.
<ubottu> Launchpad bug 633987 in foomatic-db (Ubuntu) "foomatic-db-compressed-ppds holds back ubuntu-desktop" [Undecided,Incomplete] https://launchpad.net/bugs/633987
<mdz> tkamppeter: yes, I answered your question in the bug. did you and mvo talk further about it yesterday?
<mvo> cjwatson: I'm not 100% sure, but in my tests it seems to be ok
<mdz> tkamppeter: there were a few other people on IRC yesterday who confirmed the bug
<mvo> mdz: no, sorry. but s-c/aptdaemon are uploaded now, so I have breathing space again for this
<cjwatson> access("/mnt", W_OK)                    = -1 EROFS (Read-only file system)
<cjwatson> apparently so.  neat
<tkamppeter> mdz, I do not really understand why the update is not working for you. It probably works for many users as I did not get any duplicate.
<cjwatson> mvo: you might want to e-mail the debian-live folks and ask, but given that it basically always breaks at the moment I think it should be OK
<mvo> cjwatson: I tried with usb-stick (both rw,ro) and cdrom and got the answers I was expecting
<mvo> cjwatson: good idea, I will do that
<mdz> tkamppeter: mvo is our resident expert on this type of issue
<tkamppeter> mdz, I can try to replace the Conflicts: by Breaks:, but this is simply a guess.
<mvo> tkamppeter: give me some minutes, I will try to reproduce the setup that mdz has
<tkamppeter> mvo, what exactly is the difference between Conflicts: and Breaks:?
<cjwatson> enrico: looking at the history, I guess you don't normally use UNRELEASED, so I'll go ahead and put these changes in 0.39
<mvo> tkamppeter: internally they are handled similar, but for breaks apt will try a little bit harder to upgrade the package before it gets moved to the remove-list
<cjwatson> tkamppeter: the policy manual documents this clearly
<cjwatson> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks
<cjwatson> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
<cjwatson> the latter has specific instructions for when each field should be used
<Kano> cjwatson: did you fix the iso build tool to get hybrid iso images
<tkamppeter> cjwatson, thanks.
<penguin42> is launchpad broke at the moment? #launchpad seems pretty dead and I'm having problems reporting an oops with a 'sorry, there was a problem connecting to the launchpad server.' and a guy I was helping last night had the same problems
<mvo> cjwatson: I updated the diff yet again (noticed another bit that needed fixing) and mailed debian-live. I guess its best to wait for feedback from debian-live before uploading so that the ident id does not change/become incompatible if we decide to change the code again. what do you think?
<mvo> mdz: could you mail me a tarfile with /var/lib/dpkg/status and /var/lib/apt/lists please ?  I will dig into it then
<cjwatson> mvo: seems reasonabe
<cjwatson> +l
<mvo> cool, thanks
<mvo> mdz: nevermind, I can reproduce it here now
<cjwatson> enrico: I've uploaded 0.39, and will sync that into Ubuntu
<mvo> tkamppeter, cjwatson: the eaisest fix for the foomatic-db problem is to make foomatic-db a lower priority then foomatic-db-compressed. so swtichting foomatic-db to "Priority: extra" should do it. I belive this needs to be done by a archive-admin
<enrico> cjwatson: excellent, thanks! (just came online, I was at a customer)
<apparle_> Suggest a cross platform IDE,..... I know about eclipse and netbeans... tell me which is good or other if you know any other
<cjwatson> mvo,tkamppeter: I've set the priority of foomatic-db to extra, as well as foomatic-db-engine
<mvo> thanks cjwatson
 * mvo updates the bug
<mvo> cjwatson:  and thanks for the xapian fix for software-center :)
<tkamppeter> mvo, thanks. So you have uploaded foomatic-db_20100906-0ubuntu2 now?
<tkamppeter> s/mvo/cjwatson/ ^^^
<mdz> tkamppeter: I think cjwatson meant that he changed the priority of -0ubuntu1
<tkamppeter> mdz, where are these priorities set? How can I set them if I encounter a similar problem in the future?
<mdz> tkamppeter: they are set centrally by archive administrators; it requires special privileges
<tkamppeter> mdz, mvo, cjwatson, looks a little like a workaround for a shortcoming (bug?) in apt for me. In this case foomatic-db-compressed-ppds should get priority against foomatic-db as it solves the dependencies of the new ubuntu-desktop and so no artificial prioritizing is needed.
<cjwatson> maybe so, but in this matter I bow to mvo's expertise :)
<cjwatson> and yes, mdz is correct
<mdz> tkamppeter: yes, I'm inclined to agree that it's a workaround, but we're not likely to try to fix this in apt for 10.10 ;-)
<tkamppeter> mvo, mdz, cjwatson, are these package priorities somewhere visible in Launchpad?
<mvo_> tkamppeter: it is, the resolver is not always the most smartest in the world. fortunately its very predictable. I look into a solution in code next, but for mav we can not really change the resolver anymore
<mvo_> (too risky)
<mdz> tkamppeter: yes
<mdz> tkamppeter: though the easiest way to see them is to use apt-cache
<mdz> mizar:[~] apt-cache show foomatic-db | grep Priority
<mdz> Priority: optional
<cjwatson> the top three priorities (required, important, standard) matter to varying degrees and are managed semi-automatically, but mostly we don't bother much with the distinction between optional and extra in Ubuntu
<cjwatson> it's just useful to resolve occasional bugs like this one
<tkamppeter> mdz, I have done
<tkamppeter> sudo apt-get update
 * cjwatson wonders how sudo got to be Priority: optional, and fixes it back to important
<cjwatson> tkamppeter: it's not instant, you need to wait until the next publisher run.  give it an hour
<tkamppeter> now and checked the priorities, both foomatic-db-compressed-ppds and foomatic-db have "optional".
<tkamppeter> cjwatson, OK.
<cjwatson> an hour> assuming you're using a mirror that's pushed fairly quickly that is
<tkamppeter> cjwatson, mvo, mdz, thank you very much for the help on this.
<tkamppeter> cjwatson, I am using the German mirror.
<tjaalton> tkamppeter: hi, me again. trying to work around bug 612578 I tried to forward-port cups from jaunty, but the build fails http://pastebin.com/aMeWijTY
<ubottu> Launchpad bug 612578 in cups (Ubuntu) "Printing fails unless the IPP's are purged, but fails again after "some time"" [Undecided,New] https://launchpad.net/bugs/612578
<tjaalton> tkamppeter: ideas what makes it fail?
<Laney> please can someone look at sponsoring the tar sru in bug 539814
<ubottu> Launchpad bug 539814 in tar (Ubuntu Lucid) "tar: futimens() with a bad file descriptor (AT_FDCWD) causes bootstrapping failure with kernels < 2.6.22" [Medium,Triaged] https://launchpad.net/bugs/539814
<rhlee> hi guys is this the right channel for packaging help?
<penguin42> rhlee: There is a #ubuntu-packaging
<rhlee> penguin42: cheers mate
<bilalakhtar> tedg: hey! So is there any other problem with my merge(s) ?
<bilalakhtar> tedg: Thanks for the comment on the bug, I'll be off now
<tedg> bilalakhtar, No problems other than we need to figure out the symbolic/color part
<tedg> Uhg, the IRC equivalent of starting a conversation as you're jumping out of the plane.
<seb128> lol
<smoser> cjwatson, around and have some time to talk about grub and that annoying ec2 ?
<penguin42> anyone finding alt-sysrq-b is being ignored? s and u are both working but B is doing nothing
<tkamppeter> mvo_, cjwatson, mdz, on my mirror priorities have changed to extra for foomatic-db and optional for foomatic-db-compressed-ppds. Is this OK? Can you try?
<cjwatson> tkamppeter: please remove me from the list of people you're asking; all I did was the archive-side change
<cjwatson> smoser: let me read through it all again; I'm having real trouble cramming all this into my head
<smoser> cjwatson, ok. i've got a bout 45 minutes, then i need to be afk for 30.
<smoser> so whichever hunk works better for you.
<cjwatson> smoser: is there some way that I can try this out personally?  I'm never going to really understand it otherwise
<cjwatson> both on EC2 and UEC
<cjwatson> nb: must not involve having to set up a cloud in my house :)
<smoser> cjwatson, i can get you an instance on ec2 easy.
<smoser> euca is more difficult, but in general, euca almost "just works"
<smoser> the only issue with it is that i'd like to be able to tell grub "don't worry about installing the bootloader anywhere"
<cjwatson> can I please not have pre-specified solutions
<cjwatson> I want to inspect the problem :)
<smoser> comon.
<smoser> ok. i'll get you an ec2 instance, and will work on getting you access to a uec also.
<cjwatson> I mean, you *can* tell grub-pc.postinst not to install the bootloader anywhere, and I know this because d-i does it
<cjwatson> but I'm not clear yet whether this is quite the right thing
<cjwatson> in particular creating core.img is considered part of installing the bootloader
<cjwatson> from grub-pc.postinst's point of view
<cjwatson> (yes, within grub-install they're two separate steps)
 * penguin42 is just testing afix for the lshw hang - I can see why it oops's, I just can't see why lshw manages to trigger it
<smoser> cjwatson, ok, you can ssh to ec2-75-101-239-180.compute-1.amazonaws.com
<smoser> and that system is "all yours" until you tell me to kill it. if you shut it down (/sbin/halt, it will go away).
<smoser> your ssh keys from launchpad are installed on that host
<cjwatson> smoser: so, if /dev/sda1 is really a disk image, then I wonder if it really makes sense for GRUB to regard it as a partition
<cjwatson> (aside from whatever Xen is doing)
<cjwatson> maybe we should go "huh, weird Xen thing, treat it as a disk"
<smoser> grub should not regard it as a partition.
<smoser> it is a disk for all purposes , just with a funny name.
<cjwatson> right, good.  it's not as if there's any particular relationship between /dev/sda1 and /dev/sda2 here
<smoser> note, also, that this disk is funny in that it has no partition table.
<cjwatson> GRUB will be OK withthat
<EdwinGrubbs> kees: ping
<mdz> tkamppeter: confirmed, it works now
<smoser> i poked trhough some of grub source, and hacked at trying to convince it that was a full disk.  my hack was to check if this 'name' existed in /sys/block, then it was a disk, not a partition.
<lool> doko: Is i686 without cmov supposed to be supported in maverick or not?
<lool> LP #632232
<ubottu> Launchpad bug 632232 in debootstrap (Ubuntu) "lucid pbuilder-dist unable to build for maverick" [Undecided,New] https://launchpad.net/bugs/632232
<tkamppeter> mdz, OK. Thanks. I will close the bug then.
<cjwatson> smoser: I'm thinking of instead simply observing that if the partition device exists but the disk device does not, then we might as well treat it as a disk since what else can we do?
<barry> james_w: ping
<james_w> hi barry
<barry> james_w: hi.  have a few minutes to talk about a udd issue?
<smoser> yeah. i can't imagine other scenarios where that would fail.
<james_w> barry: of course
<barry> james_w: cool.  so i'm working on an update to the gtimelog package.  it's been basically abandoned and i have upstream commit privs now.  marius released 0.4.0 and i'm redoing the packaging to more modern standards...
<barry> james_w: upstream trunk is in bzr on lp.  so i 'bzr branch trunk packaging' and create a loom, add a thread for the debianization work...
<barry> james_w: convert the patches i need (and the still relevant ones from the old packaging) to quilt, commit all that and 'bzr bd -S'
<barry> james_w: but i get a lintian warning: patch-system-but-direct-changes-in-diff
<ev> might I ask that anyone with a free moment run `sudo dmidecode` on their machine and pastebin me the output?  Thanks!
<james_w> barry: what's an lsdiff -z of the .diff.gz say?
<barry> james_w: now, the reason for that is that the trunk has moved a little bit from the released tgz.  it's got a bit of extra NEWS.txt and a version bump in the __init__.py
<james_w> ah
<barry> james_w: i can certainly ignore that, but i guess i'm looking for recommendations on how to handle this scenario in general
<barry> (ignore the lintian warning)
<james_w> then base your packaging on the revision corresponding to the tarball if available
<barry> james_w: right, that's the direction i was thinking about, but my question is: what happens when a new version is released from trunk?  what will be the best way to take my existing packaging loom and update it?  just pull from trunk with a revision# or tag to the bottom thread?
<james_w> barry: yeah
<james_w> barry: it would be great if we could get the pristine-tar data in there too
<barry> james_w: hmm, how could that be done?
<james_w> if you can use bzr import-upstream/merge-upstream at some point
<barry> james_w: yeah.  i think the scenario where the upstream is in bzr on lp is a weird corner case that actually makes things a little more difficult in several ways.  e.g. lp:ubuntu/gtimelog has no relationship to lp:gtimelog
<james_w> barry: yeah, but e.g. the dx team have that, and we linked the branches
<barry> james_w: ah, didn't know that could be done.  is that a manual request?
<james_w> barry: it's something you can do yourself
<barry> james_w: i'm probably just being dense.  it's obvious?
<james_w> barry: you pass an upstream branch and revision to merge-upstream
<barry> james_w: gotcha
<barry> james_w: cool, thanks.  as always very helpful.  i'll work this out and see if i can write something up on the wiki
<james_w> great, thanks
<james_w> let me know if you have any trouble
<barry> james_w: will do, thanks again
<doko> lool: no
<lool> doko: thanks
<doko> there should be an email
<Randall> Hey guys
<Randall> rmemeber me?
<brewmster> Randall: no.
<Randall> Genesis 2
<Randall> 1Thus the heavens and the earth were finished, and all the host of them.
<Randall>  2And on the seventh day God ended his work which he had made; and he rested on the seventh day from all his work which he had made.
<jY> i do.. you're the asshole
<Randall> 3And God blessed the seventh day, and sanctified it: because that in it he had rested from all his work which God created and made.
<Randall> 4These are the generations of the heavens and of the earth when they were created, in the day that the LORD God made the earth and the heavens,
<Randall> 5And every plant of the field before it was in the earth, and every herb of the field before it grew: for the LORD God had not caused it to rain upon the earth, and there was not a man to till the ground.
<Randall>  6But there went up a mist from the earth, and watered the whole face of the ground.
<Randall> 7And the LORD God formed man of the dust of the ground, and breathed into his nostrils the breath of life; and man became a living soul.
<Randall> 8And the LORD God planted a garden eastward in Eden; and there he put the man whom he had formed.
<Randall>  9And out of the ground made the LORD God to grow every tree that is pleasant to the sight, and good for food; the tree of life also in the midst of the garden, and the tree of knowledge of good and evil.
<Randall> 10And a river went out of Eden to water the garden; and from thence it was parted, and became into four heads.
<Randall> 11The name of the first is Pison: that is it which compasseth the whole land of Havilah, where there is gold;
<Randall>  12And the gold of that land is good: there is bdellium and the onyx stone.
<Randall> 13And the name of the second river is Gihon: the same is it that compasseth the whole land of Ethiopia.
<Randall>  14And the name of the third river is Hiddekel: that is it which goeth toward the east of Assyria. And the fourth river is Euphrates.
<Randall> 15And the LORD God took the man, and put him into the garden of Eden to dress it and to keep it.
<fagan> nice
<jY> what a troll
 * penguin42 can't imagine he would be good with daemons
<brewmster> was i the only one reading that?
<penguin42> brewmster: Yes
<brewmster> i think he might be a slow adult
<cjwatson> there is no need to cause further noise by discussing it further.,
<cjwatson> particularly since I can see for myself that the two people who responded to Randall most quickly joined the channel immediately before him and haven't been here before ...
<brewmster> cjwatson: there is no need to cause further noise by discussing it further.,
 * jdong takes a pass through the SRU queue
<jdong> Is LP behaving funky? https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text= has two identical looking php5 packages
<cjwatson> jdong: that's permitted in queues
<cjwatson> only one of them gets to be accepted, of course
<jdong> cjwatson: oh, interesting; didn't know that
<cjwatson> check that they have the same content?
<kees> EdwinGrubbs: hola!
<jdong> yep, the diffs look the same
<EdwinGrubbs> kees: hi, Launchpad is discussing whether to switch to the apport (problem_report) format for its oops tool, which puts the python traceback, cgi variables, sql query times, etc. for a single failed request in one file.
<EdwinGrubbs> kees: there are certain limitations to the apport format, and I wonder whether we would be better served by wrapping problem_report, pushing changes upstream, or just using another format.
<EdwinGrubbs> kees: I haven't seen pitti in IRC. Who all would be good to CC our oops tool discussion?
<EdwinGrubbs> one issue I see with problem_report is that it only really supports parsing a single level of field names and values, so parsing a complex value is nonstandard.  The other is that it doesn't seem to let you set the content-type for a file attachment.
<kees> EdwinGrubbs: I think extending apport would be great.
<kees> EdwinGrubbs: pitti is very responsive to patches. you could email ubuntu-devel and CC him, maybe
<EdwinGrubbs> kees: ok, thanks, I'll do that.
<kees> EdwinGrubbs: okay, cool.
<achiang> EdwinGrubbs: pitti is on holiday currently
<EdwinGrubbs> achiang: thanks for the info
<achiang> sure
<kees> hm, is umask anywhere in /proc for a process? doesn't seem to be.
<superm1> cjwatson, this might be in the realm of 32-bit is undefined, but from my experiments of throwing the 64 bit grub efi on a 32 bit CD and making it multi-catalog, it looks like the 32-bit kernel doesn't load with efi, missing /sys/firmware/efi and all the accompanied dmesg listings about memory mapping with EFI
<Chipaca> looks like I need python-gconf-dbg and it isn't built. Is that a bug, or am I missing something?
<cjwatson> superm1: I looked into the kernel a bit.  It refuses to load EFI unless the boot loader signature passed to it says EL32 (for a 32-bit kernel) or EL64 (for a 64-bit kernel); grub's x86_64-efi build passes EL64
<cjwatson> superm1: but that is not the worst problem
<cjwatson> superm1: the EFI runtime services calls are just function pointers.  If you have a 64-bit EFI implementation, those functions are very likely to contain 64-bit code.  You can't call them from a 32-bit kernel
<superm1> cjwatson, oh yikes- yeah that could be quite troublesome then
<cjwatson> I don't see any way we can cope with this
<cjwatson> if you have 64-bit EFI and want to boot a kernel in EFI mode, as far as I can see it has to be a 64-bit kernel and that's really all there is to it
<cjwatson> so we'll need to be addressing whatever problems you have that make that difficult
<cjwatson> indeed I just checked the UEFI spec and it requires this
<cjwatson> "For an operating system to use any UEFI runtime services, it must:
<cjwatson> [be] In long mode, in 64-bit mode
<cjwatson> "
<cjwatson> that's in the "x64 Platforms" section, 2.3.4
<superm1> OK, i'll take that back to my team and see what we can come up with.
<mneptok> cjwatson: thanks for the reply. i answered my own question with a VM yesterday.
<mneptok> cjwatson: your late reply meant i could not be lazy, which creates a very interesting Slacker Feedback Loop. ;)
<nemo> Does ubuntu have any way to extract an update priority in a similar fashion to Mint's update manager w/ its colour and number coding?  Even a commandline thing would be fine
<nemo> I'd just like to know if that is a capability it has
<sladen> nemo: I think it's on the list.  Eg. IIRC the colour was from some fairly simple heuristics (eg. is a core library)
<nemo> sladen: oh...
<nemo> sladen: I thought they were doing it based on "is this an exploit fix"
<nemo> versus "is this a stability only issue" or "is an enhancement"
<nemo> sladen: 'cause really, that's what our admins want to know - is this something crucial that has to be applied to the server right away
<nemo> (and w/o reading each description to find them)
<sladen> nemo: if it's post-release, it's a security fix.  If it's pre-release it's a bug-fix enhancement
<sladen> bug-fix or enhancement
<Chipzz> nemo: if your admins are blindly applyin security updates, I would have my concerns about their skills...
<nemo> Chipzz: well, these are windows admins, so I don't know their minds
<nemo> but my instinct is their thought process is "we should update as little as possible on running servers, unless there is a security issue"
<nemo> but, sounds like what sladen is saying is all post-release updates should be considered security issues and thus must be applied.
<nemo> odd, I'd swear I've seen post-release updates that wouldn't really fit that
<Chipzz> sladen: you're ignoring SRU's
<sladen> nemo: https://wiki.ubuntu.com/StableReleaseUpdates
<nemo> sladen: heh. "Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel). "
<nemo> sladen: but anyway, sounds like you're saying the only method to differentiate right now is read the description and linked LP and use your judgement
<sladen> nemo: or get them to sign up to  http://www.ubuntu.com/usn
<cjwatson> nemo: all security updates will come from RELEASE-security rather than RELEASE-updates
<cjwatson> visible in apt-cache policy output, among others
<nemo> cjwatson: thanks
<YokoZar> what's the name of the program that pops the broadcast accounts dialog
#ubuntu-devel 2010-09-11
<wgrant> slangasek: Timeouts with an OOPS ID? Or timeouts with a "Sorry, we couldn't connect to the Launchpad server" sort of thing?
<slangasek> wgrant: "couldn't connect"
<wgrant> Ew.
<wgrant> Had a report of that last night, also while filing a kernel bug.
<wgrant> Interesting.
<fagan> I get that a lot on the edge server
<slangasek> I gather that the kernel's apport bits are now quite large :)
<fagan> if you keep trying you get it eventually
<wgrant> slangasek: Do you recall how big it was in this case?
<fagan> the edge sever has a much lower time out than the main server
<slangasek> wgrant: hum, I don't know anywhere that it would've said
<wgrant> slangasek: Doesn't apport normally say before it sends?
<slangasek> I don't know :)
<wgrant> Heh.
<slangasek> maybe!  I didn't look
<wgrant> fagan: This is far nastier than a normal timeout, I'm afraid.
<slangasek> I didn't hit the error until after it had sent
<slangasek> the timeout I was getting was after the data had been uploaded, and I was trying to submit the bug /submission/
<fagan> Oh couldnt connect is a strange one
<penguin42> wgrant: Sounds like what I was reporting earlier and last night ?
<wgrant> penguin42: Exactly.
<wgrant> slangasek: Oh, that's even worse.
<wgrant> Yay.
<fagan> did anyone ask on #launchpad?
<wgrant> Yes, that's why I'm here.
<wgrant> Because slangasek ran away.
<slangasek> fagan: I did, but then I retracted because the next attempt to post went through :)
<fagan> oh
<slangasek> bug #635379, fwiw
<ubottu> Launchpad bug 635379 in linux (Ubuntu) "intel i945 GPU lockup, requires reboot to restore X" [Undecided,New] https://launchpad.net/bugs/635379
<slangasek> but before that, it was persistent for ~30min or so
<wgrant> This may be bad firewall rules again.
<atari2600a> hey
<atari2600a> empathy is accidentally my entire config upon restart
<atari2600a> more specifically my accounts
<atari2600a> any workaround until the package gets fixed?
<dylan-m> atari2600a: I think you accidentallied a verb, but I'd guess the likeliest place to ask that question is #ubuntu+1 (the discussion / support / trying to use the thing channel for 10.10)
<atari2600a> thanks dylan
<cjwatson> just so people know: bugs aren't being auto-closed by uploads right now, so you have to close them manually.  A Launchpad fix is on its way
<cjwatson> bug 634045
<ubottu> Launchpad bug 634045 in Soyuz "Regression: Launchpad-Bugs-Fixed header no longer works" [High,Triaged] https://launchpad.net/bugs/634045
<gellmar> hi! Are here any maintainers for UDFtools?
<roxdragon> ih
<Pretto> where do i find information about hal not installed by default and what is used in it's place?
<fagan> Pretto: hal was replaced by a few things really
<fagan> read the top note here to get the list http://freedesktop.org/wiki/Software/hal
<Pretto> fagan: thank you
<fagan> np
<Damascene> hi,
<Damascene> I wish you release ubuntu less often. It's hard to follow all these releases for paid persons rather than volunteers
<Damascene> too much regression
<G> Damascene: the LTS releases are designed for people that need stability and long term support (LTS)
<ari-tczew> Damascene: if you want to give an idea about longer development cycle, let's use listmails discussion or use brainstorm.
<ari-tczew> btw. I also think that development cycle should be longer.
<Damascene> ok, thanks both
<G> rapid releases have kinda put me off a little too, so often features look unpolished
<G> (in my eyes)
<G> but not just Ubuntu
<Damascene> and any way every one can get the latest version from some launchpad ppa
<directhex> Damascene, that only works for leaf packages. personally, i like the short release cycles, as it encourages setting and reaching goals
<Damascene> you might be right. but the current release system is too short I think
<Damascene> you know the default for many people is to update when there is new release and that might case many problems for them
<directhex> Damascene, if people want long-term supported releases, use long-term supported releases (6.06, 8.04, 10.04)
<Damascene> well as a user we just call it old release :)
<Damascene> any way I'm thinking of creating a wiki page to start a discussion about that
<directhex> the mailing list is the correct arena for this
<ChogyDan> Damascene: it is probably better to focus on specific packages then the release as a whole.  Projects should follow their own release schedule, no?
<directhex> although people will just say the same thing - use LTS if you want long-term support
<Damascene> ChogyDan, many developers and users complain about not having the last version in the release. why not let them do it in their ppa and blame it on them.
<Damascene> the first thing they say when you try to report but is to use the last version they have. not Ubuntu's one.
<ChogyDan> Damascene: that sounds like an argument for shorter releases, I don't think I follow
<Damascene> no what I mean is to let the developers to handle the software release and Ubuntu to handle the core. and release less often.
<Damascene> brb
<directhex> i think mdz argued for the latter part
<directhex> problem is upstreams are awful at distro integration
<directhex> and, again, it can only work for leaf packages
<Chipzz> Damascene: IMO, you can't have your cake AND eat it
<Chipzz> which means: either you choose stability, ie LTS, or you choose in between releases, with the possibility of regeressions
<Damascene> why not using decentralized Ubuntu? developers control their own apps releasing
<Damascene> then the problems is not ubuntu's problem
<Damascene> directhex, if developers don't want their programs to be in the most popular open source OS it would be awkward
<ogra_cmpc> Damascene, i think yous problem is your view here ... you see apps and core bit totally ignore integration which is the main part ubuntu devs are doing ... ubuntu featurs usually consist of a combination of a bunch of apps with added glue inbetween
<ogra_cmpc> if you let one app move forward independently the feature can break ... you cant guarantee even a minimal level of QA etc
<Damascene> why don't we start with an another repo like universe where developers can just push their apps there and see the outcome? it would be optional and for testing. when I had to install the latest evolution I just had to add it's ppa. it seems simple to have a universal open to developers ppa
<Chipzz> also, with a decentralized approach you also loose all Q&A
<Chipzz> same problem
<Chipzz> Damascene: you ignore the gist of the problem, really
<Chipzz> I think you lack a basic understanding of what is really the issue here
<Chipzz> which is a lack of manhours
<Chipzz> and he necessity for Q&A
<Damascene> Chipzz, so in the current state Ubuntu is doing QA of other apps?
<Chipzz> they're doing at least some form of Q&A on the packages, not necessarily the apps
<Damascene> why do you thing the developers can not do that if you linked them directly with the users?
<Chipzz> like I already told you, lack of manpower
<ogra_cmpc> the scenario you describe above already exists, we call it launchpad :)
<ogra_cmpc> every upstream dev is free to add his/her project and provide daily builds, stable builds etc in a ppa
<ogra_cmpc> why would you want to make all of universe unstable if single people only need single apps
<Damascene> ogra_cmpc, but that should be done by manual for every package
<ogra_cmpc> it is already happening for some
<tumbleweed> Damascene: it has to be manual. Every package is different
<Damascene> the idea for now is to have another repo for now with the latest release from developers
<ogra_cmpc> but be sure ubuntu as a distro wont give up its stability for a permanently rolling archive
<ogra_cmpc> Damascene, https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted
<Damascene> what I see now look like this. developer release package version 1 stable and 1.5 in testing. ubuntu has the package version 0.5 stable and 1.0 in testing. ubuntu users are using 0.5 and find bugs while there is 1.5 going to be released
<ogra_cmpc> its not a matter of ubuntu but a matter of devs making use of the reciepoes for daily builds
<ogra_cmpc> *reciepes
<Damascene> ogra, developers are not releasing daily! they have stable and testing too.
<ogra_cmpc> up to them
 * ogra_cmpc only releases stable 
<ogra_cmpc> everything else is development ;)
<Damascene> I just hoped to find something to release the gap
<ogra_cmpc> see the help page above
<ogra_cmpc> its supposed to close the gap
<Damascene> * lower the gap
<Damascene> yes the word is close
<Damascene> :)
<ogra_cmpc> but it needs adoption on the developer side
<ogra_cmpc> which you wont get from many sides due to political reasons
<ogra_cmpc> which is alo not a job for ubuntu to solve
<ogra_cmpc> *also
<Damascene> let me gather my ideas and start a wiki page. things need to be sorted in some place.
<Chipzz> Damascene: look, it's very simple; 0.5 gets released with the LTS, and 1.0 gets released by upstream after. It's simply not desirable to move 1.0 to the LTS, because the problems with 0.5 are known and documented. If you were to push 1.0 to LTS for every single piece of software, your LTS would hardly be stable
<penguin42> that's what backports for isn't it?
<Chipzz> penguin42: not exactly, no
<penguin42> Chipzz: But partially, yes ?
<Damascene> :)
<Chipzz> penguin42: if you're going to push every 1.0 release into backports, you might just as well run a non-LTS release, or even a development release
<Chipzz> and exactly what have you gained then?
<ogra_cmpc> more workload :)
<Chipzz> :)
<Chipzz> and from the user POV, you have gained little to nothing
<penguin42> Chipzz: Yeh but it helps for the few packages which get a really major useful upgrade
<ogra_cmpc> which in turn boils down to the "lack of manhours" from above
<tumbleweed> penguin42: all packages get really useful upgrades, but they also get new bugs
<Chipzz> penguin42: if you put package a into backports, another user is going to whine to get package b in too, and another package c, ...
<Chipzz> I think this discussion is pointless and silly
<Chipzz> Damascene fails to understand what a release is, and fails to appreciate the amount of work it takes
<Chipzz> and the discussion is going around in circles
<Damascene> Chipzz, developers releasing with bugs is because of the lack of user testing
<Damascene> thanks for the nice discussion.
<Chipzz> Damascene: like I said before, your POV is basically "I want more updates" and the answer to that is basically "Can't do due to a lack of manpower"
<Chipzz> and this isn't going to get fixed unless canonical hires more ppl
<penguin42> how much automated testing happens?
<Damascene> not exactly. the update are their but needs some of Ubuntu man power for testing instead of providing packages that the upstream do not want to support
<Damascene> * there
<Damascene> I know this is not Ubuntu only problem and it can not solve it alone. developers will have to make sure there packages are really stable
<ogra_cmpc> Chipzz, why would it be a matter of canonical hiring anone ?
<ogra_cmpc> its a matter of having more devs, no matter if they are employed by canonical, TI, dell, or are hobbyists
<Chipzz> ogra_cmpc: right; but that would be the easiest solution
<Chipzz> ogra_cmpc: the quality of packages hardly is garantueed when a package is made by a volunteer
 * ogra_cmpc disagrees
<ogra_cmpc> a volunteer often is more intrested in his package than someone being paid for maintining other peoples software imho
<tumbleweed> Chipzz: where does debian's legendary stability come from then?
<Chipzz> ogra_cmpc: do I really need to point out the (perceived) lack of quality of a lot of packages in universe/multiverse?
<Chipzz> tumbleweed: do you really want an answer to that?
<mr_pouit> yesâ¦
<tumbleweed> Chipzz: I'd say that's because there aren't enough people for the size of universe
<ogra_cmpc> Chipzz, do i need to point ut the overworkedness of many paid canonical devs ?
<Chipzz> IMO the better quality of packages in debian is because of the New Maintainer process, which assures people are intimately familiar with the debian policy because they get asked questions about it during the course of the NM process
<Chipzz> ogra_cmpc: I am not pointing a finger at Canonical Employees here
<Chipzz> what I *am* saying is that the barrier to becoming a MOTU is much lower, resulting in underqualified MOTU's
<Chipzz> not all of them, mind you
<ogra_cmpc> well, you are assuming canoinical hiring more employess would help in any way
<tumbleweed> probably true. But also not enough of them. I see more neglected packages than packages where MOTUs screwed up
<ogra_cmpc> canonical is a company working for revenue ...
<ogra_cmpc> adding more people requires to make more of it
<ogra_cmpc> the only solution can be to get more voluteers
<Chipzz> ogra_cmpc: it would help the quality of packages, since Canonical would presumably only hire very qualified ppl
<directhex> canonical employees are not better by definition than community MOTU
<ogra_cmpc> no matter if for main or universe
<directhex> IME, anyway
<Chipzz> directhex: I would hope they are, or Canonical has a serious problem screening new hirees
<ogra_cmpc> Chipzz, it wouldnt ...
<directhex> Chipzz, again, my experience says otherwise.
<directhex> the biggest problem with universe is that people upload to it
<ogra_cmpc> canonical hires the best for the task if it can ... but people plainly tasked with only packaging are very very rare in the company
<penguin42> I guess it depends; some community guys are full time experienced programmers anyway - they just don't happen to work for canonical
<directhex> universe quality is at its worst when people upload stuff directly which isn't in debian, then never maintain it long term
<directhex> second worse is when they introduce an ubuntu delta from debian, then never notice that it needs an update (but there is more chance of it being noticed than when the upload is ubuntu only)
<ogra_cmpc> directhex, that applies to main as well
<directhex> third worst is when ubuntu distro changes mean a direct unmodified debian package doesn't work, even though the package itself is unmodified
<directhex> ogra_cmpc, yeah, but at least people are meant to care more about main. i try not to abuse my upload powers
<Damascene> https://wiki.ubuntu.com/damascene/Decentralized%20Ubuntu
<Damascene> I made that page for the subject
<ScottK> Chipzz: The perceived lack of quality for Universe/Multiverse is due to lack of manpower and packages being left unmaintained.  It is (almost always) not because someone is working on the packages and doing it badly.
<ScottK> Also getting hired by Canonical doesn't give anyone upload rights.  MOTU/Core-dev that are employed by Canonical get approved the same way community people do.
<Chipzz> ScottK: like I pointed out before, my comment wrt Canonical hiring ppl should be interpreted in terms of Canonical having lots of knowledgable ppl, which will be the ones reviewing applications, and as a result them hiring only knowledgable ppl
<Chipzz> as opposed to ppl in MOTU who may be rather new to packaging
<Chipzz> I was in no way implying that Canonical employees get a different treatment due to being employed by Canonical, but rather that it stands to reason that Canonical employees deliver high-quality work
#ubuntu-devel 2010-09-12
<ScottK> Chipzz: That's one theory I guess.
<Kalidarn> just wondering if it'd be acceptable to open a bug for this, encrypted LVM in ubuntu 10.04 seems to break suspend mode
<Kalidarn> https://help.ubuntu.com/community/EncryptedFilesystemLVMHowto#Some%20Notes it says here "Suspend or suspend2 don't work with this configuration. If you have a working configuration with suspend or suspend2, please append to this article or post a separate one." I'm using Ubuntu 10.04 LTS.
<Kalidarn> it does say there in the wiki that it does not work
<Kalidarn> I'm just wondering if there's a technical reason as to why it doesn't work
<Kalidarn> ie something related to security, the swap file is encrypted so it shouldn't be an issue suspending to it.
<Kalidarn> it'd be also interesting if someone with a 10.10 release could test it, incase it has been fixed.
<Kalidarn> too much info relates t < 8.04 which was back when we had HAL
<riyaz> hi everyone i am here to get some idea about contributting to open source by the way i am interested to learn core programming ....anybody can help??
<chris_osx> riyaz: do you mean kernel hacking?
<riyaz> chris_osx:no no just to contribute some applications ..
<damascene> hi,
<Damascene> hi, I made a summary page about decentralized Ubuntu package system https://wiki.ubuntu.com/damascene/Decentralized%20Ubuntu please look at it.
<bonii> I had a problem with sound in headphones on my new asus eee pc running lucid, I followed instructions here https://wiki.ubuntu.com/Audio/InstallingLinuxAlsaDriverModules, the module is only available for 2.6.32-24 kernel and currently on lucid I am running 2.6.32-25 kernel, so will the fix be patched into this kernel, please advise
<fagan> bonii: if it doesnt work in maverick then you can make a bug report about it
<Chipzz> bonii: pls don't abuse this channel for bug reports, especially not for bug reports about stable..
<Chipzz> err, s/bug reports/support/
<fagan> Chipzz: I was just saying to report a bug if its not in maverick
<fagan> and the channel was quiet so its all good
<Chipzz> fagan: no. this channel being quiet is no excuse for abusing it
<fagan> Chipzz: I wasnt
<Chipzz> fagan: and my comment wasn't aimed at you...
<fagan> oh sorry
<bonii> I am sorry if I abused something, I just thought of cross checking with the devs before filing a report, whether the fix was in the process of being pushed
<bonii> Sorry if it went againts the channel policy
<fagan> bonii: well the kernel version should be fine for maverick
<Chipzz> bonii: it's good practice to read a channels' topic before talking in it
 * Chipzz wonders why ppl never do that. *sigh*
 * bonii goes to read the topic
<fagan> Chipzz: its a bad habit really for people
<Chipzz> that last thing was a generic comment, not aimed at you specifically bonii
<fagan> they see the channel name and think this one can give me the answer
<bonii> Chipzz: :)
<Chipzz> I am really really REALLY considering a patch to xchat which pops up a big warning to read the channel topic upon starting it, with a greyed out 'ok' button that only gets enabled after 10 seconds, and the only way to turn it off a hidden and undocumented gconf option
<fagan> Chipzz: hmmm people would still probably ignore it
<Laney> ...the original query wasn't that bad
<fagan> its one of those things that ive come to accept that its always going to happen
<Laney> this is a gross overreaction
<Chipzz> Laney: I'm just ranting about no-one caring about topics anymore, not so much about the original query ;)
<Laney> an off-topic rant about people being off-topic
<Laney> hmm
<fagan> :)
<Chipzz> bonii: about your original query; #ubuntu is for general support; if you don't get an answer there, you could try #ubuntu-kernel (not 100% sure if it's on-topic there)
<fagan> (it is on topic for that channel)
<Chipzz> since #ubuntu-kernel's topic doesn't specify wether it's only about stable or devel too, and the wiki page mentions the "The Ubuntu Kernel Team" and "Crack of the Day", I'ld say it is
<bonii> Chipzz: Thanks, I will check that out
<cjwatson> Chipzz: honestly, most of these OT questions could be defused with much less noise in the channel if you'd be a little bit less hair-trigger-annoyed in your replies.  A polite redirection suffices and is more within the spirit of the code of conduct.  There's no need to rant at people.
<cjwatson> the person who came in was apologetic and polite when corrected
<Chipzz> cjwatson: and I did point him in the right direction
<cjwatson> you were unnecessarily vitriolic.
<cjwatson> please try to refrain from that in future
<cjwatson> (yes, you did point him in the right direction)
<Chipzz> cjwatson: IMO, much of these OT questions could be avoided by simply setting the channel +s
<Chipzz> so it doesn't show up in the server list of channels
<cjwatson> I don't think that's necessary.  The OT questions are not a significant contributor of noise.  The attempts to police them, however, do seem to be
<cjwatson> I frequently read through long backlogs of this channel to find a small amount of OT questions and a huge screed of flamewar about whether it was appropriate or not
<cjwatson> being a bit more relaxed in directing people to where they can best get help would do everyone a lot of good, I think
<cjwatson> I've bitten my tongue about it for some time because I don't want to be part of the same problem
<cjwatson> but the contrast with some other channels where somebody comes in with a question, we say "sorry, this isn't really the right place, try #whatever", and they say thanks and leave, is quite marked
<fagan> I tend to do that but if it can be answered in one line anyway I just answer and say this isnt the place
<fagan> if no one answers
<Chipzz> cjwatson: I did say it was not the place, and I did point him in the right direction. and the rant wasn't directed at him specifically
<Chipzz> or is it my use of the word "abuse" you're objecting to?
<fagan> Oh yeah I mean say that I was just shortening it
<Laney> The whole diatribe was unnecessary. If you'd have just redirected him in one line then nobody would have got upset.
<fagan> True but I answered the question in one line instead and I thought that it was ok
<fagan> but then 10 mins later it spawned the other thing
<Laney> fagan: yes, it should have been the end of it
<Chipzz> fagan: I don't think this is about you :)
<fagan> :)
<Laney> Enough about this for now though, please
<fagan> yep
<ryanakca> Anybody know which package the Kubuntu posters are in on the LiveCD?
<Chipzz> ryanakca: I don't, but have you tried dpkg -S?
<ryanakca> Chipzz: I don't have an Ubuntu LiveCD with me, only a box of Kubuntu ones (I'm trying to print one off for Software Freedom Day/week and don't know what package to download to get it)
<Chipzz> wouldn't the Kubuntu posters be on the Kubuntu CD instead of on the Ubuntu CD? :)
<shadeslayer> Chipzz: youd think so
<shadeslayer> but they are on the Ubuntu CD... along with Xubuntu ones
<charlie-tca> that's not the "example-content" file, is it?
<shadeslayer> charlie-tca: aye
<shadeslayer> its a pretty nice set
<Chipzz> ryanakca: if you know the filename, you can use packages.ubuntu.org
<charlie-tca> package name is "example-content
<charlie-tca> "
<ryanakca> Ew. The example-content still uses old artwork and thinks we use Konqueror as our file manager.
<ryanakca> (On Lucid anyways)
<shadeslayer> ryanakca: time for a update to that package then i guess :P
<ryanakca> Quite :)
<ryanakca> shadeslayer: I guess I'll have to make my own poster and update the package with it...
<shadeslayer> :D
<shadeslayer> ryanakca: poke sheytan with the artwork stuff
<shadeslayer> he is really really good at it
<lex79> cjwatson: can you add libbluedevil and bluedevil to the set of kubuntu packages please? :P
<lex79> thanks
<Jarvis> any core devs about? i'm trying to chase somone to take a look at Bug #539814
<ubottu> Launchpad bug 539814 in tar (Ubuntu Lucid) "tar: futimens() with a bad file descriptor (AT_FDCWD) causes bootstrapping failure with kernels < 2.6.22" [Medium,Triaged] https://launchpad.net/bugs/539814
<dupondje> pfft :( sd card on my laptop is so broken in recent kernels :(
#ubuntu-devel 2011-09-05
<TheMuso> Apteryx: I think that rule is somewhat obsolete, and its not used by anybody I know who packages pulse for Ubuntu, myself being one of them.
<TheMuso> Apteryx: So I wouldn't worry about it.
<Apteryx> TheMuso... so shouldn't it be cleaned out?
<Apteryx> :)
<TheMuso> Apteryx: Debian may still use it, so we leave it there to make sure the delta between Ubuntu and Debian is minimal.
<Apteryx> TheMuso, ok.
<Apteryx> TheMuse so in order to remove obsolete patches, I just delete them from the source folder?
<Apteryx> (I was commenting them in the series file, but they were applied anyway)
<TheMuso> Apteryx: Yes, and remove them from the series file in debian/patches.
<Apteryx> I'd still like to get the big picture about what is going on during build process... pbuilder calls the rule file as a makefile... and then all the job gets done from there (and included *.mk) ?
<TheMuso> Yes, cdbs does a lot of the heavy lifting for us.
<Apteryx> Is the rule file cdbs tailored? Or it could be used without it also?
<Apteryx> Ok, just reread the cdbs part and the ./debian/rules file seem to be cdbs specific ;)
<Apteryx> Still think the rpmbuild system was easier to figure out, though :D
<Apteryx> TheMuso thanks for helping :)
<TheMuso> Apteryx: np, and cdbs doens't have to be used, but the rules file would be bigger as a consequence.
<TheMuso> Having said that, it may be much the same size if the new debhelper 7 system was used.
<TheMuso> Rpm only having one spec file for everything seems ilogical to me.
<TheMuso> illogical
<Apteryx> TheMuso for a newbie like me it was simpler, everything labeled and put in the same place ;)
<Apteryx> TheMuso, also everytime I start pbuilder it seems to reinstall the dependencies... I've seen a bit about pbuilder sessions to save the chroot state, but did not really understand how to do that.
<TheMuso> I don't know much about pbuilder, I don't use it. I use sbuld instead.
<TheMuso> sbuild
<Apteryx> TheMuso, would you recommend it over pbuilder?
<LaserJock> Apteryx: sbuild usually takes more hard drive space, but it can be faster and in some way simpler to use
<Apteryx> LaserJock, ok.
<Apteryx> Other more general question: is it possible to build also x86_64 packages from a 32 bits host?
<LaserJock> I'm not positive but I don't think so. You can go the other way around, x86_64 can build i386 too
<TheMuso> The only way it could be done is if you were to set up a cross-compiler.
<TheMuso> But I am still not 100% sure about that, given the different number of registers...
<Apteryx> TheMuso, I've deleted the 0096-lp533877-handle-digmic.patch in /debian/patches and also in the /debian/patches/series file... and it still fails with: "Patch 0096-lp533877-handle-digmic.patch does not apply (enforce with -f)
<Apteryx> don't know where its coming from to haunt me ;)
<TheMuso> Apteryx: Do you have any patches applied in your current working tree? TO be sure, look in the .pc directory.
<Apteryx> TheMuso, no, not that I can see. (Would this be in the pbuilder building tree or already present?)
<TheMuso> Apteryx: Oh right, you are getting that when you test build...
<Apteryx> TheMuso, yes.
<TheMuso> Apteryx: How are you running pbuilder?
<Apteryx> TheMuso... you just rang the bell ;)
<Apteryx> TheMuso, pbuild --build pulseaudio... .dsc
<Apteryx> ;)
<TheMuso> ok.
<Apteryx> I guess the .dsc needs to be refreshed first?
<TheMuso> It seems the patch is still in your source package for some reason.
<TheMuso> Why I don't know.
<TheMuso> Yes.
<TheMuso> That would help.
<Apteryx> I'll try that.
<Apteryx> Thanks.
<RAOF> If you installed an amd64 kernel you could easily build x86_64 packages in a chroot (such as provided by sbuild or pbuilder).  There be dragons lurking in that area, though, particularly if you're using proprietary drivers.
<Apteryx> RAOF, ok. I don't see why would proprietary drivers affect the builds? (If these builds don't depend on them)
<RAOF> Apteryx: Oh, no.  Proprietary drivers won't affect the builds; they just might not work properly if you're using a 32bit userspace with 64bit kernel.
<RAOF> So the *builds* would work, but 3D, X, etc might not :)
<Apteryx> RAOF, ok. Never attempted to run 3D in a chroot anyway. Anything is possible in a chroot?
<Apteryx> (with /sys and such bindings) ?
<RAOF> Everything except the kernel.  You'll need to be running the 64bit kernel.
<Apteryx> Ok. Thanks :)
<Apteryx> TheMuso, any flags that I should set for sbuild? It says "no distribution defined".
<Apteryx> My command right now looks like this: sbuild -As -p successful  pulseaudio_0.99.3-0ubuntu1.dsc
<TheMuso> Apteryx: You need to use the -d flag. man sbuild for more info.
<Apteryx> TheMuso, I recall there was a command to return distribution name, but forgot it... Any idea what it is?
<RAOF> You can also set the default distribution in ~/.sbuildrc
<Apteryx> TheMuso, found it, it's `lsb_release -cs`
<Apteryx> RAOF, cool
<Apteryx> anyone knows a good tuto about getting start with sbuild? Now it tells me I don't have chroots defined in /etc/schroot/schroot.conf
<Apteryx> This might be enough to get me started: https://wiki.ubuntu.com/DebootstrapChroot
<RAOF> Apteryx: mk-sbuild
<RAOF> Apteryx: There's a wiki page on sbuild, but really all you need to know is mk-sbuild (unless you're doing freaky stuff)
<Apteryx> RAOF, ok ;)
<Apteryx> Hello, the debuild manpage seems incomplete. What exactly do the -S, -a, and -s flag do?
<Apteryx> My command is debuild -S -sa
<Apteryx> I guess one of these is to sign the packages
<Apteryx> -s maybe
<Apteryx> Oh... these are dpkg-buildpackage flags!
<Apteryx> the manual of dpkg-buildpackage does not explain the -sa flag either :S
<RAOF> You sometimes have to traverse the stack there â¹ - dpkg/debuild pass the unrecognised flags down to their tools
<RAOF> -sa is âinclude .orig.tar.gzâ, so it's probably a dpkg-source flag.
<Apteryx> RAOF, ok!
<RAOF> Bah, no of course.
<RAOF> It's actually a dpkg-genchanges flag.  It sticks the .orig.tar.* in the _changes_ file1
<Apteryx> ok. It's listed in the dpkg-source manual too!
<Apteryx> It says "use the .tar file to generate the diff"
<Apteryx> Hehe, so we don't really know which uses it ;)
<Apteryx> RAOF, if I run sbuild with the '--purge-deps successful' shouldn't the dependencies be preserved in chroot as long as the build does not succeed?
<RAOF> Apteryx: But you'll be using a throwaway overlay chroot, which will likely have been cleaned up.
<Apteryx> my exact command is: sbuild -As -p successful --purge-deps successful -d natty-i386 ../pulseaudio_0.99.3-0ubuntu1.dsc
<Apteryx> What do I have to tell it if I want it to preserve my dependencies while I test a build that fails?
<Apteryx> Cause right now it's downloading & installing 214 dependencies everytime... not exactly productive xD
<Apteryx> On fedora, mock at least cached the packages (though it reinstalled it).
<Apteryx> sbuild also says: "Not cleaning session: cloned chroot in use" when my build fails
<RAOF> Apteryx: Oh!
<RAOF> Apteryx: Yeah, right.  You want to do something about that ;)
<RAOF> There are a couple of options; you can edit /etc/schroot/sbuild/fstab and bind-mount /var/cache/apt/archives, and your existing apt cache will be available in the chroot.  Or you could do what I do, which is to run squid-deb-proxy and add an /etc/apt/apt.conf.d/ snippet setting that proxy.
<Apteryx> So I've added this line: /var/cache/apt/archives /var/cache/apt/archives none rw,rbind 0 0
<Apteryx> We'll see if it helps ;)
 * micahg uses apt-cacher-ng
<pitti> Good morning
<pitti> mdke: oh sure, will have a look
<Apteryx> RAOF, sorry to bother yet again. Still having issues with sbuild ;)
<RAOF> Apteryx: Ah, you'll need to do something slightly special with your fstab?
<Apteryx> yeah it's still downloading :(
<Apteryx> but I have a new issue with gpg
<Apteryx> Do I have to do something special for the fstab to be read?
<Apteryx> logout / login or something?
<RAOF> Bah, no, sorry.
<RAOF> I was forgetting the context that schroot's fstab is interpreted in.
<Apteryx> what do you mean?
<Apteryx> I thought it should have worked
<RAOF> I was thinking of my local-packages thingy, which *does* need special handling.
<RAOF> Yeah, I think it should work.
<Apteryx> i used "rbind" instead of bind, because /sys was already mounted with that
<RAOF> Yeah, sorry, I think that what you've done should work.
<RAOF> What was your problem again?
<Apteryx> 1st problem is dependency being redownloaded at every sbuild try
<Apteryx> 2nd problem is gpgv issue: http://pastebin.com/qAyTBsfG
<Apteryx> man... loosing patience. time to sleep ;)
<Apteryx> RAOF, thanks for all the hints! I'm sure I'll get over it tomorrow.
<micahg> pitti: hi, good morning, would you mind if we pushed back the final langpack push for maverick till the end  of the month?
<pitti> micahg: sounds fine to me; I'll just follow your plan there
<micahg> pitti: thanks, I'll keep you updated as soon as I have a new timeline
<RAOF> Oh, dear.  qt4-x11 has a different API on arm.  Joy!
<pitti> RAOF: trying to create .symbols files?
<pitti> since natty or so, the symbols files are different on all architectures
<RAOF> pitti: No, trying to work out whether a bunch of doko_ 's FTBFS filed against mesa are actually a problem in mesa.
<RAOF> This is bug #840679, by the way.  qt4-x11 broke API and ABI on arm in 4:4.7.3-4ubuntu1
<ubottu> Launchpad bug 840679 in qt4-x11 (Ubuntu Oneiric) "conflicting types in GLES2/gl2.h and GL/glext.h" [High,Confirmed] https://launchpad.net/bugs/840679
<micahg> RAOF: here's a little writeup that janimo did for the Ubuntu Developer week about it if it helps any: https://wiki.ubuntu.com/ARM/FTBFS
<RAOF> micahg: Ah, good.  That's known, and I'll re-assign any further ftbfs bugs misfiled against mesa to you :)
<micahg> heh, I still haven't successfully fixed any of those yet :)
<RAOF> They're non-trivial.
<RAOF> The whole fixed-function pipeline that a lot of the old GL-using programs will be using is *gone* in GLES2.
<RAOF> You get to rewrite things as vertex programs!
<micahg> sounds like fun...
<didrocks> good morning
<mdke> pitti: great, thanks
<doko_> RAOF, it might be wrong; I found in another report that Qt is ported to GLES, but e.g. vtk is not ...
<doko_> maybe rsalveti does know a bit more
<RAOF> doko_: Yeah; micahg pointed me at https://wiki.ubuntu.com/ARM/FTBFS which you'll notice has a section "OpenGL and Qt"
<RAOF> :)
<RAOF> Basically, anything on arm which directly or indirectly includes that Qt header and which uses, directly or indirectly OpenGL is going to blow up in roughly the same way.
<dholbach> good morning
<RAOF> I think that anything that's currently *built* and uses that bit of Qt as well as GL will either fail to load with conflicting symbols, or, even better, not work in an even less obvious fashion, like not drawing properly.
<diwic> Could I have a core dev upload pulseaudio for me? PulseAudio as of this morning fails to start due to bug #841649
<ubottu> Launchpad bug 841649 in pulseaudio (Ubuntu) "Module "module-jackdbus-detect" should be loaded once at most" [Critical,Fix committed] https://launchpad.net/bugs/841649
<diwic> and the fixed stuff is already in lp:~ubuntu-audio-dev/pulseaudio/ubuntu.oneiric
 * pitti fixes usb-creator
<diwic> pitti, IIRC I submitted a merge proposal for that a day or two ago
<pitti> diwic: oh, for the set_cursor() call?
<diwic> yes
<diwic> None -> False
<pitti> diwic: sorry, didn't check for this before, it was an one-minute thing to just fix
<diwic> better fix twice than not at all :-)
<dupondje> Somebody knows if the primary group really needs to be the same as the username ?
<dupondje> cause if its not the case, it seems to break alot of things
<cjwatson> dupondje: anything that breaks if it isn't is a bug
<cjwatson> it's a lazy assumption
<cjwatson> for instance, the Canonical data centre machines are set up such that the primary group is not the same as the username
<dupondje> well I changed my default group to 'users' instead of my own group that got created. And that caused to break adding printers/ network connections / etc
<dupondje> it just shows I don't have permissions to do those actions
<dupondje> all grayed out
<cjwatson> sure, I'm not saying it's bound to work, I'm saying that you should file bugs about such things and that people should not be rejecting them
<cjwatson> and you can quote me on that
<dupondje> hehe ok
<dupondje> well just needed to know if it was a requirement to be on your own group :)
<dupondje> seems not, so there are some bugs then :D
<debfx> cjwatson: have you got my mail about the kubuntu packageset I sent 2 weeks ago?
<cjwatson> debfx: oh, yeah, sorry, I'll have a look at it now
<debfx> thanks
<doko_> I like this one ...
<doko_> checking for 64 bit compilation flags... let's see what happens
<doko_> checking for 64 bit CFLAGS... -m64 -fPIC
<doko_> checking for 64 bit FCFLAGS... -m64 -fPIC
<doko_> checking for 64 bit CXXFLAGS... -m64 -fPIC
<doko_> checking size of void*... 8
<doko_> checking to see if we got 64 bits... oh yes
<doko_> [...]
<doko_> checking for dummy main to link with Fortran libraries... unknown
<doko_> configure: error: in `/home/packages/tmp/u/elmerfem-6.1.0.svn.5272.dfsg/eio':
<doko_> configure: error: linking to Fortran libraries from C fails
<cjwatson> micahg: re the gnash/armel build failure, what do you think is the right thing to do?  Just disable the OpenGL renderer on armel?  I see upstream has a GLES renderer, but it's not in our package yet
 * doko_ cries ...
<doko_> # Homemade configure file for the ERESI project
<doko_> yes, homemade ...
<jamespage> doko_: just got an OK on #ubuntu-release for those two FFE's (bug 837979 and bug 837990)
<ubottu> Launchpad bug 837979 in maven-plugin-tools (Ubuntu) "[FFE] Sync maven-plugin-tools 2.8-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/837979
<ubottu> Launchpad bug 837990 in jtidy (Ubuntu) "[FFE] Sync jtidy 7+svn20110807-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/837990
<Apteryx> 'morning ;)
<chrisccoulson> doko_, gcc has started crashing when building firefox - https://launchpadlibrarian.net/79032680/buildlog_ubuntu-oneiric-i386.firefox_7.0%7Eb4%2Bbuild2%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz
<chrisccoulson> every mozilla build has started failing on oneiric today
<chrisccoulson> on i386
<doko_> chrisccoulson, looking
<chrisccoulson> doko_, thanks
<chrisccoulson> i'll start a build on osageorange in a moment. i guess that anything useful from that build has probably long gone now hasn't it?
<doko_> ls -l /scratch/packages/tmp/insighttoolkit-3.20.0/obj-arm-linux-gnueabi/Wrapping/WrapITK/Modules/IntensityFilters/wrap_itkMaskImageFilterPython.cxx
<doko_> -rw-r--r-- 1 doko doko 25294455 Sep  5 14:46 /scratch/packages/tmp/insighttoolkit-3.20.0/obj-arm-linux-gnueabi/Wrapping/WrapITK/Modules/IntensityFilters/wrap_itkMaskImageFilterPython.cxx
<doko_> 30MB sources are actually better than the 300MB sources generated by ghc ...
<soren> doko_: Wow. Just... wow.
 * tumbleweed hopes doko enjoys insighttoolkit :P
 * doko_ passes tumbleweed paraview
 * tumbleweed hides
<Apteryx> Hello :) I'm currently stuck in the process of building an Ubuntu Natty pulseaudio 0.99.3 package.
<Apteryx> It used to go further, but now it fails on doing "debuild -S -sa". Result shown here: http://pastebin.com/UaAbGtzk
<cjwatson> Apteryx: so remove pulseaudio_0.99.3-0ubuntu1_i386.build from your tree - that almost certainly shouldn't be in the source package anyway
<cjwatson> maybe you ran pbuilder in the wrong directory at some point or something
<diwic> Apteryx, you might be better off starting with the daily packaging I made at lp:~ubuntu-audio-dev/pulseaudio/packaging.upstream.master
<diwic> Apteryx, IIRC that's for both Oneiric and Natty
<diwic> Apteryx, in case you get stuck starting with the Oneiric packaging
<diwic> of 0.99.3 that is
<Apteryx> cjwatson, I tried deleting all those already, keeping only source tree and .orig.tar.gz
<Apteryx> I saw somewhere I should run distclean, but this program is not installed on ubuntu.
<Apteryx> diwic, you're building this daily?
<Apteryx> diwic, so this is the latest latest I can get?
<cjwatson> Apteryx: well, the error message says otherwise, so I would check if I were you
<cjwatson> I expect that meant 'make distclean' - but that typically only removes files the build system knows about, which I wouldn't expect to include pulseaudio_0.99.3-0ubuntu1_i386.build
<diwic> Apteryx, it broke down a few days ago (I should ping someone in launchpad about that) but other than that it should be okay
<diwic> Apteryx, it does not include my jack detection patches though
<diwic> since they are not yet upstream
<diwic> Apteryx, https://launchpad.net/~ubuntu-audio-dev/+archive/pulse-testing
<diwic> Apteryx, oh, actually it's only the Oneiric ones that are down, so you can take the Natty version there and you'll have the latest (maybe lag a day or two compared to upstream)
<Apteryx> diwic, why does the version says 1:0.98 ? shouldn't it be 1:0.99.3 ?
<diwic> Apteryx, because it's taken from git master and as such does not have a fixed number
<diwic> Apteryx, you might also be interested in http://pulseaudio.org/wiki/Notes/0.99
<Apteryx> diwic, thanks. My goal was primarily to test latest pulseaudio so I'll give your ppa a shot first.
<doko_> ScottK: zope packages shouldn't stay partially converted to dh_python2, you know this calls for trouble
<ScottK> doko_: I agree.
<ScottK> I didn't say that an FFe shouldn't be given, but "It's Universe, so FF doesn't apply" is wrong.
<doko_> well, you could have told the former too ;)
<ScottK> Sure, but at the time all I had was the one bug mail to look at.
<AnAnt> Hello
<AnAnt> where do I request for a package to be added in Canonical's partner repository ?
<roadmr> hey folks! Gdk.color_parse used to return a tuple (Boolean,Gdk.Color) but at some point last week it started returning just the Gdk.Color. Anyone got any idea which package update caused this?
<cjwatson> AnAnt: um, normally only the relevant commercial partner would request that
<AnAnt> cjwatson: oh
<AnAnt> cjwatson: ok, here's the problem, Google's googleearch package sucks !
<AnAnt> cjwatson: they ship Qt libraries with the package (and for some wierd reason the package depends on alien !!!)
<AnAnt> the problem with the shipped Qt libraries, is that the non-latin support (for ex. arabic) is not working properly
<AnAnt> in old versions of googleearth, it was possible to remove those shipped Qt libs, and use system's Qt libs, and the problem would be fixed
<AnAnt> but in new versions, some symbol errors happen, and hence googleearth crashes
<cjwatson> AnAnt: I'm having trouble seeing what this has to do with partner, since there's no googleearth package in partner
<AnAnt> cjwatson: oh, I was hoping that if Canonical maintains the package (like it does with skype), that this would be fixed
<cjwatson> Google would need to use (IIRC) http://www.canonical.com/partners/isv
<cjwatson> I guess you could ask Brian Thomason but I have no idea whether this is something we can initiate
<cjwatson> why not make sure the googleearth-package installer package in multiverse works propery?
<cjwatson> *properly
<AnAnt> cjwatson: ok, will try that
<micahg> cjwatson: now that we have the libav fix for gnash, I can merge the git snapshot from Debian, maybe that will help
<cjwatson> micahg: if you think that's a better idea than a targeted fix, sure ...
<micahg> cjwatson: well, we generally take the latest gnash anyways, I'll make sure there are no crazy packaging changes and get an FFe if there are feature changes upstream, anyways, gnash is something that should actually be SRUd regularly due to flash changing
<cjwatson> true
<victorp> cjwatson, quick question
<victorp> cjwatson, nevermind got an answer in another channel ;)
<jjardon> hello, anyone with problem loading the datetime preferences from the control center?
<doko> jamespage, still online?
<cjwatson> victorp: ok
<roadmr> sorry for the dumb question, who should I put as reviewer on a FFe merge request? (ubuntu-release perhaps?)
<jamespage> doko: yep
<micahg> roadmr: you need a bug  for the FFe and you can link it to the merge proposal
<doko> jamespage, who did approve the FFe's? I can't see anything in the bug reports
<jamespage> "iulian: jamespage: Looks good, please go ahead and get them in."
<doko> jamespage, hmm, which report?
<iulian> doko: That was on -release. I should've added a comment to the report, sorry for the confusion caused.
<cjwatson> roadmr: as micahg says; for the merge request itself, please don't make ubuntu-release the reviewer; ubuntu-sponsors is usual
<doko> jamespage, iulian: ahh, ok. just didn't see it
<doko> looking at gauche, the 23rd scheme implementation ...
<roadmr> cjwatson, micahg : thanks!! putting ubuntu-sponsors as reviewer then
<hyperair> can someone from ubuntu-sru please ack https://bugs.launchpad.net/unity/+bug/816632 please?
<ubottu> Launchpad bug 816632 in unity (Ubuntu) "Memory leak in IndicatorObjectEntryProxyRemote::GetPixbuf" [Undecided,Fix committed]
<hyperair> i posted that patch slightly over a month ago, and it's just gotten ignored.
<doko> jamespage, synced
<doko> jamespage, could you review https://code.launchpad.net/~xranby/ubuntu/oneiric/libxerces2-java/lp834068 ?
<hyperair> i completely forgot about it until some update from natty-proposed came and overrode my unity package and it suddenly started leaking again.
<jamespage> doko: already have - LGTM
<jamespage> (see MP comments)
<jamespage> doko: did you sync all four packages?
 * jamespage goes to look
<hyperair> er actually i really meant core-dev earlier, not ubuntu-sru.
<doko> jamespage, yes
<AnAnt> cjwatson: googleearth-package has same problem
<AnAnt> cjwatson: btw,  I think it can make use of multiarch
<cjwatson> don't confuse me for somebody who cares about googleearth :-)  I was just trying to advise on partner
<cjwatson> I expect it could, yes
<micahg> cjwatson: I take it we're not going to make the openssl transition complete for oneiric then, are efforts best spent elsewhere then?
<cjwatson> micahg: the point of openssl098 wasn't giving up on the openssl transition, it was more that I'm aware that libssl is quite likely to be linked into third-party binaries
<cjwatson> so it's more worth a compat package than usual, IMO
<micahg> cjwatson: ok, thanks
<AnAnt> LP 833791
<ubottu> Launchpad bug 833791 in texinfo (Ubuntu) "Please merge texinfo 4.13a.dfsg.1-8 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/833791
<AnAnt> just changed status to confirmed
<Seq> Does anybody know where empathy keeps it's account credentials? It seems to forget all of my accounts at every login, but they are in .mission-control/accounts/accounts.cfg, so it must also track them elsewhere?
<Seq> Also, I have a plain-text keyring (I use auto login), but my keyring keeps re-encrypting itself. I'mm clear the passphrase with seahorse and confirm the login.keyring is plain ascii text. Time will pass and I reboot, and my login.keyring is encrypted again. Does anybody know how to fix this?
<tmus> Is there a known issue with fglrx in Oneiric lately? I just upgraded my natty laptop to Oneiric, and fglrx just won't load properly - I constantly end up with radeon loaded
<Sarvatt> tmus: theres a problem with the blacklist not getting used if you have cryptsetup installed (which puts the drm modules end up in the initrd) leading to radeon/nouveau loading too early, you can get around it by adding your own blacklist in /etc/modprobe.d/ and update-initramfs -u after
#ubuntu-devel 2011-09-06
<poolie> ubuntu monospace seems to have gone away?
<pitti> Good morning
<didrocks> good morning
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<jamespage> morning
<evfool> hey pitti: regarding 829635: glib.markup_escape_text number of params, you've mentioned in the bug that glib has changed to accept only the text, but the gir generated from the typelib still has two params
<evfool> what's the thing here I'm missing?
<htorque> sladen: hi! will we see an update to the beta fonts anytime soon? the oneiric version 0.71.2-0ubuntu7 supersedes the one in the ppa and now i'm missing that fine mono font. :-)
<pitti> evfool: I suppose they fixed the annotation to say that the second is the length of the first
<evfool> pitti: so the correct call is as it currently appears in apport, with only one param, the text
<pitti> apparently so, yes
<sladen> htorque: yeah, I'll add the Arabic beta in that DM sent over
<sladen> htorque_: yeah, I'll add the Arabic beta in that DM sent over
<htorque_> sladen: thanks :-)
<Riddell> sladen: old logo alert https://wiki.ubuntu.com/UbuntuAppDeveloperWeek
<sladen> Riddell: https://bugs.launchpad.net/ubuntu-branding/+bug/837531/+affectsmetoo
<ubottu> Launchpad bug 837531 in ubuntu-branding "AppDeveloperWeek uses pre-2010 Ubuntu and Edubuntu logos" [Undecided,Confirmed]
<bdrung> tumbleweed: E:237:SourcePackage.pull_dsc: Instance of 'ParseResult' has no 'scheme' member
<tumbleweed> bdrung: aah, I probably only pylinted it on sid. I take it you are happy with the other commits I did directly?
<bdrung> tumbleweed: yes
<bdrung> tumbleweed: our testcase catches that error posted above.
<bdrung> but it appears with 'pylint ubuntutools/archive.py'
<tumbleweed> sounsd like a pylint bug, then
<tumbleweed> ParseResults have scheme members
<bdrung> look at our pylint.conf
<bdrung> tumbleweed: do you have some minutes?
<bdrung> tumbleweed: pushed. look at http://paste.debian.net/128598/ -> the first message shouldn't be an error in this case!
<Laney> shouldn't the second one be Info: too?
<bdrung> yes
<ogra_> can someone bump the score on https://launchpad.net/ubuntu/+source/vlc/1.1.11-2build2/+build/2763654
<cjwatson> ogra_: done
<ogra_> thx
<ogra_> hopefully it doesnt segfault again
<tumbleweed> bdrung: hi, yes I have some time (sorry, just had to deal with a DNS issue)
<bdrung> tumbleweed: the first two items in http://paste.debian.net/128598/ should be info level
<tumbleweed> bdrung: should we also ignore CURRENT blacklisting when syncing from experimental (when ubuntu > sid, everything will be blacklisted CURRENT)
<Laney> you need ffe for that change btw (dh_python2 switch)
<bdrung> Laney: i know, i just wanted a test case :)
<Laney> k
<tumbleweed> bdrung: I disagree about Info. syncpackage hides Info messages by default
<bdrung> right
 * tumbleweed uses warn
<bdrung> then: error -> warn for first message
<tumbleweed> ah, normal
<bdrung> tumbleweed: btw, pushed again
<tumbleweed> bdrung: pushed
<bdrung> tumbleweed: "syncpackage: The blacklisting only applies to the current versions in Debian and Ubuntu. --force is required to override the blacklist." is a little bit long
<tumbleweed> we're going to have the same problem with comments, because they are append-only. /me adds wrapping
<Laney> that could get annoying
<bdrung> tumbleweed: pushed
<tumbleweed> Laney: any better ideas?
<Laney> get launchpad to get rid of old comments
<Laney> :(
<cjwatson> libdevel-bt-perl is an object lesson in why it's sometimes worth debugging build failures on unsupported architectures
<cjwatson> it turns out that the reason powerpc failed is that it's running a new enough kernel to have the yama security extension turned on; if you try to build (or indeed use) libdevel-bt-perl on a current i386 system it fails in the same way
<doko> seb128, what to do with seahorse? you did drop the -dev package
<seb128> doko, what about seahorse?
<seb128> doko, oh, the lib it used to ship is a new source
<seb128> somebody needs to package it if we need it for something else
<doko> seb128, bug 840611, well, then please don't drop the -dev package in the first place :-(
<ubottu> Launchpad bug 840611 in seahorse (Ubuntu Oneiric) "seahorse dropped the libcryptui-dev package, needed by almanah and seahorse-plugins" [High,Confirmed] https://launchpad.net/bugs/840611
<seb128> doko, how can we keep the binary when the corresponding code has been dropped in the upstream update?
<seb128> doko, they moved that code to a new source and tarball
<shbk> hello, does anybody know what functions exactly can I use to get info about system(video card, resolution) from man 2 or man 3 . I have to use only c/c++.
<bdrung> tumbleweed: what command did you use to test your changes?
<seb128> doko, well those 2 binaries can be dropped from oneiric if nobody cares about it
<doko> seb128, please state this in the bug report
<seb128> doko, ok
<pitti> seahorse-plugins seems quite obsolete indeed
<pitti> in the past we needed it for gpg, but that's built into g-keyring now
<seb128> pitti, it still had gedit integration iirc but it's not worth spending efforts on
<shbk> hello, does anybody know what functions exactly can I use to get info about system(video card, resolution) from man 2 or man 3 . I have to use only c/c++.
<tumbleweed> bdrung: icedove. I couldn't test the CURRENT blacklisting because i couldn't find a suitable package (and couldn't get it working on dogfood)
<bdrung> tumbleweed: xmms2
<Hobbsee> shbk: we don't do your homework for you.  Try google.
<seb128> shbk, hi, that's probably not the right channel for your question, try #ubuntu, and repeating the question this way will rather be annoying to others than useful to get a reply
<jamespage> doko: thanks for doing those syncs yesterday - however maven2-core/maven2 needed to be built/published sequentially so we now need a no-change rebuild on maven2 to pickup the right version of maven2-core (2.2.1-6)
<jamespage> once that has published maven-plugin-tools should build OK (FTBFS ATM)
<doko> jamespage, sorry, could you do these?
<jamespage> doko: I can do a branch for the maven2 rebuild - but I can't upload either package :-)
<jamespage> doko: if you are tied up I can prob find someone else to sponsor for me
<doko> jamespage, sorry, forgot. will do
<jamespage> doko: thankyou
<bdrung> tumbleweed: time to release 0.129 or is there something left to do?
<tumbleweed> bdrung: I'm happy. I suspect we'll find more issues when more people start using syncpackage, but that's fine
<bdrung> tumbleweed: pushed and uploaded
<Riddell> sladen: my oneiric install seems to have Ubuntu and Ubuntu Light fonts fixed up http://people.canonical.com/~jriddell/tmp/font-screenshot.png
 * ogra_ kicks gtk-3.0 
<Riddell> top is Ubuntu, second is ubuntu Light
<ogra_> build faster, damned thing
<ogra_> ha ! that helped !!
<pitti> ogra_: DEB_BUILD_OPTIONS=nocheck,parallel=4 might help? :-)
<ogra_> pitti, well, you were the uploader :P
<sladen> Riddell: https://bugs.launchpad.net/ubuntu-font-family/+bug/744812/+affectsmetoo  or do you think this is something different again?
<ubottu> Launchpad bug 744812 in ubuntu-font-family-sources (Ubuntu Oneiric) "FontConfig/Qt stack choke on Ubuntu Medium font meta-data (No medium in Inkscape and too bold in Qt apps)" [High,Fix released]
<ogra_> but i fear that wont help on the uniprocessor armel builders :)
<pitti> ogra_: oh, and --extra-paint=go-faster-stripes
<pitti> ogra_: ah
<pitti> dear linux, please stop sucking so much when even the slightest bit of IO is going on
<Riddell> sladen: I suspect it's different.  this isn't qt for one thing
<sladen> Riddell: https://bugs.launchpad.net/ubuntu-font-family/+filebug?field.title=Metadata:+Libreoffice+confusion+with+Ubuntu+Light
<ogra_> cjwatson, there is some unreleased stuff in the livecd-rootfs tree from you, i assume its fine to upload ?
<cjwatson> ogra_: yes
<ogra_> thx
<cjwatson> I didn't need to upload that since I deployed it by way of RT
<ogra_> yeah, i remember
<ogra_> siretart, hmm, i see you worked on vlc-cachegen segfaults, any idea why it still fails on armel (seems to build on the other arches now)
<dholbach> we have to get sponsorship back on track again
<dholbach> the queue is growing, growing and growing
<dholbach> and I'm sure there's still loads of good fixes in there
<cjwatson> We also have to get the archive stable for release
<dholbach> oh, I wasn't trying to say that everybody was twiddling thumbs :/
<cjwatson> I'm not saying this as a contradiction, but we have a *lot* of queues that need to be driven to zero
<agateau> hi, it seems multiarch support changed quite a lot in oneiric, I need to install 32bit versions of Qt libs in order to test Skype on an amd64 system, do you know how to do that?
<pitti> agateau: if you enable partner, sudo apt-get install skype:i386 should get you everything you need
<agateau> pitti: oh
 * agateau tries
<pitti> agateau: the amd64 package hasn't been updated for that yet, that was in the beta-1 release notes
<agateau> pitti: you mean for skype or for qt?
<pitti> agateau: skype
<agateau> pitti: ok, right now the skype binary from skype.com does not start because it is missing 32bit versions of Qt libs and libXss, is there a way for me to install those?
<jtaylor> yes, install the missing libs ._.
<jtaylor> apt-get insall libxss1:i386 etc
<pitti> agateau: yes, you can install any i386 version of a library with e. g. sudo apt-get install libqtgui4:i386
<cjwatson> skype:i386 should get you the lot though
<agateau> oh, I didn't know about the :i386 syntax, thanks jtaylor and pitti
<jtaylor> someone should put that skype thing in the topic, its probably the most frequent question
<pitti> it's in the release notes
<jtaylor> oh this is not +1
<pitti> otherwise, skype isn't in ubuntu :)
 * agateau feels like a noob
<pitti> agateau: in short, in oneiric final we'll (hopefully) have this fixed so that installing from s-c just works
<agateau> pitti: sounds good
<agateau> ftr, it seems to work but I had to add foreign-architecture i386 to /etc/dpkg/dpkg.cfg (as mentionned in http://wiki.debian.org/Multiarch/Implementation)
<zul> mterry: can you review the MIR for python-stompy please? Bug #835596
<ubottu> Launchpad bug 835596 in python-stompy (Ubuntu) "[MIR] python-stompy" [Undecided,New] https://launchpad.net/bugs/835596
<cjwatson> agateau: also as mentioned in https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-August/000886.html for people who've been upgrading through oneiric; people who upgrade to oneiric directly using update-manager won't need to do that
<cjwatson> (if you're running development releases, it's important to follow ubuntu-devel-announce)
<mterry> zul, sure
<agateau> cjwatson: ok, taking note
<zul> mterry: thanks
<dholbach> can somebody moderate my mail on u-d-a through?
<doko> didrocks, could you upload the new qt4-x11? ARM needs it
<pitti> dholbach: looking
<didrocks> doko: it's untested on kubuntu (I asked kubuntu-devel people to get some test) and it completely breaks unity-2d and I wait for some to get some initial fixes
<cjwatson> dholbach: done
 * pitti cancels listadmin then and starts over :)
<seb128> hum, no slangasek
<seb128> bug #839744 seems a multiarch sort if issue
<doko> didrocks, when do you expect this? because else, I'd like to get the fix for  bug 785318
<ubottu> Launchpad bug 839744 in glib2.0 (Ubuntu) "package libglib2.0-0 2.29.16-0ubuntu3 [modified: usr/share/doc/libglib2.0-0/changelog.Debian.gz] failed to install/upgrade: ErrorMessage: './usr/share/doc/libglib2.0-0/changelog.Debian.gz' is different from the same file on the system" [Undecided,Confirmed] https://launchpad.net/bugs/839744
<ubottu> Launchpad bug 785318 in qt4-x11 (Ubuntu) "programs segfault trying to dlopen libQtOpenGL" [Low,Confirmed] https://launchpad.net/bugs/785318
<didrocks> doko: Thursday at the latest, hoping tomorrow
<dholbach> thanks cjwatson
<doko> ok, sounds good
<dholbach> and thanks pitti too :)
<seb128> seems like the amd64 and i386 binaries conflict on the changelog?
<cjwatson> seb128: are the changelogs bitwise-identical between architectures?  (this is required)
<seb128> cjwatson, I see no reason they shouldn't be
<cjwatson> but are they?
<seb128> but I didn't check the debs content
<seb128> let me have a look
<seb128> "Package: libglib2.0-0 2.29.16-0ubuntu3 [modified: usr/share/doc/libglib2.0-0/changelog.Debian.gz]" on the apport bug
<seb128> that's a bit weird
<doko> gnome-auto stuff?
<seb128> not on the changelog
<cjwatson> I don't know how relevant that is - I'd check the actual .debs
<seb128> it seems to happen for people upgrading from natty
<Laney> won't they be not-bit-identical due to the changelog trimming?
<pitti> that would be weird
<pitti> changelog trimming is very well defined
<pitti> and not arch specific
<Laney> I was thinking of the compression
<pitti> the full lenght changelogs get compressed as well, though
<pitti> (just like manpages, etc.)
<pitti> dh_compress ought to call gzip with the "no timestamp" mode to get reproducible files
<Laney> true
<pitti> that is to say, I'm not at all claiming that changelog trimming isn't to blame here
<nigelb> g23
<seb128> cjwatson, yeah, the files are the same (same md5sum, from the unpacked debs)
<pitti> it's just that we apply it to each and every package, and it doesn't seem to be a general problem
<Laney> they're the same here
<seb128> cjwatson, it seems only to happen for natty to oneiric updates seeing the duplicate, no bug from oneiric to oneiric
<seb128> Laney, pitti: ^
<pitti> would that be a problem if you have multiarch enabled in natty, and upgradre the amd64 and i386 package at different times?
<pitti> (regardless of the particular package)
<cjwatson> pitti: the terminal log here shows that the amd64 package had already been upgraded, so that *shouldn't* be a problem
<cjwatson> seb128: posted some analysis to bug 836915; would appreciate your thoughts
<ubottu> Launchpad bug 836915 in opal (Ubuntu Oneiric) "opal is missing a b-d on ptlib, which is not in oneiric" [High,Confirmed] https://launchpad.net/bugs/836915
<seb128> cjwatson, thanks, looking
<cjwatson> seb128: ... and added some IRC discussion too
<ogra_> hmpf, why does cdimage not respect ARCHES= anymore
<cjwatson> it should do
<ogra_> yeah
<cjwatson> exact command line?
<seb128> cjwatson, I'm not sure now why we synced that one, is was a while back, but updating ptlib and ekiga with the experimental seems the easier thing to do there
<ogra_> ARCHES=armel+ac100 for-project ubuntu cron.daily-preinstalled
<ogra_> i end up with a log for mx5
<cjwatson> (although you should not be putting ARCHES= in the crontab any more, as there's a better mechanism)
<ogra_> no, thats a manual testbuild
<ogra_> i use cdimage's mechanism for auto-builds
<cjwatson> seb128: can you do the FFe stuff the?
<cjwatson> *then
<cjwatson> I'm currently trying to assemble a working build tree; if I can get far enough then I can provide a libav patch if need be
<ogra_> funnily i know that the same worked before beta (ac100 was disabled suring milestone freeze)
<seb128> cjwatson, ok
 * ogra_ tries the build again but removes armel+mx5 from etc/default-arches
<ogra_> i'm pretty sure ARCHES is overridden here ... might be that my format for the entry in etc/default-arches wasnt right
<ogra_> yup, that way it works
<ogra_> cjwatson, is there anything wrong with the old line 2 on http://paste.ubuntu.com/683644/ ? ARCHES isnt respected with the upper line but works fine if i just add ac100 to line 4
<ogra_> (or drop mx5 as i did)
<ogra_> (thats wrt cdimage/etc/default-arches)
<bdmurray> pitti: I'm trying to sort out an issue with the ubiquity apport source package hook and version tagging of bug reports in bug 842130 you can see the tag was added by my bot and not with the source package hook
<ubottu> Launchpad bug 842130 in ubiquity (Ubuntu) "[regression] Does not fit netbook screen" [Undecided,New] https://launchpad.net/bugs/842130
<cjwatson> default-arches shouldn't even be looked at at all if ARCHES is set
<cjwatson> I suggest using sh -x to find out what's going on
<cjwatson> (DEBUG=1 is useful when doing this too, so that it doesn't try to publish stuff)
<ogra_> k
<apw> pitti, i have an issue with apport-gtk, where it seems to be consuming 25% of my CPU, killing my battery life
<apw> pitti, when i renamed it away i got a popup saying that "program this report refers to is no longer present"
<apw> (and my CPU went back to 0)
<bdmurray> apw: is there anything recent in /var/crash ?
<apw> bdmurray, yep piles of unity exploding
<bdmurray> apw: you might try recreating the issue with ubuntu-bug /var/crash/pile_1_of_explodyness
<apw> bdmurray, will try once i have done these power tests
<maco> there's a patch pilot in the /topic but not in the channel. hrmph.
* micahg changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<micahg> maco: fixed :)
<maco> heh
 * maco scowls at lp. scan branch fasterer!
<bryceh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh
<om26er> bryceh, Hi! can you please sponsor https://code.launchpad.net/~om26er/ubuntu/natty/unity/unity-fix-761409/+merge/74009 :)
<barry> ScottK: re your comment in bug 832864.  are you saying you've approved the ffe for pyside?  if so, i can upload the new version and its dependents
<ubottu> Launchpad bug 832864 in pyside (Ubuntu Oneiric) "pyside version 1.0.4-1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/832864
<ScottK> Yes.
<barry> ScottK: cool, thanks
<bryceh> om26er, ok, looking
<micahg> bryceh: there's another unity issue waiting for sponsorship from hyperair
<hyperair> \o/
<om26er> micahg, i have the fix for that as well ;)
<hyperair> om26er: you do?
<hyperair> om26er: why didn't you include it in your upload? =\
<om26er> hyperair, my branch have the fix
<om26er> i added your patch
<hyperair> ah
<hyperair> i didn't see your branch
<hyperair> but whatever got uploaded to -proposed didn't have my patch.
<om26er> hyperair, I also proposed your fix to lp:unity/3.0
<hyperair> afaik my fix was irrelevant/already committed into trunk.
<hyperair> so there wasn't really a need to do that, or was there?
<om26er> hyperair, it proposed it to stable series trunk
<bryceh> om26er, hyperair, ok, ping me again when you have this all sorted out :-)
<om26er> bryceh, its sorted already ;)
<bryceh> om26er, also, the version number for a natty backport should be ~natty1.n rather than ~natty3
<om26er> bryceh, last upload I had it natty1.1 it was rejected
<om26er> i was asked to make it natty2
<bryceh> om26er, by whom?
<micahg> bryceh: natty2 is already in -proposed
<om26er> raof I think
 * om26er checks
<bryceh> hmm
<micahg> bryceh: makes sense this this was already a natty backport
<micahg> or a natty specific upload
<bryceh> oh right
<bryceh> weird numbering
<om26er> https://bugs.launchpad.net/ubuntu/natty/+source/unity/+bug/769703/comments/46
<ubottu> Launchpad bug 769703 in unity (Ubuntu Natty) "Unity launcher does not auto hide when using dragging in Qt softwares" [High,Fix released]
<micahg> om26er: your branch should be against natty-proposed BTW, not natty
 * micahg goes back to other things...
<hyperair> meh. i can't figure out all this bzr crap.
<hyperair> om26er: do you have any other fixes queued in your bzr branch?
<hyperair> if not, can bryceh just upload my debdiff as is?
<hyperair> it would be much simpler that way.
<hyperair> bryceh: also, what's with the natty1.n versioning? i've never seen this kind of versioning before.
<om26er> hyperair, it have two bug fixes bug 816632 and 761409
<ubottu> Launchpad bug 761409 in unity (Ubuntu Natty) "Cannot click on left-most indicator on panel if a systray icon appears" [High,Triaged] https://launchpad.net/bugs/761409
<ubottu> Launchpad bug 816632 in unity (Ubuntu) "Memory leak in IndicatorObjectEntryProxyRemote::GetPixbuf" [Undecided,Fix committed] https://launchpad.net/bugs/816632
<hyperair> oh seriously.
 * hyperair sighs
<hyperair> how complicated.
<hyperair> honestly, i don't really care as long as my patch goes in somehow.
<hyperair> the memory leak is annoying.
<hyperair> so just do as you like
<bryceh> hyperair, shall I wait on sponsoring om26er's branch until you have things sorted out?
<hyperair> bryceh: i'm letting om26er sort things out. he's already got my patch queued in his branch.
<om26er> (this branch have the fix for the issue hyperair reported) the change in src/IndicatorObjectEntryProxyRemote.cpp is the fix
<hyperair> bryceh: honestly, bzr confused the hell out of me, and i'm satisfied with just uploading debdiffs.
<hyperair> s/confused/confuses/
<maco> bryceh: can you take a look at https://code.launchpad.net/~maco.m/ubuntu/oneiric/system-config-printer/desktop-change/+merge/74273 ?
<maco> >< an hour is an awful long time to take to generate a one-line diff
 * micahg hugs maco for that fix
<beuno> maco, launchpad's diff generation is stalled at the moment
<maco> beuno: oh, well that would explain that
<maco> micahg: xfce user?
<micahg> maco: xubuntu dev :)
<maco> oh heh
<maco> charlie was making some noise about it in -a11y
<bryceh> maco, sure
<mdz> smoser, kirkland, we're running into bug 816387 and are going to try Tyler's proposed patch
<ubottu> Launchpad bug 816387 in eCryptfs "ecryptfs kernel panic when rebooting/shutdown" [High,In progress] https://launchpad.net/bugs/816387
<maco> bryceh: thanks
<mdz> is https://wiki.ubuntu.com/KernalTeam/EC2Kernel the best resource for how to build the kernel for EC2?
<smoser> mdz, kernel is just -virtual kernel
<mdz> smoser, ok, so no special instructions? just build that flavour?
<smoser> yes.
<smoser> for >= maverick
<mdz> is https://help.ubuntu.com/community/Kernel/Compile the right resource then?
<smoser> you should ask in ubuntu-kernel to be more sure, smb woudl know. but i think so, yes.
<mdz> smoser, ok, thanks
<smb> !kernel-compile
<smb> smoser, mdz Not sure there was a community one but also some more specific...
<smb> The link was the community one
<bryceh> om26er, sponsored and uploaded to natty-proposed.
<om26er> bryceh, thank you :)
<smb> mdz, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<tyhicks> mdz: Be sure to check out the kernel.org bug - the proposed patch that was mentioned in the LP bug didn't fix it
<tyhicks> mdz: This one seems to fix it: http://git.kernel.org/linus/f61500e000eedc0c7a0201200a7f00ba5529c002
<mdz> tyhicks, will do, thanks very much!
<bryceh> /tmp/buildd/system-config-printer-1.3.6+20110831/debian/tmp//usr/share/applications/system-config-printer.desktop: error: value "KDE,GNOME;" for key "NotShowIn" in group "Desktop Entry" contains an unregistered value "KDE,GNOME"; values extending the format should start with "X-"
<bryceh> Error on file "system-config-printer.desktop": Failed to validate the created desktop file
<bryceh> make[3]: *** [install-desktopDATA] Error 1
<bryceh> maco, ^^
<maco> bah, ok.
 * maco goes to re-look-up how lists work
<bryceh> should it be =KDE;GNOME maybe?
<broder> yeah, i think semicolon is the separator there
<seb128> bryceh, it should yes
<maco> oops. sorry :(
<seb128> bryceh, maco: with a ; at the end of the list as well i.e ="KDE;GNOME;"
<maco> i dont have an oneiric here to try to do the testing with
<maco> i wonder if "The OnlyShowIn field is a list of strings identifying the environments that should display a given menu item. If an OnlyShowIn field is present, a given environment should only display the menu item if the string identifying that environment is present. The strings are case-sensitive." in the menu spec could be updated to say "semi-colon delineated list"
<bryceh> at least the build process includes a validator to catch it
<bryceh> so that's nice :-)
<maco> making a debdiff for that for oneiric on natty wouldnt work here, so i just kinda hoped the syntax was right :-/
<bryceh> maco, I've fixed it up locally and will upload it
<maco> bryceh: thanks
<hyperair> om26er: thanks for incorporating my patch.
<bryceh> maco, chroots and pbuilders are your friends :-)
<maco> bryceh: dont i need a source package before i can pbuild it?
<maco> (and i have no idea how to do the chroots thing. i can chroot in to rescue a system, but other than that...vmware)
<om26er> hyperair, oh no problem :)
<hyperair> om26er: :)
<seb128> maco, the format didn't change you could probably desktop-file-valide it on any recent ubuntu version
<bryceh> maco, no problemo, I'll email you a script I use to make chroots
<maco> seb128: i didnt know about that command. i guess if i quilt push -a then i could run it on the desktop.in, maybe?
<seb128> maco, yeah, you could take the .desktop, hack it locally and run the validator on it
<bryceh> maco, chroot making script sent.
<bryceh> maco, branch merged and uploaded for oneiric
<maco> thank you
<seb128> maco, that changelog entry is quite confusing, it doesn't match the upload
<seb128> "to NotShowIn:KDE so it works for Xubuntu, GNOME, etc. (LP: #841817)"
<seb128> "NotShowIn=KDE;GNOME;"
<maco> cruddddd did i write it before reading your comment on the bug, maybe?
<maco> today is a fail day
<kirkland> mdz: I'm just getting online for the first time in a few days....responded to your email now, glad to see tyhicks got you looking at the right git commit
<smoser> kees, does this look sane to you: http://paste.ubuntu.com/683827/
<micahg> smoser: he's off today, but you're missing the piece in debian/control that was dropped
<smoser> oh for petes sake.
<smoser> micahg, ok http://paste.ubuntu.com/683828/
<smoser> that seems right to me (and builds)
<micahg> smoser: I think that's fine, but to be sure, you can grab the last ubuntu version and diff
<smoser> micahg, last ubuntu version did not need the additional patch
<smoser> (the adding of the 'hardening-wrapper' is correct)
<smoser> previous source just built with no necessary additional patches
<micahg> smoser: right, was referring to the control file, idr exactly what the diff was, ah, if you checked then it should be fine :)
<seb128> could somebody set https://code.launchpad.net/~jtaylor/ubuntu/natty/meld/meld-sru/+merge/72410 to merged?
<jono> Laney, howdy
<Laney> greetings
<jono> sorry in advance
<jono> I am here to nudge you about work items
<Laney> hahaha
<jono> would you mind having a look into your items on the following:
<jono> https://blueprints.launchpad.net/ubuntu/+spec/community-o-app-review-board-review-and-assessment
<jono> https://blueprints.launchpad.net/ubuntu/+spec/community-o-debian-dex
<jono> https://blueprints.launchpad.net/ubuntu/+spec/community-o-review-sponsorship-process
<Laney> I mailed the ARB yesterday
<jono> that's it :-)
 * Laney changes that one
<jono> if you could update them, that would be great
<jono> thanks!
 * Laney is not very good at blueprints
<ajmitch> Laney: you did?
<Laney> yes
<Laney> didnt it work?
<stgraber> haven't received anything
<Laney> is it moderated for non members?
<ajmitch> did you do it through the LP contact-a-team, or the ML?
<Laney> list
<ajmitch> probably, jono can approve
<Laney> yah boo
<Laney> down with moderation!
<ajmitch> yay for less spam though :)
<stgraber> Laney: add a WI for jono to let the e-mail through ;)
<jono> stgraber, oi!
<jono> :-)
<ajmitch> jono: or you could possibly add arb people to the mailman listadmin? :)
<Laney> it wasn't a very good solution to the work item fyi
<Laney> "here are the docs, but they suck"
<jono> lol
<ajmitch> hah
<Laney> maybe the new sexier mentors will let us unify the two finally
<jono> ok, I need to get IS to reset the password for the list for me
<jono> I have lost it
<jono> and then I will see if someone else can be an admin
<Laney> haha
<Laney> i'll forward it to ajmitch who can then send it to the list :P
<ajmitch> heh, ok
 * jono is useless
<jono> apologies Laney
<ajmitch> jono: don't worry, it took me awhile to dig up the password for the ubuntu-nz list :)
<jono> :-)
<Laney> you don't have it in ~/.listadmin.ini?
<Laney> sent
<ajmitch> I didn't
<jono> thanks Laney
 * jono goes back to hassling other people about work itemms
<jono> items
<Laney> I was thinking about the debdiffs thing the other day
<Laney> how would you tell them apart from other diffs?
 * micahg has a work item or 2 outstanding, but doesn't remember what they are
<Laney> lsdiff them for changes in debian/?
<ajmitch> given that any change should include something in debian/changelog, I guess that'd work
<Laney> then you have to download them all :(
<ajmitch> is there a fulltext search on LP for attachments?
 * ajmitch is sure he read something about that awhile ago
<ajmitch> https://lists.launchpad.net/launchpad-dev/msg03633.html is the best I can find offhand, saying no
<bryceh> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<ajmitch> Laney: ok, it made it through to the list now
<Laney> hoorah
<Laney> nighty night
<siretart> ogra_: in debian, the cause was a lovely segfault due to global destructors in qt
<siretart> ogra_: known in ubuntu as LP: #785318
<elmo> is the FFE process for universe really the same as main these days?
<infinity> Pretty much.
<infinity> Though you may find release folk slightly more tolerant of universe FFEs.
<cjwatson> yep, same process, not necessarily same strictness
<micahg> elmo: not on an image with no rdepends has a lower burden
#ubuntu-devel 2011-09-07
<doko> micahg, what do you mean to do about bug #838828?
<ubottu> Launchpad bug 838828 in gst-plugins-ugly-multiverse0.10 (Ubuntu Oneiric) "Please remove gst-plugins-ugly-multiverse0.10 source and binaries " [Wishlist,Confirmed] https://launchpad.net/bugs/838828
<micahg> doko: I think slytherin uploaded something for it, but I think it breaks for me, I think my initial assessment was correct, but have not had time to investigate
<doko> micahg, ok, I'll remove it and let the report open
<micahg> doko: I think you can safely remove it
<doko> micahg, and while you are here ... NBS:
<doko> flashplugin-nonfree
<doko>    	flashplugin-nonfree-extrasound	multiverse	i386
 * micahg looks that up on LP quick
<doko_> <doko> micahg, and while you are here ... NBS:
<doko_> <doko> flashplugin-nonfree
<doko_> <doko>     flashplugin-nonfree-extrasound multiverse i386
<doko_> * Disconnected (Connection reset by peer).
<micahg> doko_: I don't think we need it, but it's in Debian, so should be removed only in concert with them, we dropped the transitional flashplugin-nonfree binary, so that needs to be transitioned to flashplugin-installer I think
<micahg> doko: is that the only  NBS for that binary?
<doko_> micahg, yes, see http://people.canonical.com/~ubuntu-archive/nbs.html
<micahg> doko_: ok, we just need to transition to the new binary, I can do that tonight I guess
<pitti> Good morning
<pitti> apw: when do the 25% CPU happen of apport-gtk? while it's collecting data? or what does it do at that time?
<micahg> pitti: could you give this back please: https://launchpad.net/ubuntu/+source/perl/5.12.4-4/+build/2768379 (doko requested it)
<micahg> pitti: and good morning :)
<pitti> micahg: done
<micahg> pitti: thanks
<didrocks> good morning
<ScottK> didrocks: I assigned the Qt update to you in anticipation of you getting it packaged.
<didrocks> Hey ScottK, it's packaged and in the ubuntu-desktop ppa since Monday. There are serious regression with unity-2d (they are fixing it for Thursday), so, I think pushing it at the same time. I asked for testing on #kubuntu-devel but got no feedback
<ScottK> Yeah, we've been focused on KDE 4.7.1 packaging.
<ScottK> That should get pushed today.
<didrocks> oh nice :)
<didrocks> ScottK: the ppa is there (ubuntu-desktop/ppa) if anyone wants to test, amd64 should be built as well now despite the mozilla jump on all available ppa builders :)
<dholbach> good morning
<madnick> morning
<evfool> hi all, how is the power-and-settings indicator officially called?
<evfool> what's the official name to use in docs?
<FourDollars> Hi, I have a patch for the ibus-chewing package in main. Who can help me?
<FourDollars> https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/843619
<ubottu> Launchpad bug 843619 in ibus-chewing (Ubuntu) "There is a twice pages turning problem when using plain zhuyin with space as selection." [Undecided,Confirmed]
<dholbach> FourDollars, if you subscribed ubuntu-sponsors you should be all set :)
<FourDollars> dholbach: I just attach a patch file. Is it enough for ubuntu-sponsors ?
<dholbach> yep, it should
<dholbach> if the commit is upstream, it would help pointing out a reference to it
<FourDollars> Thanks
<brendand> has anyone else 'lost' their keyring in oneiric? I'm constantly being bothered by password prompts when ssh'ing
<dholbach> FourDollars, was the patch already submitted/accepted upstream? do you know?
<FourDollars> dholbach: I just submitted to upstream and wait for his merge or reject to improve.
<dholbach> FourDollars, is this the same as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630331
<ubottu> Debian bug 630331 in ibus-chewing "ibus-chewing has annoying pop-up when enabling IME, causing focus to change" [Important,Fixed]
<dholbach> or is it slightly different?
<FourDollars> dholbach: no
<FourDollars> dholbach: It is different.
<dholbach> ok - I was just wondering if this fix would be interesting for Ubuntu too
<FourDollars> dholbach: There is another bug may be relative.
<dholbach> FourDollars, if you have a link to where you submitted it upstream, could you add it to the bug report?
<dholbach> ok
<FourDollars> dholbach: https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/838643
<ubottu> Launchpad bug 838643 in ibus-chewing (Ubuntu) "ibus-engine-chewing crashed with SIGABRT in raise()" [Medium,Confirmed]
<FourDollars> dholbach: Could you see https://github.com/definite/ibus-chewing/pull/8 ?
<dholbach> yes, thanks
<dholbach> FourDollars, so it looks like Debian bug 630331, bug 843619 and bug 838643 would be good to get fixed in oneiric - is that right? if so, I could help put a package together and build it in ppa - could you test it afterwards, because I wouldn't know how to use it
<ubottu> Debian bug 630331 in ibus-chewing "ibus-chewing has annoying pop-up when enabling IME, causing focus to change" [Important,Fixed] http://bugs.debian.org/630331
<ubottu> Launchpad bug 843619 in ibus-chewing (Ubuntu) "There is a twice pages turning problem when using plain zhuyin with space as selection." [Undecided,Confirmed] https://launchpad.net/bugs/843619
<ubottu> Launchpad bug 838643 in ibus-chewing (Ubuntu) "ibus-engine-chewing crashed with SIGABRT in raise()" [Medium,Confirmed] https://launchpad.net/bugs/838643
<FourDollars> dholbach: Yes. I think it is good to try.
<dholbach> great
<dholbach> FourDollars, I'll ping you when I uploaded it
<FourDollars> dholbach: Roger that
<FourDollars> dholbach: Thanks
<sabdfl> pitti, any idea why aptitude can't find changelogs at the moment?
<pitti> hey sabdfl
<sabdfl> howdy :-)
<pitti> sabdfl: uh, aptitude.. do you happen to know where it takes them from?
<sabdfl> pitti, let me sniff some packetry
 * pitti installs aptitude and learns how to use it
<pitti> argh, my packages are broken right now, darn multiarch
<pitti> sabdfl: just wonder whether it uses changelogs.u.c. properly
<pitti> installing now
<pitti> $ aptitude changelog gtk+3.0
<pitti> Feh Changelog of gtk+3.0
<pitti> E: Download des Changelog schlug fehl: Download queue destroyed.
<pitti> E: Konnte kein Ãnderungsprotokoll fÃ¼r Â»gtk+3.0Â« finden
<pitti> sabdfl: ^ something like this?
<sabdfl> pitti, ed zachary, yes
<pitti> hm, aptitude changelog gtk+2.0 tries to access http://changelogs.ubuntu.com/changelogs/pool/main/g/gtk+2.0/gtk+2.0_2.24.5-0ubuntu7/changelog, which does exist
<pitti> sabdfl: hm, so no obvious reason, and I can't see an obvious failure from strace; so I guess this needs a more thorough gdb/code inspection session
<pitti> apt-get changelog seems to work fine, and is pulling from the same server
<pitti> seems someone already reported it as bug 824708
<ubottu> Launchpad bug 824708 in aptitude (Ubuntu) "Changelog download failed: Download queue destroyed." [Undecided,Confirmed] https://launchpad.net/bugs/824708
<doko_> pitti, could you have a look at the libindicate ftbfs on powerpc?
<pitti> doko_: very low-priority; I'll add it to my queue, but won't get to it this week
<pitti> doko_: -pljava fixed, BTW
<doko_> pitti, seen, thanks
 * pitti does some further package updates and NBS cleanup
<dholbach> FourDollars, https://launchpad.net/~dholbach/+archive/ppa/+builds?build_state=pending
<dholbach> it will take a while for them to build, but if you could test and confirm they fix all the issues and you're happy with them, I can sponsor to oneiric
<sabdfl> hi pitti, sorry i got disconnected, exploding X
<FourDollars> dholbach: Thanks.
<pitti> sabdfl: FYI, it is already reported as bug 824708
<ubottu> Launchpad bug 824708 in aptitude (Ubuntu) "Changelog download failed: Download queue destroyed." [Undecided,Triaged] https://launchpad.net/bugs/824708
<brendand> for some reason i didn't have gnome-keyring installed. guess i should have had...
<cjwatson> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cjwatson
<Daviey> Good point.
<Daviey> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Daviey, cjwatson
<dholbach> yeeehaw
 * dholbach hugs cjwatson and Daviey
<doko> any cmake experts here? how do I convince cmake not to build with -O3, but -O2?
<cjwatson> convert to autotools
 * cjwatson runs
<cjwatson> looks like possibly you need to prod CMAKE_C_FLAGS_RELEASE (guessing slightly)?
<seb128> dholbach, half of the sponsoring queue is package importer merge requests
<cjwatson> ./Modules/Compiler/GNU.cmake:31:  set(CMAKE_${lang}_FLAGS_RELEASE_INIT "-O3 -DNDEBUG")
<seb128> including quite some weird ones with only .pc directory changes
<seb128> doko, ask agateau maybe
<seb128> he knows quite a bit about cmake ;-)
<cjwatson> seb128: I can probably take a pass through those in a bit
<agateau> seb128: sshhh don't tell anyone!
<seb128> agateau, welcome back! ;-)
<seb128> cjwatson, thanks, I'm still confused by things like https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/gnome-desktop3/oneiric-201109060812/+merge/74173 and why that happens
<cjwatson> seb128: I have no intention of attempting to solve or even explain the general problem
<cjwatson> but I can work through case-by-case
<seb128> ok, fair enough ;-)
<agateau> doko: the way to set build options with cmake depends on whether you are using a predefined build type
<agateau> doko: do you set CMAKE_BUILD_TYPE to something like Release or MinSizeRel?
<doko> agateau, I'm looking at insighttoolkit. it starts with -O2, but some/most submodules are built with -O3
<agateau> doko: oh weird, maybe they are overriding the flags in the submodules?
<doko> beware, the build system is insane, starts from scratch every time :-/
<agateau> fun
<agateau> downloading the src pkg (will take some time here)
<pitti> ok, tbird ppc is building, that should fix the remaining NBS in main
 * pitti removes the gnome-media stuff
<cjwatson> NBS is almost looking sane!
<pitti> mostly due to your heroic libav porting
<doko> pitti, I know ... join the party to remove the gnome stuff in universe ;-P
<pitti> wrt. indicator-applet, if DX doesn't get to porting that, we'll just remove it all
<pitti> (I'd remove it either way, but they asked us to let them some more time)
<pitti> doko: yep
<pitti> all the old applets should go, I'll slaughter them
<pitti> seb128: ^ ok?
<pitti> seb128: i. e. everything on http://people.canonical.com/~ubuntu-archive/nbs.html which still depends on libpanel-applet2-0?
<cjwatson> are all of those only applets, as opposed to packages which happen to ship an applet along with other stuff?
<cjwatson> I saw some examples of the latter which were fixed in Debian by dropping the applet but keeping the other bits
<pitti> the two that would be worth keeping are gnote and workrave, AFAICS
 * cjwatson tries to figure out how to upload app-install-data-ubuntu in the absence of mvo
<seb128> pitti, keep indicator-applet
<seb128> pitti, I think ted had a version building, it just needs testing
<pitti> seb128: yes, and I'd check if e. g. gnote/workrave have newer upstream versions
<seb128> right
<pitti> cjwatson: yeah, of course I'll check for new Debian versions first
<doko>   * CMakeCache.txt.debian: Set CMAKE_BUILD_TYPE to "RELEASE" so that we
<doko>     build with -O3 (not -O2), necessary to optimize the templated code.
<doko> agateau, ^^^ :-/
<doko> and RELEASE is supposed to build with -O3?
<agateau> doko: you can define what RELEASE does
<doko> hmm, old changelog entry, the file doesn't exist
<seb128> pitti, verbiste-gnome is probably worth keeping as well in this list, should be possible to just turn the applet off for it
<agateau> doko: I see one CMakeLists.txt which explicitly set -O3 for one file
<agateau> doko: Utilities/vxl/core/vnl/tests/CMakeLists.txt
<doko> agateau, right, but this looks like something for the tests
<agateau> doko: anyway, you should be able to override things by setting CMAKE_C_FLAGS and CMAKE_CXX_FLAGS to "-O2" I think
<ogra_> phew ...
<ogra_> when did we get .xz support in dpkg ... i just had to wait over 10min for "dpkg-source: info: unpacking ubiquity_2.7.27.tar.xz" on my armel install
<agateau> I see quite a few CMake flags in debian/rules already, including one which sets CMAKE_CXX_FLAGS to -Wno-deprecated
<agateau> doko: ^
<cjwatson> ogra_: xz support for source packages was added in 1.15.5
<doko> agateau, right, I see /usr/bin/g++   -DITKCommon_EXPORTS -Wno-deprecated  -Wno-deprecated  -ftemplate-depth-50 -Wall -Wno-deprecated -O3 -DNDEBUG -fPIC
<cjwatson> and that routinely makes a difference to how quickly I can upload ubiquity, so ...
<ogra_> well, since its only for source packages its fine, but its (very) noticeable slower
<cjwatson> I suspect it's rather memory-dependent
<doko> cjwatson, agateau: btw, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640214  I'm wondering how many packages just don't set the debian defaults, and build with undefined/default behaviour
<ubottu> Debian bug 640214 in cmake "cmake sets the default optimization level to -O3" [Serious,Open]
<ogra_> ah, that might be an issue here, 512M and no swap
<cjwatson> perhaps you should do some benchmarking and contribute to the Debian discussion regarding using it for binaries
<ogra_> (and lots of open apps)
<cjwatson> (people have already suggested that that should be architecture-dependent, etc.)
<cjwatson> doko: does dh get it right?
<ogra_> yeah, if it goes into binary debs i fear that would kill some stuff here ... unpacking things like gnome-user-docs already take up to 20min to only unpack here
<cjwatson> doko: ... doesn't appear so
<doko> cjwatson, I probably should start with a smaller package ;-)
<cjwatson> $ grep CMAKE /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm
<cjwatson>         push @flags, "-DCMAKE_INSTALL_PREFIX=/usr";
<cjwatson>         push @flags, "-DCMAKE_VERBOSE_MAKEFILE=ON";
<ogra_> given the ratio i see for ubiquity (1-2min vs more than 10) that would put gnome-u-d to funny unpack times
<doko> cjwatson, well, this one is cdbs
<doko> cjwatson, ok, neither cdbs
<agateau> doko: I would try to remove the line which sets the build type in debian/rules
<pitti> seb128: oh, and gnome-desktop-sharp2, I'll try to just drop the panel bits there
<agateau> I am still learning about multiarch, I (think I) converted two packages to multiarch, but would like to test it locally. Is there a simple way to build a i386 package from an amd64 machine?
<Laney> pitti: please do that in exp if you can to save us doing it again
<Laney> you should be able to write to pkg-cli-libs
<pitti> Laney: ack
<pitti> Laney: I'll finish the package removal fest first, though
<Laney> sure
<doko> I love debhelper not echoing the commands calling the upstream build system :-/
<cjwatson> doko: DH_VERBOSE=1
<cjwatson> agateau: proper multiarch cross-building is still in its early stages; I suggest http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#amd64i386
<doko> cjwatson, right, hide it in the build logs \o/
<agateau> cjwatson: ok thanks
<cjwatson> doko: maybe the default verbosity for dh_auto_* should be adjusted
<cjwatson> those are a bit different from the rest of dh_*
<doko> agateau, removing the line in debian/rules was the right hint. I'll do that for non ix86
<agateau> doko: good news!
<doko> agateau, however, some subprojects are now built *without* optimization
<Daviey> Seriously, how can vnc4 really have an uncompressed 170MB source..
<pitti> lamont: do you know what's up with dubnium? It's sitting in "almost finished" state like https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2770676 for over an hour
<agateau> doko: there is some ugly CMAKE_*_FLAGS manipulation in Utilities/vxl/core/vnl/algo/tests/CMakeLists.txt (line 107) I wonder if it can affect the whole project or at least other modules
<agateau> doko: it is supposed to only happen for gcc 2.95, but I would check nevertheless if you get there
<Daviey> pitti: I assume you agree with bug 828537 ?
<ubottu> Launchpad bug 828537 in meta-gnome2 (Ubuntu) "Please remove meta-gnome2 from the Oneiric archives" [Undecided,New] https://launchpad.net/bugs/828537
<agateau> doko: you can do printf-like debugging with cmake with the message() function.  I would add a few `message("CMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}")` in that CMakeLists.txt
<pitti> Daviey: yep, will do
<doko> agateau, cjwatson: passing -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo does work for me. so it looks like this should be passed by default in debhelper/cdbs
<agateau> makes sense to me
<cjwatson> can we just do that case-by-case for oneiric where it's needed, and file upstream debhelper/cdbs bugs with the aim of changing that across the board for P?
<cjwatson> sabdfl: I hope we're getting a name for P soon; we could do with encoding the name in a few places :)
<doko> heh, it has to be a Python ;-)
<doko> cjwatson, yes, that's my plan, didn't want to change it for oneiric
<pitti> seb128: keeping verbiste then; no rdepends, so easy to kill, but if you want to work on it, I'll keep it for a while
<pitti> I now went through the old applet rdepends, and removed most of them; I'll work on the others after lunch
<seb128> pitti, I don't "want" to work on it, I just said we shouldn't kick it out because the applet is broken
<pitti> seb128: *nod* the stuff that I removed were pure applets
<seb128> it has a --with-gnome-applet configure flag
<seb128> so should be trivial to turn the applet off
<debfx> cjwatson: in your mail about data.tar.xz you mentioned that it requires a Pre-Depends on dpkg. what about packages synced from Debian? I hope we don't need to change them.
<doko> cjwatson, agateau: so setting CMAKE_BUILD_TYPE seems to be always wrong. using RELEASE, you get no debug info, and with RelWithDebInfo, the flags passed by dpkg-buildflags are overwritten with the hard-coded default in cmake
<cjwatson> debfx: IMO dak should be fixed to require that too
<cjwatson> unless they've explicitly decided not to since squeeze had the requisite version, I guess
<cjwatson> debfx: but lucid doesn't have dpkg 1.15.6, so we have to do this at least until P releases because otherwise we'll cause failures for direct upgrades from lucid to P
<cjwatson> debfx: after P releases, I would be willing to drop that check in LP
<debfx> ok, in that case let's hope not too many maintainers decide to use xz compression
<cjwatson> debfx: a Pre-Depends for a while might not be too hard a sell, at least for those who are receptive to Ubuntu
<pitti> seb128: verbiste fix uploaded, FYI
<pitti> Laney: do you want me to create an experimental branch for this, or drop it in unstable? NB that in Debian, gnome-panel 3 is still in experimental
<pitti> Laney: there are two rdeps, tomboy and drapes; tomboy is fixed in ubuntu
<Laney> pitti: in experimental, yeah. Tomboy is fixed in exp too; I'll look at drapes soon (but probably remove it, seems pretty dead)
<Laney> if you do it in exp then we can just reupload to unstable when gnome-panel 3 goes
<pitti> Laney: want me to create a new experimental branch for this, or just use master?
<pitti> I suppose master is fine
<pitti> this isn't likely to get another unstable upload anyway, last one was from April 2010
<Laney> yeah, doubt it'll see an upload to unstable before then
<Laney> there's a bts bug you can close with the upload
<pitti> Laney: oh, handy
<Laney> good old joss
<pitti> yep, doing
<Laney> cheers
<pitti> Laney: I'm not an uploader, can you upload once I'm one, or want me to mark this as an SRU?
<pitti> sorry, NMU
<pitti> too many TLAs
<Laney> personally don't care if you do it as a maintainer upload
<pitti> ok
<Laney> part of the reason we allow all DDs write access to the branches
 * pitti sighs and installs 171 packages worth of build deps
<Laney> it's also why mono is small on the CD :P
<pitti> yeah, it's just 30 MB, so not too bad
<Laney> (doesn't take much time with a tmpfs overlay for me)
<pitti> Laney: oh, this isn't using git-buildpackage?
<pitti> at least gbp acts strangely
<Laney> yes, it should be
<Laney> did you branch upstream and pristine-tar?
<pitti> ah, sorry
<pitti> but still acting up
<pitti> no matter, I'll build it in-tree
<jdstrand> dholbach: hi! I need to reschedule my patch pilot today-- several items came up and I don't have enough hours in this day to do it
<Laney> erk
<directhex> is there a way to do a build of mono on one of the ubuntu buildds without affecting the package currently published for oneiric? upstream have given us a possible fix for the "doesn't build on vernadsky" problem we were having with epoll, but the only machines where it always failed were ubuntu buildds
<dholbach> jdstrand, sure, just move it to some other day that's better in the calendar
<Laney> pitti: looks like I forgot to push the changelog for -4, give me a second
<pitti> Laney: now, that's working nicely
<pitti> Laney: ah, just in time
<pitti> I'll rebase then
<Laney> weird, I even tagged it
<Laney> sigh
<jdstrand> dholbach: ok thanks. I moved it to next wednesday since this week seems pretty full already
<dholbach> jdstrand, whenever is good for you
<Laney> what in the world
<Laney> pitti: all yours
<pitti> Laney: cheers, rebased
<pitti> Laney: still a miracle how to build a clean source package -- it always deletes Makefile.in files, even with git-buildpackage -S -us -uc -nc
<pitti> regardless of how I build this, it alwasy complains about local changes
<pitti> I guess the clean rule gets in the way
<Laney> yeah, debian/rules there is pretty ancient
<pitti> ah, found a workaround, nevermind
<Laney> could do with some dh-autoreconf love at least
<pitti> 15998 2011-07-13 14:06 gnome-desktop-sharp2_2.26.0-4.diff.gz
<pitti> 15598 2011-09-07 15:13 gnome-desktop-sharp2_2.26.0-5.diff.gz
<pitti> wow!
<pitti> I managed to remove and add exactly the same number of bytes :)
<__z0rt__> in the hundreds column?
<pitti> Laney: uploaded/pushed
<Laney> great, thanks a lot!
<Laney> drapes has a large-ish popcon, i wonder how useful it is without the applet
<sabdfl> cjwatson, tell me about it, looks like the longest section in the darn dictionary!
<sabdfl> pitti, thanks for the digging, sounds like it's aptitude-specific and not related to our processes
<sabdfl> does soyuz publish changelogs now when it publishes packages, or is this still an out of band process?
<pitti> sabdfl: yes, it is
<pitti> sabdfl: LP has done something like that for quite a while now
<sabdfl> i ask because I'm usually most interested in the changelogs for recently updated packages, which are often not yet published
<pitti> https://launchpad.net/ubuntu/+source/gtk%2B3.0/+changelog
<sabdfl> oh, it is now?
<sabdfl> but that's not where apt-get or aptitude look, is it?
<pitti> but it's not a pure changelog, and invokes quite a lot of backend processing
<pitti> i. e. not just a flat file like changelogs.u.c. is
<sabdfl> i don't see why soyuz couldn't produce changelogs.u.c (and do the same for ppa's)
<pitti> sabdfl: right, apt-get/update-manager use changelogs.u.c., as these are plain files and thus scale better
<sabdfl> and also, why the archive metadata couldn't tell apt/aptitude where to find the cl's
<pitti> sabdfl: nothing stopping it in theory
<cjwatson> sabdfl: I think wgrant was talking about simplifying +changelog now that the full changelog is in the librarian
<sabdfl> that would be great, could even be a redirect
<sabdfl> wgrant, what say you to ^?
<sabdfl> ppa changelogs would be excellent
<wgrant> sabdfl: As of Lucid, update-manager looks in the archive for changelogs and not just on changelogs.u.c, so third-party archives can provide them.
<wgrant> My intention was to implement this in Soyuz a year ago, but it turned out to be harder than expected to remove them when the sources were removed.
<wgrant> Due to the way pools are divided by component.
<sabdfl> ah
<wgrant> And then I got hired before solving that.
<sabdfl> heh
<wgrant> But we have all the changelogs in the librarian now, so we can display them in the web UI easily.
<sabdfl> we have an easy way to write files, not to rm them?
<sabdfl> i'm more interested in helping apt / aptitude get them right now
<wgrant> And once someone works out how to keep them in the right component on the archive disk, we can publish them to update-manager.
<sabdfl> changelogs.ubuntu.com could in theory redirect, couldn't it?
<wgrant> changelogs.ubuntu.com is a bit of a special case. It could probably redirect, yes.
<wgrant> Not sure how much update-manager would like that, though.
<wgrant> It may be better to make the update process cheaper, and run it regularly as an LP API client.
<wgrant> Since it should just have to watch for recent source publications, and pull down their changelogs.
<wgrant> Pretty trivially cheap.
<wgrant> I'm not sure the LP API exposes changelogs easily yet, but that's literally a 2-line fix.
<__z0rt__> I'm not really new to c coding for the linux platform, per se, but I mainly *worked* with unix. So, I was wondering... is there something similar to fbsd's style (indent guide) for ubuntu?
<pitti> doko: I'm confused by https://bugs.launchpad.net/ubuntu/+source/seahorse/+bug/840611/comments/1, seems the packages weren't actually removed?
<ubottu> Launchpad bug 840611 in seahorse (Ubuntu Oneiric) "seahorse dropped the libcryptui-dev package, needed by almanah and seahorse-plugins" [High,Confirmed]
<doko> pitti, I just removed the binaries
<pitti> ah
<cjwatson> __z0rt__: Ubuntu is made up of many packages, and each one tends to have its own preferred style
<cjwatson> __z0rt__: it's much more important to adhere to the prevailing style of the code you're editing
<__z0rt__> ah, okay. thank you
<smoser> kees, if you would, https://code.launchpad.net/~smoser/ubuntu/oneiric/nagios-plugins/lp837085/+merge/74309 nagios-plugins is ready.
<cjwatson> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Daviey
<apw> pitti, i think what was happening was apport-gtk was crashing while trying to handle a crash
<apw> and we were going into a repeated cycle of that, with a new apport-gtk appearing repeatedly (differnt pids)
<pitti> apw: can you reproduce this when you run "apport-bug /var/crash/something"? do you get a stack trace on stdout?
 * apw will see whats in there
<apw> _usr_share_apport_apport-gtk.1000.crash .. i see i have an apport-gtk crash in ther
<apw> that seems 'bad'
<pitti> apw: can you pastebin the file? (or put on people etc.)
<apw> pitti, http://paste.ubuntu.com/684418/
<pitti> apw: hm, I fixed that yesterday -- what's yoru apport-gtk version?
<jtaylor> what does nbs stand for?
<pitti> jtaylor: "not built from source"
<pitti> i. e. a binary that is not built by anything
<pitti> usually old libraries or renamed packages
<jtaylor> ah ok, thx
<Daviey> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> cjwatson: do you think there's a realistic chance to fix gnash on armel, or sohuld we just remove the armel binaries?
<pitti> cjwatson: it seems to be the last rdepends of a whole lot of libav NBS stuff
<cjwatson> pitti: http://irclogs.ubuntu.com/2011/09/05/%23ubuntu-devel.html#t11:33 and http://irclogs.ubuntu.com/2011/09/05/%23ubuntu-devel.html#t16:24
<pitti> ah, thanks
<micahg> if someone feels it's pressing, please feel free to merge gnash, otherwise, I'll take care of it as soon as I have some time (when out of crisis mode)
<micahg> it might need an FFe as it's a new version, but should be easy to get approval
<pitti> yeah, it's easy enough to test
<pitti> micahg: not super-urgent, no
<pitti> thanks
<seb128> re
<seb128> pitti, thanks
<ahasenack> hi, can someone please nominate https://bugs.launchpad.net/ubuntu/+source/smart/+bug/244453 for lucid, maverick and natty? I added the SRU request to the bug and 3 debdiff files, one for each distro
<ubottu> Launchpad bug 244453 in smart (Ubuntu) "pycurl does not fail on authentication error" [Undecided,New]
<ahasenack> it's fixed in oneiric already
<stgraber> ahasenack: done
<ahasenack> stgraber: thanks!
<seb128> cjwatson, pitti, Laney: but the glib multiarch bug has been dupped from bug #835625
<ubottu> Launchpad bug 835625 in apt (Ubuntu Oneiric) "apt may try to unpack a foreign-arch multiarch library before the native package is at a multiarch version, prohibited by dpkg" [High,Triaged] https://launchpad.net/bugs/835625
<seb128> just for info
<Laney> ah, cheers
<seb128> -but
<tedg> Howdy, trying to get flash installed and it's not handling the multi-arch stuff.
<tedg> Which I heard was supposed to be fixed now.
<tedg> It seems to not go down the stack to install all the i386 libs.
<tedg> Is there anything I should try/get debug info?
<kees> smoser: hi! okay, looking at it now
<dholbach> Ursinha-holiday, enjoy!
<muneeb> which app is used to draw these kind of mockups? https://wiki.ubuntu.com/NotifyOSD?action=AttachFile&do=get&target=fallback-alert-mixed.jpg
<jcastro> muneeb: those are drawn by hand
<bdmurray> pitti: I'd like to add in the version of apport being used to apport bug reports do you have any preference as to where this happens?  The ubuntu general hook or the generic one?
<bdmurray> james_w: Do you happen to have a bzr plugin to modify a bug upon a cmmit?
<bdmurray> er commit
<james_w> bdmurray, I do not
<james_w> bdmurray, like set it fix committed or similar?
<bdmurray> james_w: well I want one to modify tags and remove a subscriber but yeah
<james_w> I don't know of such a thing, sorry
<james_w> how would it know which bug to modify?
<bdmurray> It'd be in the commit message
<bdmurray> or in the diff of the file I'm committing
<bdmurray> the latter makes more sense
<james_w> bdmurray, the post_commit hook point is likely what you would want. I'm not sure how to look at the diff given what is passed to it, but once you have that the rest should be straightforward if you want to give it a go
<bdmurray> james_w: thanks
<james_w> it's likely that you would have to generate the diff between the tree you get as an argument and its parent
<shnatsel|busy> hello everybody
<shnatsel|busy> I'm having trouble with Germinate again
<shnatsel|busy> I get "Permission denied (publickey)." error on remote branch checkout, whatever I try. I've managed to work that around using a local branch, but now it attempts to read "platform.oneiric" branch from the same location and can't find it.
<shnatsel|busy> man germinate doesn't mention any platforms
<shnatsel|busy> neither does the ubuntu-meta package
<Chipzz> shnatsel|busy: "Permission denied (publickey)." looks like an SSH error message. The problem very likely is that either a) you simply are not allowed access to the remote server or b) your key isn't properly loaded
<infinity> shnatsel|busy: As a quick workaround, you could branch platform.oneiric locally too, but it sounds like it's trying to get a r/w lock on the remote, which you quite likely don't have access to do.  bzr misconfiguration or some such?
<shnatsel|busy> Chipzz, infinity: yeah I tried all that, I'm OK with a local branch for now. I'm more concerned about the platform.oneiric thing that seems to be undocumented but required.
<infinity> shnatsel|busy: It's just a branch sitting next to ubuntu.oneiric.
<shnatsel|busy> infinity: yeah I see, what should it contain?
<infinity> shnatsel|busy: ubuntu/xubuntu/kubuntu all depend on it, STRUCTURE defines this.
<infinity> shnatsel|busy: It just contains.. More seeds.  Common seeds, so we don't have to change things in 3 places.
<shnatsel|busy> yeah, it's looking for STRUCTURE in that branch too...
<shnatsel|busy> infinity: OMG
<shnatsel|busy> infinity: thanks
<shnatsel|busy> huh, I can't even branch  bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.oneiric
<shnatsel|busy> same "Permission denied (publickey)."
<shnatsel|busy> removing "+ssh" returns timeout error
<shnatsel|busy> oh, it's Launchpad. lp: should do it.
<infinity> shnatsel|busy: The pubkey denial sounds like your default ssh key is one that LP isn't fond of.  You could just branch over http.
<shnatsel|busy> yep, LP did it
<shnatsel|busy> infinity: I'm now using 100% clean fresh Ubuntu Oneiric daily
<Seq> jdstrand: Thanks for fixing #843552! I reported it at about 0200 local time and was going to submit a patch today after work. You're very speedy.
<jdstrand> Seq: :)
<shnatsel|busy> hmmm, OK finally I made some seeds work
<shnatsel|busy> only locally though
<shnatsel|busy> bazaar's SSH drives me nuts
<cjwatson> shnatsel|busy: have you (a) run 'bzr launchpad-login' (b) set up ~/.ssh/config appropriately?  https://help.launchpad.net/Code/UploadingABranch has instructions
<cjwatson> set this up correctly once and you should not need to do it again
<shnatsel|busy> cjwatson: I had a valid LP login, it didn't help
<cjwatson> shnatsel|busy: have you specifically done both of the two operations I listed above?
<shnatsel|busy> cjwatson: I removed my LP login, it didn't help either
<cjwatson> I expect that your local username differs from your Launchpad username, and that you need to tell ~/.ssh/config about this.  As I say, instructions in the URL above.
<shnatsel|busy> cjwatson: I have a complex setup so I won't bother you with the details; I think I have enough info to deal with that now. Thanks for your help!
<cjwatson> (Either that, or multiple public keys and it's using the wrong one, or you haven't uploaded your public key(s) to Launchpad.)
<cjwatson> If it helps decouple things from bzr in your head, your system ought to be set up such that 'sftp bazaar.launchpad.net' works.
<hallyn> oneiric i386, when doing apt-get update (well it was a new install) i get Hash Sum Mismatch
<hallyn> then i can't install anything (pastebinit, openssh-server, etc)
<Daviey> hallyn: I think there is an issue with the archive atm.. it's been update-in-progres for hours
<Daviey> hallyn: I threw "91.189.92.170 archive.ubuntu.com" in my hosts which looks like a good mirror atm
<Daviey> (part of the a.u.c RR)
<hallyn> Daviey: thx!
<hallyn> Daviey: (that actually didn't work for me;  hope that'll get fixed soon)
<Daviey> hallyn: :(, sorry.
#ubuntu-devel 2011-09-08
<robert_ancell> how do I find why a package has been removed from the archive?
<ajmitch> the publishing history on launchpad should show a reason
<ajmitch> there should be a link in the top-right of the page for the package
<robert_ancell> ajmitch, cheers!  screenruler is gone.  I used that a lot...
<ajmitch> looks like it needed a bit of love
<ScottK> I guess you'd have to love it enough to port it to Gnome 3.
<ajmitch> & you'd need to love ruby, I don't know what the state of the bindings are there
<ScottK> Oddly enough, I just uploaded updated Qt and KDE bindings for Ruby.
<pitti> Good morning
<ajmitch> morning pitti
<pitti> bdmurray: I think we can add the complete Ubuntu revision in the ubuntu hook, as we often have ubuntu revision specific changes
<pitti> hey ajmitch, how are you?
<ajmitch> pitti: I'm good, how are you today?
<pitti> ajmitch: very good, thanks!
<didrocks> good morning
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
<dholbach> good morning
<sladen> Morgen Damen und Herren!
<OdyX> is persia usually around ?
<tumbleweed> OdyX: he's not been around for the last month
<geser> OdyX: I didn't see him for some time now, I don't know if there a better way to reach him
<tumbleweed> word is he's due back some tmie soon
<OdyX> okay. I'll do without his feedback for my DC11 report then.
<dholbach> smb`, happy birthday
<doko_> Sweetshark, should that be removed? if yes, please leave a comment. https://bugs.launchpad.net/ubuntu/+source/ooo-build-extensions/+bug/755987
<ubottu> Launchpad bug 755987 in ooo-build-extensions (Ubuntu Oneiric) "ooo-build-extensions version 3.0.0.9+r14588-9 failed to build on i386" [High,Confirmed]
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dholbach> didrocks, good work
<seb128> dholbach, can we move the importer bugs to another list? ;-)
<seb128> dholbach, that's really spamming the sponsoring queue for things which are not sponsoring
<didrocks> dholbach: thanks :)
<dholbach> bdrung_, tumbleweed: ^ what do you think?
<cjwatson> agreed, that would be a good idea
<didrocks> yeah, I just cleaned the obvious noise one, to let "real issues for investigation" for udd people
<didrocks> but it's quite noisy in the list
<seb128> didrocks, don't complain, cjwatson already cleaned a whole stack of those yesterday ;-)
<dholbach> maybe we could add a new table for them at the bottom and not include them in the stats either
<didrocks> seb128: yeah, I just continued on this :)
<seb128> dholbach, I think they should be better on a list like nbs,e tc
<dholbach> and add other tables like "sru nomination" there as well
<seb128> they are really not sponsoring
<seb128> they are archive? cleaning
<cjwatson> yeah, they're moving around things that people with commit access already committed
<cjwatson> practically by definition they aren't sponsoring
<dholbach> ok, then I guess that should be a list on Harvest
<dholbach> I'll file a bug about the package import thing then
<seb128> dholbach, why harvest?
<seb128> they are not really opportunities
<seb128> they are things that need a review and be cleaned regularly
<dholbach> where do you feel would be a prominent enough place for them?
<seb128> we should have a list on a people page or a launchpad query url?
<seb128> well, harvest would work as well I guess
<dholbach> ok filed a bug about it
<dholbach> bug 844659
<ubottu> Launchpad bug 844659 in ubuntu-sponsoring "Filter out ~package-import merge proposals" [Undecided,New] https://launchpad.net/bugs/844659
<seb128> dholbach, danke! ;-)
<dholbach> (and added a comment to bug 833706)
<ubottu> Launchpad bug 833706 in ubuntu-sponsoring "Show pending SRU nominations" [Undecided,New] https://launchpad.net/bugs/833706
<pitti> can we use .tar.xz orig tarballs in Launchpad now?
<pitti> upower only publishes xz tarballs these days
<pitti> I saw cjwatson's announcement for data.tar.xz, but that's for binary packages
<Laney> yes
<cjwatson> pitti: xz source tarballs have worked for considerably longer
<pitti> ok, thanks
<cjwatson> ubiquity uses one
<Daviey> barry: ISTR you were looking at a dupe of bug 827271, but can't find it right at the moment.  If you were, how is it looking?
<pitti> they work for Debian now, too, so I can just upload/sync that one
<ubottu> Launchpad bug 827271 in lazr.restfulclient "warning about "Module paste was already imported from None, but /usr/lib/python2.7/dist-packages is being added to sys.path"" [High,Confirmed] https://launchpad.net/bugs/827271
<pitti> cjwatson, Laney: thanks
<cjwatson> landed on LP trunk 2011-03-26 (r12667)
<Laney> colord was synced with .origi.tar.xz
<Laney> yes, .origi!
<gotwig> hey
<gotwig> cjwatson: hey, could I ask you something about the "seed" system ?
<cjwatson> sure
<gotwig> cjwatson: PM ?
<cjwatson> gotwig: is it private somehow?
<gotwig> no :P
<cjwatson> here is fine then
<gotwig> cjwatson: so how does the "seed" system excactly work
<gotwig> I dont understand it :/
<gotwig> does it only use ubuntu, or debian and other distros, too ?
<cjwatson> gotwig: seeds are just a set of top-level lists of package names, which are expanded based on their dependencies in a particular distribution
<cjwatson> gotwig: it's certainly possible to expand seeds based on Debian or other distributions, but we only do so based on Ubuntu
<gotwig> cjwatson: so why you dont simply use apt-get ?
<cjwatson> gotwig: there are a number of contexts where we need to be able to predict what will happen without having an apt state conveniently available
<cjwatson> gotwig: for actual installation we do in fact simply use apt-get (although typically, the task or metapackage it's installing is constructed based on seeds)
<cjwatson> seeds are a build-time thing, not a run-time thing
<gotwig> cjwatson: oh thanks for help :-)
<gotwig> cjwatson: and can two packages have the same file?
<cjwatson> gotwig: could you be more specific?
<pitti> didrocks: I'm setting all your "WIP" package importer branches to "rejected"
<pitti> really, pre-applied patches with .pc/ in bzr is utter utter madness
<didrocks> pitti: oh, you have this power? lucky guy :)
<pitti> developers can't get it right, the package importer can't get it right, bzr mu can't get it right
<gotwig> cjwatson: as example, there is a configuration file in /etc/* , but I want to use an other configuration as specifified in that config file. Can I install an package, that "overwrites" the standard installed config file from the first package
<pitti> it makes commits very hard to read, and is not what you generally expect when you have broken out patches in the first place
<cjwatson> pitti: unapplying the patches out of sync with the importer is worse
<pitti> </rant>
<pitti> (that's also one of the big reasons why we mostly don't use them in the desktop team)
<Daviey> pitti: you don't enjoy reviewing .pc/* ? :)
<cjwatson> gotwig: you have to use the Replaces field; whether it will do the right thing with any particular configuration file is a different matter
<pitti> Daviey: I still don't know how to tear apart a chicken to commit the result of  adding a new patch so that the importer doesn't yell at me
<pitti> Daviey: apparently you have to add some, but not all, of the new files in .pc
<cjwatson> all but dotfiles
<cjwatson> (I don't know why the importer doesn't import dotfiles)
<gotwig> cjwatson: so when the first package upgrades, will it remove my configuration trought the 2.th package?
<Daviey> I've just added them all.. but when in doubt or lazy, let the importer handle it. :/
<pitti> that's what I tried in one of my more recent updates (not import dotfiles)
<Daviey> not really cricket.
<cjwatson> pitti: works for me
<pitti> seems we didn't get a conflict there indeed
<cjwatson> gotwig: it shouldn't if you've used Replaces, but I would strongly advise testing carefully
<pitti> but still, this is so far apart from easy and intuitive..
<gotwig> cjwatson: thanks again
<Daviey> pitti: Have you tried UDD for SRU's?
<pitti> Daviey: only for sponsoring
<pitti> Daviey: I use the UDD branches for native packages
<cjwatson> I wouldn't be wholly opposed to the importer changing to unapplied-patches, but it needs to be actually coordinated
<pitti> Daviey: but in my very personal opinion they are broken by design right now for patched packages
<cjwatson> although I strongly believe that applied-patches is the correct default for dpkg-source -x
<Daviey> cjwatson: That would sensible, we can't start doing things that make sense.
<pitti> we either need to keep broken-out debian/patches/* stuff, or use proper threads, without debian/patches/* stuff, but not both
<cjwatson> that way users can see what code is actually being built, you know, radical suggestion
<gotwig> :)
<pitti> Daviey: and they don't work at all for packages where the packaging branch is a branch of upstream trunk in bzr
<chrisccoulson> this is one reason why i don't use UDD branches for stuff i maintain
<cjwatson> developers using bzr branches might be expected to know more about the source package format though
<cjwatson> pitti: yes they do
<Daviey> I hoped that bzr would become quilt .pc aware, and just suck it in and hide it from me.
<cjwatson> pitti: I do it personally, not making it up :)
<pitti> cjwatson: not for me
<cjwatson> pitti: in fact they work *best* that way - you get unified bzr blame across packaging and upstream changes
<pitti> cjwatson: as they have no relationship at all with trunk
<cjwatson> which is the reason I like applied-patches
<cjwatson> pitti: not the auto-imported branches, but a manually-imported branch with the right structure can be persuaded to play nicely
<pitti> right, I mean the auto-imported ones
<Daviey> cjwatson: Really, never - ever look at the eucalyptus branch.
<pitti> for some packages with manual history we pushed them "over" the auto-import ones, and then things work of course
<cjwatson> we aren't at a sufficiently late phase of the grand plan to have auto-imports based on upstream imports
<cjwatson> although it is in the grand plan
<Daviey> cjwatson: That was an experiment of importing from upstream bzr.. into our bzr
<pitti> anyway, my venting aside, I cleaned your reviewed branches; thanks didrocks
<cjwatson> that usually works fine as long as you're careful to have an intermediate branch representing release tarballs
<cjwatson> which is, granted, fiddly
<cjwatson> Daviey: the inability to push to lp:ubuntu/natty-proposed/package or whatever until an upload has been accepted and imported is the main problem for SRUs
<Daviey> cjwatson: Before my time, it was experiemented of just re-merging from upstream which had an intermediate commit removing the upstream tarball.
<Daviey> It didn't use patches, which meant it was essentially a fork
<didrocks> pitti: thanks for setting to rejected. Will directly ping you next time rather than the "WIP workaround"
<Daviey> measuring the delta was impossible.
<cjwatson> ooh, I think I found the octave commit that unbreaks octave-symbolic
<pitti> didrocks: fine for me
<pitti> didrocks: we just can't reject them wholesale, sometimes there's an actual problem there
<pitti> so they still need careful review
<cjwatson> (SRUs> bug 668948)
<didrocks> pitti: indeed, that's why I didn't unset the whole list
<ubottu> Launchpad bug 668948 in Ubuntu Distributed Development "nowhere to push branches for an initial upload to lucid-proposed" [Undecided,New] https://launchpad.net/bugs/668948
<pitti> not sure why we get so many which are completely empty, though
<cjwatson> pitti: in cases where the MP is empty, the trees are usually still slightly different - it's just that merging has no effect because one is a subset of the other
<cjwatson> now and again I decide that it's worth merging richer history in such case
<cjwatson> s
<cjwatson> or re-merging, since the MP is for the original contents of the branch
 * Daviey wonders how many people actually check to see if there staging commits in the UDD branch.
<Daviey> (before uploading, not using UDD)
<Snicksie> hi all, i'm trying to get involved in helping developing ubuntu, ive read https://wiki.ubuntu.com/ContributeToUbuntu and https://wiki.ubuntu.com/UbuntuDevelopment but i still find it difficult to know how I can help... anyone who can help me further with this?
<Daviey> Snicksie: We like builds to be reproducible, we have an awful lot of packages that are failing to rebuild right now.  That would be a good area of contribution.
<Snicksie> what do I need to help with that, Daviey ? :)
<Daviey> Snicksie: Do you have a pbuilder or sbuild enviroment?
<Snicksie> I installed all this stuff: sudo apt-get install --no-install-recommends bzr-builddeb ubuntu-dev-tools fakeroot build-essential gnupg pbuilder debhelper
<Snicksie> it includes pbuilder :)
<Daviey> Snicksie: pbuilder-dist oneiric i386 create <-- create env
<Daviey> pull-lp-source qucs <-- grab the source package, of something reported to not build
<Daviey> Snicksie: pbuilder-dist oneiric i386 build qucs*dsc <-- build it in a clean chroot, to check it's valid.
<Snicksie> i've got an error, will paste the error
<Daviey> Snicksie: bug 756183, is all yours.
<ubottu> Launchpad bug 756183 in qucs (Ubuntu Oneiric) "qucs version 0.0.15-1 failed to build on i386" [High,Confirmed] https://launchpad.net/bugs/756183
<Snicksie> http://pastebin.ws/aynmva
<Daviey> Snicksie: Archive mirror you are using is poorly for oneiric.
<Snicksie> how can I fix that? :p
<Daviey> Snicksie: annoyingly, you are probably better off just waiting - but it's a good chance to do some reading :)
<Snicksie> okay, have you got some suggestions about what to read? :)
<Snicksie> wait, this time it works :p
<Snicksie> Daviey, does it automatically create a build-log?
<Daviey> Snicksie: yes, ~/pbuilder/oneiric-i386_result/last_operation.log iirc
<Snicksie> okay :) So all I have to do now is waiting till it stops building? Should I do anything else, like assigning the bug to myself? What should I do after the build ended (successfull or not)?
<Snicksie> okay, it failed already...
<Daviey> Snicksie: I'm really sorry, but i can't give you my full attention at the moment.  You may also be able to get help in #ubuntu-motu ...
<Snicksie> okay, will ask there :)
<Daviey> Snicksie: doing http://pb.daviey.com/Cqow/, should give you a shell if the build fails... that you can poke it, and run "debian/rules binary" to experiment to find a fix
<cjwatson> I generally only assign build failure bugs to myself once I've done a little initial investigation to determine that I have some hope of fixing it
<Snicksie> Daviey, can I also use gedit (or another editor) to edit instead of only command-line?
<Daviey> Snicksie: Hmm.. you can, not easily tho.
<valavanisalex> Hi there, a new bug-fix-only version of Inkscape (0.48.2) is packaged in oneiric.  If I want to upgrade the natty (0.48.1) & maverick (0.48.0) packages, is it better to do this as an SRU or a backport?
<cjwatson> backport
<Laney> someone just requested a backport of that, was it you?
<valavanisalex> Thanks... I thought backports had to include new features
<Snicksie> Daviey, found out, I found the package in my home-directory and edited the file i wanted with gedit...
<cjwatson> valavanisalex: it's more that SRUs normally must be targeted fixes only
<valavanisalex> No I didn't request the backport, but I saw the request
<valavanisalex> cjwatson: great - thanks for the clarification.  I'll start work on the backport checking then.
<bdrung_> dholbach: done.
<Daviey> Snicksie: Sorry, i thought you mean't within the pbuilder enviroment
<bdrung_> dholbach: why is "Time in Queue" unknown, but correct in my local run: http://people.ubuntu.com/~bdrung/sponsoring/ ?
<Laney> valavanisalex: there are some reverse dependencies ink-generator zoomer that you should check still work
<valavanisalex> Laney: will do.  Thanks.
<ahasenack> hi, can I get a sponsor for this SRU? https://bugs.launchpad.net/smart/+bug/244453
<ubottu> Launchpad bug 244453 in smart (Ubuntu Natty) "pycurl does not fail on authentication error" [Undecided,New]
<Snicksie> yeah, that was preferrable, but this >should< work too . unfortunately it doesnt really seem that any of my changes change... Is it because it uses the archives or because my change isn't really a change? :p
<Snicksie> ah, it seems to be in the tmp
<Daviey> ahasenack: didrocks, micahg and kenvandine are patch pilots today (or scheduled to be).. see if they can..
<didrocks> Daviey: on unity releases, that's why I did my patch piloting really early :)
<seb128> kenvandine is on holidays this week
<ahasenack> so, micahg, whenever he comes in
<ahasenack> almost 8:00 there, should be one our more or so
<Daviey> ahasenack: I just subscribed ubuntu-sponsors, that increases the changes of it getting sponsored :)
<Daviey> If nobody does it in the next few hours, i will have a look over it.
<ahasenack> Daviey: uh, I thought I only needed to subscribe the sru team
<ahasenack> who is ubuntu-sponsors?
<Laney> the sru team review from the queue
<ahasenack> a superset of the sru team?
<Daviey> ahasenack: Normally it bakes in the unapproved queue, then the SRU team look at it, and accept or reject it based on the SRU report.
<ahasenack> Daviey: so ubuntu-sponsors are the ones who upload to this queue
<Daviey> ahasenack: People who want to do sponsoring,
<Daviey> as in, some archive access.
<ahasenack> Daviey: ok, thanks
<dholbach> bdrung_, tumbleweed might know - I think it's something to do with permissions - AFAIR Stefano changed it to anonymous authentication
<dholbach> bdrung_, thanks - I'll have a look at the branch in a bit
<Laney> that was reverted
<bdrung_> dholbach: we reverted the anonymous authentication
<dholbach> bdrung_, ah great
<dholbach> bdrung_, updated r122 â r125
<dholbach> so that should fix the auth problem too
<pitti> sabdfl: looks like there's not much on topic for today's TB meeting?
<jml> kirkland: how could I tell if I was running powernap?
<kirkland> jml: sudo status powernap
<jml> kirkland: unknown job. I guess that means "no".
<kirkland> jml: that's a "no", then
<sabdfl> hey pitti
<smoser> SpamapS, slangasek bug 839595 has some interesting/expected comments from a user.
<ubottu> Launchpad bug 839595 in upstart (Ubuntu) "failsafe.conf's 30 second time out is too low" [High,Fix released] https://launchpad.net/bugs/839595
<bdrung> Laney: do we need a FFe for u-d-t 0.129?
<Laney> yes, but I'll approve it
<bdrung> Laney: bug #844869
<ubottu> Launchpad bug 844869 in ubuntu-dev-tools (Ubuntu) "FFe: Sync ubuntu-dev-tools 0.129 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/844869
<Laney> bdrung: done, I added an lptools task for you
<bdrung> Laney, tumbleweed: do you know if LP closes bugs automatically if you close them in the changelog and use the new sync API?
<Laney> bdrung: https://bugs.launchpad.net/launchpad/+bug/833736 went to Fix Released, so I guess it is supposed to
<ubottu> Launchpad bug 833736 in Launchpad itself "copyPackages() doesn't close LP bugs" [High,Fix released]
<doko> Sweetshark, ooo-build-extensions ping
<tumbleweed> bdrung: it's no supposed to, yes
<tumbleweed> now
<tumbleweed> haven't tested it
<Laney> we'll see if it works
<Laney> give it a go
<bdrung> ok, let's see if it works. :)
<Sweetshark> doko: im in conf call
<Sweetshark> later
<tumbleweed> dholbach: did I understand correctly from the backscroll, that you bzr updated ubuntu-sponsoring, and it's sane again?
<dholbach> tumbleweed, with a bit of confusion it should, yes
<tumbleweed> cool
<tumbleweed> you are wanting to move the out of date UDD branches into a separate table? will that not lead to them being neglected?
<tumbleweed> that code must really be broken into seperate download and render jobs, for ease of development...
<Laney> auto closing seemed to work
<Laney> nice
<tumbleweed> \o/
<bdrung> Laney: really?
<bdrung> haven't received a mail
<bdrung> great, it works.
<brendand> does old-releases.ubuntu.com have an rsync server?
<micahg> ahasenack: sorry, not piloting today, I might be able to sponsor something late tonight
<soren> brendand: Why don't you just try?
<ahasenack> micahg: so no pilots today? ok
<soren> brendand: "rsync old-releases.ubuntu.com::" isn't that hard.
<ahasenack> micahg: I think zul was going to sponsor it
<zul> ahasenack: is this the smart stuff?
<ahasenack> zul: yes
<zul> ahasenack: already taken care of
<ahasenack> zul: ah,cool, thanks
<micahg> ahasenack: didrocks piloted earlier, sorry, still cleaning up after DigiNotar
<ScottK> didrocks: If I read Bug #823061 correctly, that change got uploaded before the FFe review was done.  Is that correct?
<didrocks> ScottK: no, the release is just happening now
<didrocks> ScottK: it has been merged *upstream* before the FFe review was done
<didrocks> ScottK: I warned dx about it
<didrocks> ScottK: and now it's sorted out
<ScottK> didrocks: OK.  It seems someone got the bug tasks a bit mixed then.
<ScottK> That or I read it wrong.
<ScottK> Thanks.
<didrocks> ScottK: yeah, the unity-2d task shouldn't be fix released, Kaleo push it by error
<Kaleo> didrocks, ScottK: sorry about that :)
<ScottK> Kaleo: No problem.  Things happen.
<didrocks> ScottK: so right now, the doc team acked the freeze and in a few hour, we will get unity and unity-2d upload fixing this ui bug
<ScottK> didrocks: I think you should answer pitti's concern too.
<didrocks> ScottK: that was discussed between jbicha, pitti and njpatel on #ubuntu-desktop
<ScottK> Ah.  OK.
<ScottK> Great then.
<ScottK> Please note that in the bug then.
<didrocks> sure, doing
<doko> barry, fyi, flufl packages still ftbfs in oneiric
<Sweetshark> doko: wrt bug 755987, never knew much about that package, but it is still available in debian sid and the breaker seems to be just a update of the dep from openoffice.org-dev to libreoffice-dev ...
 * Sweetshark tries a small and simple fix.
<doko> Sweetshark, thanks!
<barry> doko: dang
<doko> barry, ahh, wait, that was lazr.* ...
<doko> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110816-oneiric.html
<barry> :)
<barry> doko: i'll look at those
<doko> barry: other two popular maybe are python-event (needs porting to libevent2, and in NBS), and maybe python-lucene, but scan the page yourself ...
<barry> doko: yep, i've been looking at python-related packages off that page
<bdrung> tumbleweed: what's your idea how to fix bug #823832?
<SpamapS> smoser: you answered his questions the same way I would have. :)
<tumbleweed> bdrung: this isn't the only thing that requires people doing ubuntu-dev on debian systems to add an /etc/dpkg/origins/ubuntu (for example, you need to do that to generate Launchpad-bugs-fixed)
<bdrung> tumbleweed: but then backporting from debian to ubuntu is still broken
<tumbleweed> yes
<Laney> let the user specify a vendor in -s/-d?
<Laney> -s ubuntu/maverick ...
<bdrung> tumbleweed: what do you think about using the vendor chain and then hardcode ["ubuntu", "debian"] after that?
<bdrung> Laney: ^
<Laney> I don't know what the vendor chain is
<bdrung> Laney: ubuntutools/misc.py -> system_distribution_chain
<bdrung> says: Detect the system's distribution as well as all of its parent
<bdrung>     distributions and return them as a list of strings, with the
<bdrung>     system distribution first (and the greatest grandparent last). If
<bdrung>     the distribution chain can't be determined, print an error message
<bdrung>     and return an empty list.
<bdrung> this will be ["debian"] on debian and ["ubuntu", "debian"] on ubuntu
<bdrung> tumbleweed, Laney: proposed fix: system_distribution_chain
<bdrung> http://paste.ubuntu.com/685382/
<tumbleweed> bdrung: seems plausible
<tumbleweed> I think we need a documentation file / wikipage for doing ubuntu-dev on debian
<Laney> hmm
<Laney> why not just make it search all known distros?
<Laney> seems weird to special case like that
<tumbleweed> Laney: it's ubuntu-dev-tools, the only distro it absolutely has to search is Ubuntu (and debian is the parent, so it should be searched after ubuntu)
<tumbleweed> but yeah, it's overly generic when there are only 2 distros that matter here :)
<broder> blame persia for that - he gave me crap when i proposed a non-generic solution :-P
<Laney> I just mean to make codename_to_distribution independent of the current distribution
<broder> the goal was to leave room to make backportpackage useful for ubuntu derivatives
<broder> i don't really know if i succeeded or not
<bdrung> broder: btw, mint uses ubuntu as deb_vendor
<pitti> didrocks, ScottK: yeah, my concern is that these features should be FFEed first and then have work effort assigned to it
<pitti> otherwise it's rather pointless
<ScottK> Agreed.
<Sweetshark> arrgh
<Sweetshark> anyone around who can help me out with how udd is supposed to work?
<ScottK> barry knows everything about UDD.
<Laney> Is the hot new syncpackage going to be announced now that it's in? :-)
<tumbleweed> bdrung: does mint rebuild?
<ScottK> Laney: Is there some agreement on how and when it should be used?
<Laney> it's not suitable for sponsoring yet (due to attribution), but otherwise for requested syncs
<Laney> AFAIK anyway
<ScottK> Probably someone like cjwatson should write a mail to u-d-a if he thinks it's ready for general use.
<pitti> Laney: is that in ubuntu-dev-scripts? I thought that syncpackage script was just an improvement of my original hack which just crafts an appropriate .changes file for a .dsc?
<Laney> pitti: Yeah. It was that, but now it uses the LP API to do it properly.
<pitti> nice!
 * pitti dist-upgrades
<bdrung> tumbleweed: probably no (just add packages)
<Laney> give LP much kudos for that
<bdrung> Laney: there is still the bug that the syncer isn't credited
<Laney> that's got a branch being reviewed now.
<ScottK> " ... feel free to use it now if you aren't vain enough to care about who gets credit for the upload in Launchpad."
<Sweetshark> I did 1) bzr branch ubuntu:ooo-build-extensions 2) modify debian/control 3) modify source 4) dch "move dependencies to libreoffice (LP: #755987)" 5) dch "move build paths to libreoffice"
<Sweetshark> how do I continue? 6) bzr commit && bzr push lp:~bjoern-michaelsen/ubuntu/oneiric/ooo-build-extensions-lp755987 ?
<Laney> ScottK: it means you don't get emailed about build failures though
<ScottK> True, but I tend to not rely on email for that anyway.
<Laney> Experience tells me some people do ;-)
<ScottK> No doubt.
<ScottK> Plenty seem to not manage to notice even with the email.
<Sweetshark> pitti: would you sponsor a fix for bug 776594? if so, how should I publish the fix?
<ubottu> Launchpad bug 776594 in ooo-build-extensions (Ubuntu) "failed to remove openoffice.org-coooder during upgrade to natty. Openoffice is running" [Medium,Confirmed] https://launchpad.net/bugs/776594
<Sweetshark> pitti: ups
<Sweetshark> pitti: wrong bug hang on
<Sweetshark> pitti: bug 755987
<ubottu> Launchpad bug 755987 in ooo-build-extensions (Ubuntu Oneiric) "ooo-build-extensions version 3.0.0.9+r14588-9 failed to build on i386" [High,Confirmed] https://launchpad.net/bugs/755987
<Sweetshark> pitti: https://code.launchpad.net/~bjoern-michaelsen/+junk/ooo-build-extensions-lp755987 does this mix of dpatch and udd work?
<mdz> sabdfl, you're chairing tech board today?
<pitti> hey Sweetshark
<pitti> Sweetshark: just r10? or more?
<pitti> Sweetshark: UDD and dpatch are completely different things, so that should be ok
<bdmurray> pitti: https://code.launchpad.net/~brian-murray/apport/add-apport-version/+merge/74659
<pitti> Sweetshark: posted on the bug; needs dpatchification indeed
<pitti> bdmurray: ah, thanks! merging
<bdmurray> pitti: no problem, thank you.  This should help some confusion I sometimes have. ;-)
<bdrung> tumbleweed: time for another upload?
<bdrung> of u-d-t
<bdrung> tumbleweed: care about fixing bug #844992?
<ubottu> Launchpad bug 844992 in ubuntu-dev-tools (Ubuntu) "requestsync environment variable documentation out of date" [Undecided,New] https://launchpad.net/bugs/844992
<bdrung> tumbleweed: and bug #791956?
<ubottu> Launchpad bug 791956 in ubuntu-dev-tools (Ubuntu) "[sponsor-patch] does not work properly with uploads to -proposed" [Medium,New] https://launchpad.net/bugs/791956
<doko> jamespage, still online? could you have a look at libspring-2.5-java? currently ftbfs, the ubuntu changeset can be dropped, but I didn't check for updated dependencies
<jamespage> doko: ack - can't do now but will first thing tommorow
<doko> jamespage, thanks, but no haste, just for oneiric
<doko> Daviey, just gave back fbasics and fgarch in the test archive. still ftbfs. could you reopen the reports?
<bdrung> ScottK: you did the change in requestsync that causes bug #844992. will you update the man page?
<ubottu> Launchpad bug 844992 in ubuntu-dev-tools (Ubuntu) "requestsync environment variable documentation out of date" [Low,New] https://launchpad.net/bugs/844992
<ScottK> bdrung: I can't promise when I'll get to it.
<ScottK> I don't generally hack on u-d-t, it was more of a it suddenly broke, so it needed to get fixed ASAP kind of thing.
<bdmurray> @pilotin
<udevbot> Error: "pilotin" is not a valid command.
<bdmurray> @pilot-in
<udevbot> Error: "pilot-in" is not a valid command.
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray
<bdmurray> How or who can set https://code.launchpad.net/~jtaylor/ubuntu/natty/pyfltk/fix-779340/+merge/68194 to merged?
<bdmurray> cjwatson: How or who can set https://code.launchpad.net/~jtaylor/ubuntu/natty/pyfltk/fix-779340/+merge/68194 to merged?
<hallyn> bzr branch lp:ubuntu/natty/libvirt libvirt-n
<hallyn> bzr: ERROR: Revision {james.westby@ubuntu.com-20110318080232-bskde7dqc2icfixv} not present in "Graph(StackedParentsProvider(<bzrlib.repository._LazyListJoin object at 0x2eb6ed0>))".
<micahg> hallyn: as an aside, you most probably want natty-proposed or natty-security
<hallyn> micahg: well that's one i've asked about before:  natty-proposed does not exist in bzr
<hallyn> i'm not allowed to create it
<micahg> hallyn: right, UDD needs to create it, it should be done automatically once an upload happens
<micahg> which already has happen which means it's an importer failure
<hallyn> so is there a way to force it?
<hallyn> to help UDD along?
<micahg> file a bug against the UDD project for the import failure if one doesn't exist
<hallyn> That exists
<hallyn> micahg: but so noone is ablt to do a 'bzr push' to force it to happen? :)
<micahg> hallyn: not that I know of
<hallyn> micahg: thanks
<micahg> hallyn: maybe ask poolie nicely to have someone fix the import failure
<ScottK> doko: Can you take a look at the kdesdk FTBFS on powerpc?  We've got no developer in the Kubuntu team with powerpc hardware, so we need some help.
<hallyn> poolie: pretty please?
<doko> ScottK, sorry, not for oneiric. however everybody within Canonical could do this
<ScottK> doko: There's no Canonical representation among Kubuntu developers this cycle.
<sbeattie> So how am I supposed to unwind a quilt patch where a merge from debian modified one of the files in the patch, such that the original file in .pc/patch/ is now different from what the file would look like with the quilt patch popped off, causing quilt to complain that the patch does not remove cleanly.
<doko> ScottK, Riddell didn't loose his permissions while on rotation ;) and I'm not Kubuntu for sure
<ScottK> Well, no he didn't, what he lost was time.  I'll see if I can find someone.
<doko> sorry, lacking time myself
<micahg> sbeattie: quilt pop before merging
<ScottK> Ohh.
<ScottK> micahg: Any chance you could help out with my powerpc FTBFS? ^^^
<micahg> ScottK: hah, figured you would ask me, definitely not this week, if things slow down next week, I can try
<ScottK> OK.  Thanks.
<sbeattie> micahg: blah, okay.
<doko> heh, he did volunteer to fix armel NBS first :-P
<micahg> ScottK: just poke me if you don't hear from me by mid-next week
<ScottK> OK.
<micahg> doko: this is true...
<sbeattie> micahg: oh, bleah, the patch in question still doesn't unapply cleanly.
<micahg> sbeattie: sorry, did you pop -a to get them all?
<sbeattie> micahg: I'm trying to do the initial pop before merging, for this package (openssl) the last (first to be popped off) in the series fails to pop off.
<micahg> orly? maybe the importer failed on it?
<micahg> nope, weird...
<barry> ScottK: hey, if you want to spot me $200 to fix the power supply on my ol' dual-g5, i'd be willing to look into it <wink>
<barry> sbeattie: still having trouble with quilt?
<sbeattie> barry: yes, still trying to unwind a .pc that's out of sync without losing changes. I think force-popping and the updating the patch to apply will fix it, but I'm fearing that I'll end up reverting a change that I shouldn't.
<barry> sbeattie: is this a udd branch (i.e. bzr branch ubuntu:foo ?)
<sbeattie> barry: yes
<barry> sbeattie: okay, first, i sympathize ;)   second, i do this all the time.  just finished one with python-virtualenv, so i will try to help ya!
<barry> sbeattie: when you first get the branch, all the patches are applied
<barry> sbeattie: so, e.g. when i wanted to merge-upstream, i first did `quilt pop -a` to get a pristine source branch
<barry> sbeattie: then i did the bzr merge-upstream and committed those changes
<sbeattie> barry: as an aside, that should get added to http://developer.ubuntu.com/packaging/html/udd-merging.html
<barry> sbeattie: then i had to verify/update all the patches.  indeed they all failed to apply cleanly, so one-by-one i did the following:
<barry> sbeattie: best to file a bug on ubuntu-packaging-guide for that
<barry> sbeattie: okay, so what *i* do (which i am not claiming is the best way to do it, but iwfm)
<barry> quilt push -f
<sbeattie> barry: in this case, I reverted all changes to my merge (bzr revert); however, the last patch in the series after the revert still fails on quilt pop
<barry> then apply any .rejs manually, fix any other patch problems, etc.  then `quilt refresh`
<barry> rinse & repeat
<sbeattie> (the last patch in the series is an ubuntu applied patch not in debian)
<barry> sbeattie: so right after you grab the branch, you can't pop -a ?
<barry> sbeattie: what's the branch url?
<sbeattie> barry: lp:ubuntu/openssl
<barry> sbeattie: let me try it...
<barry> sbeattie: okay, i did this:
<barry> bzr branch ubuntu:openssl oneiric
<barry> cd oneiric
<barry> quilt pop -a
<barry> and that succeeded
<barry> sbeattie: can you try again with a clean branch?
<sbeattie> barry: how odd; bzr st tells me I have no changes (and I did no commits) and it fails.
<sbeattie> barry: yeah, will do.
<barry> sbeattie: those .pc directories kill you every time
<barry> sbeattie: yeah
<sbeattie> as a quilt user for 6+ years, checking them in feels very, very wrong to me.
<barry> sbeattie: yeah, it's a design goal of udd to want the source branch to have all patches applied, but it gets very very tricky
<barry> i usually end up doing all my work in a separate branch, then do a final merge back into ubuntu:foo and revert any .pc directory changes before i commit and push
<barry> i can pretty much get reasonable results now, but it's a known problem that the udd/bzr guys are working on
<tumbleweed> bdrung: err, no I think the pull-lp-source patch was nice (if hacky), but nothing else was that urgent. I'd like to see if we hit some big syncpackage issues. Also the change in lp of having debian versions Published rather than Pending may affect some things
<bdrung> tumbleweed: release early, release often
<sbeattie> barry: quilt pop still fails for me after a clean checkout; wondering if it's anything specific to my quilt settings; do you have QUILT_PATCHES set to debian/patches?
<tumbleweed> sure, but I don't see the urgency
<barry> sbeattie: yep
<bdrung> tumbleweed: but i didn't saw something blocking :)
<barry> sbeattie: how odd
<barry> sbeattie: i also have: QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index
<barry>  
 * sbeattie reads through quilt --trace output to look for what's going wrong.
<tumbleweed> bdrung: oh, I see you've already tagged it :)
<bdrung> tumbleweed: already uploaded (some hours ago)
 * tumbleweed was out
<sbeattie> barry: weeeeird. I had QUILT_PATCH_OPTS="--unified-reject" set in my .quiltrc, unsetting that caused quilt pop -a to work.
<sbeattie> barry: which looks to be a no-longer valid argument to patch. Âµ.
<barry> sbeattie: yeah, i was just going to say i couldn't find that in the manpage ;)
<nigelb> sbeattie: I admire your patience. About this time I'd be headdesking or breaking the keyboard into two ;)
<barry> nigelb: i already did that three times today, but it was because i tried to use git :)
<bdmurray> barry: you are on your 4th keyboard?
 * sbeattie looks at the four smashed keyboards over in the corner and thinks "what nigelb doesn't know won't hurt him."
<nigelb> barry: Ouch. I didn't know git was that bad.
<nigelb> sbeattie: heh :)
<barry> bdmurray: i keep spares around just for the occasional forehead tickling
<bdmurray> barry: what needs to happen to https://code.launchpad.net/~jtaylor/ubuntu/natty/pyfltk/fix-779340/+merge/68194 to get out of the sponsorship queue?
<barry> bdmurray: hmm, good question.  looks like mdeslaur approved the change and was going to do an sru.  do you know if that happened?  (not that i can really help with that 'cause i can't do sru approvals afaict)
<bdmurray> barry: its all fix released it just that the status of the mp is needs review
<barry> bdmurray: oh.  i think only ~ubuntu-branches can change the status.  i'm not on that team either and have no pencil button next to the status.
<bdmurray> barry: so hunt somebody down in that team then?
<barry> bdmurray: i believe so
<sbeattie> barry: re git: if it make you feel any better, I'm also cherrypicking patches from openssl upstreamâ¦ which uses cvs. I'd forgotten how hard it was to pull out individual untagged commits from cvs.
<barry> sbeattie: let's bring back rcs and sccs!
<bdmurray> bdrung: what I mean in bug 807644 is that code names should only be used for the development release after they are released they should be the number
<ubottu> Launchpad bug 807644 in distro-info (Ubuntu) "ubuntu-distro-info displays codenames" [Undecided,Incomplete] https://launchpad.net/bugs/807644
<bdrung> bdmurray: for which use case?
<bdrung> bdmurray: for the end user?
<bdmurray> bdrung: if I use distro-info --all I see a bunch of code names
<bdrung> bdmurray: and you want to see a mix with code names and numbers?
<bdrung> or just numbers?
<bdmurray> bdrung: I think just numbers unless its the devel release
<broder> bdmurray: i think that significantly hampers distro-info's usefulness as a dev tool
<bdrung> bdmurray: that's not useful for scripts using distro-info
<bdmurray> bdrung: okay I guess the package description makes it clear that "distro-info script will give you the codename" but the man-page and --help don't
<bdmurray> bdrung: I mean that seems reasonable but my confusion, if you will, is understandable - to me at least ;-)
<bdrung> bdmurray: do you want a switch to show the version numbers? like http://paste.debian.net/128918/
<bdmurray> bdrung: yes, its beats checking wiki.ubuntu.com or trying to remember
<bdrung> bdmurray: can you update the bug report?
<bdrung> bdmurray: i even could show the full name like 10.04 LTS "Lucid Lynx"
<bdmurray> I think that'd be ideal
<bdrung> and 5.0 "Lenny" for debian
<infinity> bdrung: Maybe a "full name" option or something?
<infinity> bdrung: Or, basically, the same output options you get from lsb_release.
<bdrung> infinity: lsb_release doesn't know the full code name
<infinity> bdrung: I can see wanting several different types of output, but if I want to loop through codenames, the current output is useful, and passing it through cut or something would be annoying.
<infinity> bdrung: Sure it does.
<infinity> bdrung: Err, it knows the archive-level codename.
<infinity> bdrung: That lowercase codename is the useful one. :P
<bdrung> infinity: which different types of output do you want?
<infinity> bdrung: Well, I'm happy with the current output.
<infinity> bdrung: bdmurray seems to want numbers, and I can see why that's also handy.
<infinity> bdrung: And an output that maps A to B would be keen too, I'm sure.
<bdrung> infinity: the full name would be for humans and there i would prefer the longest one
<infinity> bdrung: Yeah, the full names would be neat.
<infinity> bdrung: So, -c (codename), -r (release version), and -f (full name)?
<infinity> bdrung: And default to -c, to not break backward compat with people already using it.
<bdrung> infinity: sounds plausible. can you comment the bug with that?
<bdrung> bdmurray, infinity: would having "Ubuntu" in the beginning useful for the full name mode?
<bdrung> -> Ubuntu 10.04 LTS "Lucid Lynx"
<bdrung> -> Debian 5.0 "Lenny"
<bdmurray> If I used --supported I'd see Ubuntu 4 or 5 times which seems excessive ...
<infinity> Not sure you need the quotes there.  I'm not picky about Debian/Ubuntu being in the string (though, for trademark reasons, it perhaps should be).
<infinity> Since it's not just "10.04", it's "Ubuntu 10.04".
<infinity> LTS, even, in that case.
<infinity> But yeah.
<infinity> For the "-f" case, it should probably be the real full name.
<bdmurray> and what about 10.04.3?
<bdrung> bdmurray: i haven't collected data about that case
<bdmurray> I don't think it shows up in Launchpad anyway
<infinity> The only place point releases show up is base-files, really.
<bdrung> infinity: for the -f case, you want "Ubuntu" in the name?
<infinity> And ISO images, if/when we update them.
<infinity> bdrung: I would consider that more "correct", yeah.
<bdrung> ok.
<bdrung> and following will the correct (with the quotes): Ubuntu 10.04 LTS "Lucid Lynx"
<bdrung> ?
<infinity> I realise it'll look silly when you list --all with "Ubuntu" 12 times, but whatever.
<bdrung> infinity: it's your decision. i have one -1 from bdmurray and i am not decided yet
<bdmurray> I take it back
<infinity> bdrung: I'm for correctness over worrying about "icky" output.  The product is "Debian 5.0" or "Ubuntu 7.04", not "5.0"
<infinity> bdrung: (And people can get just the version list with the proposed "-r")
<bdrung> infinity, bdmurray: compare http://paste.ubuntu.com/685623/ with http://paste.ubuntu.com/685624/
<bdrung> tumbleweed: your opinion about ^?
<bdmurray> I like http://paste.ubuntu.com/685623/ better
<infinity> Definitely with the product name.
<infinity> SO, 623.
<bdrung> ok, then it's decided
<infinity> (Also, thanks for bringing this up in -devel and making me aware of the tool) :P
<infinity> Very handy.
<bdrung> infinity: mailing list or IRC?
<infinity> bdrung: As in, just now.
<infinity> Always happy to discover a useful little tool.
<bdrung> :)
<bdrung> infinity: do you know wrap-and-sort and suspicious-source?
<bdrung> and sponsor-patch?
<infinity> Nope!
<bdrung> then it's time
<infinity> I can only learn one new thing per day.
<ambro718> Hi. How do I get an upstart embedded script to be executed by bash not dash?
<poolie> hi micahg, hallyn, what's the bug number/s?
<broder> ambro718: you can recompile upstart to do that, or you could put the script in a separate file and have the upstart config call that
<broder> ambro718: but you should probably try to rewrite the script without bashisms
<broder> because bash is much slower than dash, especially since it won't already be loaded into memory
<ambro718> broder: I have a /etc/default/something which has an array of command line arguments, like MY_ARGS=( "First Argument", "  Second Argument  " ). How do I rewrite that?
<ambro718> broder: I just do: exec <hardcoded args> "${MY_ARGS[@]}"
<ambro718> not so much in dash which upstart calls.
<broder> jono: we don't really know how much of the "number of times to get approved" was affected by quorum issues, do we?
<Laney> What is implied by the number of times to get approved statistics?
<Laney> I'm most concerned that nobody cares about backports :P
<infinity> ambro718: Why do you need your args in an array rather than just a string?
<ajmitch> Laney: of course we care
 * Laney cares about bed currently
<Laney> nighty night
<broder> Laney: i think it's self-feeding. backports don't get approved so people don't bother with backports. there's not enough interest around backports so people don't approve them
<broder> honestly, i hate it when people do this, but i find myself tempted by something awful like WONTFIXing all open backport requests, starting over and trying to keep a better handle on things
<Laney> nah, just keep on top of new ones and the old requests will take care of themselves by releases going EOL
<ambro718> infinity: ... because individual arguments may contain spaces ...
<ambro718> infinity: and not just theoretically, but actually
<infinity> ARGS='-p arg -f "arg 2" -q "arg 3 whee"'?
<ajmitch> broder: you could do it by 'accident'
<ajmitch> 165 open on lucid-backports, that's quite a few
<broder> though when i think about this more, i remember that hte problem is we need better tools than we have
<Laney> some of our requirements are really annoying, like test /all/ rdeps and test on /all/ intervening releases
<ambro718> infinity: doesn't work probably
<infinity> ambro718: These are command-line args?
<infinity> ambro718: If so, how do you call it on the CLI?
<ajmitch> sometimes I just care about having something work on lucid, since it's LTS
<broder> ajmitch: yes, but the backports requirements are that it work on everything between lucid and oneiric
<ambro718> infinity: my_program "first argument" "second argument"  (just one way to do it)
<Laney> it's too much to ask requesters really
<ajmitch> testing on maverick & natty as well is a bit much for some packages
<Laney> so stuff doesn't get done
 * ajmitch spots python-django in the list
<infinity> ambro718: Right, then this works: ARGS='"first arg" "second arg"'; my_program $ARGS
<broder> Laney: i agree with you, but i also agree with the principle behind the requirement
 * Laney shrugs
<Daviey> doko: Odd!  They are building for me :/
<broder> maybe if we could use stgraber's app preview thing we could make it easier
<ajmitch> broder: so what should be done with all those open requests?
<infinity> ambro718: Or not.  Hrm.
<infinity> ambro718: I know there's a way to make this work. :P
<broder> ajmitch: figure out the patterns, then teach a tool to do the same
<ambro718> infinity: is not... which is why all shell scripts should be destroyed....
<broder> ajmitch: honestly, 85% of the backports testing process could be overseen by a bot instead of a human
<broder> and that would be the *real* answer
<ajmitch> how much testing are requestors required to do for a package?
<Daviey> doko: Ah, did you give back to natty?
<ajmitch> checking that the package installs is easy enough, checking that some functionality still works is a bit harder to automate
<doko> Daviey, if you think they do work, please upload these as *buildN* versions to oneiric
<doko> Daviey, no oneiric
<cjwatson> bdmurray: I've marked that pyfltk branch as merged now
<doko> Daviey, your haskell geive-back did succeed, thanks!
<broder> ajmitch: our requirements for "runs" are pretty minimal. you could probably do something like..
<broder> ajmitch: run every binary in an X environment. sleep for 5 seconds, then capture console output and a screenshot. show the output/screenshots to a backporter and let them decide whether that counts as "running"
<broder> then over time you build up blacklists ("Segmentation fault" does not count as "running", etc...)
<Daviey> doko: excuse the utf-8 fail.. but http://pb.daviey.com/Rn8O/
<doko> Daviey, what I did learn is to do the rebuild test under the umbrella of a team, so that more people than me can do give-backs
<ajmitch> broder: I imagine that wouldn't be particularly hard to automate with testing in a VM
<Daviey> doko: sounds wise
<doko> Daviey, acknowleged, and you're under arrest for the next one ;-P
<bdmurray> cjwatson: thanks
<ajmitch> broder: I'll try & do a quick & dirty PoC in virtualbox this weekend if you want :)
<broder> ajmitch: i never say no when other people offer to write code for me :)
<ajmitch> though on my hardware, 5 seconds would be very optimistic
<broder> ajmitch: the number can be whatever you want. especially if it's autonomous, performance really just isn't a concern
<ajmitch> broder: I'll see what I can do, I've already got VM images of most releases which I can snapshot & automate
<broder> ajmitch: awesome, i'm looking forward to it
<ajmitch> broder: yeah, it's not too dissimilar to some of the testing stuff I've been doing at work lately, so I already have a bit of it working :)
<stgraber> broder: I actually have some code that you may find interesting for backports
<stgraber> broder: it's code that I've been working on as a proof of concept for ARB and commercial apps
<broder> stgraber: go on... :)
<stgraber> broder: basically a debhelper script that moves all your package to /opt/extras.ubuntu.com/<package name> except your .desktop that are simply modified to use arb-wrapper
<stgraber> broder: arb-wrapper uses fuse to create an overlay of your filesystem and the content of /opt/extras.ubuntu.com/<package name>
<stgraber> broder: and then uses fakechroot to run the software
<ajmitch> stgraber: that reminds me, I'll mail that list of bugs to the arb list
<stgraber> broder: so the application will stil lthink it's running on a regular system, but it won't be affecting other software running on your machine
<broder> stgraber: hmm..could be useful, although i think the biggest barrier to backports testing right now is our requirements about testing across multiple releases
<broder> but we might be able to solve that with chroots
<stgraber> broder: yeah, for that specific case I don't have code yet but saw some code around a while ago to basically get a list of everything a given binary is going to use on the system
<stgraber> broder: you could then bundle all of that and run it in a chroot using file system overlay, not having to care about what's on the system
<stgraber> though you're going to waste a lot of space doing it
<broder> that's not really as much of a concern for us. everything in backports started in the main archive, so there's a pre-assumption of trustworthiness
<stgraber> so probably only worth doing in some very specific corner cases (very old binary app that needs to run on a recent machine comes to mind)
<stgraber> yeah, I must admit not using backports (as I'm almost never running a stable release) but I'd think the one thing that'd be interesting is co-instability of multiple versions of the backported package and the original package
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<stgraber> and that's something I can quite easily do, though it'd need quite a bit of work to be user friendly ;)
<ajmitch> stgraber: what do you mean by that? having both installed at once?
<stgraber> yes
<stgraber> anything coming from backport would essentially be isolated from the system so it can't conflict with it (no need for rdepends check then). Some kind of chroot (overlay of your system + the content of the backported packages) would be dynamically created when you ask to start something from backport
<ajmitch> stgraber: it sounds like a lot of work just to get a newer version of a package
<ajmitch> especially when you want the package in interact with stuff in $HOME
<stgraber> ajmitch: how so? my current code gives the program the exact same FS access it'd have otherwise on the FS
<stgraber> I guess I confused people a bit by saying "overlay" earlier as I really meant "overlay" and not "copy-on-write overlay" as aufs does
<ajmitch> broder: http://paste.ubuntu.com/685665/ is a 5-min plan of what I might do, suggestions welcome :)
<stgraber> so any read being done will first it /opt/extras.ubuntu.com/<path requested>, then if not found /<path requested>. Any write would happen directly in / as usual
<ajmitch> ok
<stgraber> it doesn't restrict the app in any way, other than showing some extra files that arent usually on the fs (or have a different content)
 * ajmitch was thinking that you meant you'd keep writes isolated as well
<stgraber> no, I do that for stuff I don't trust (in Arkose). Backports are perfectly trustworthy so there's no need to do it
<ajmitch> it wouldn't solve the problem of app 2.0 scribbling over 1.x config & data files, but it'd be a good initial step
<broder> ajmitch: backportpackage gets more love than prevu these days. i like looking at .desktop files; if there are none i would fall back on trying everything in /usr/bin or /usr/sbin in turn
<broder> looks awesome other than that
<ajmitch> broder: other bits like the ipv6 address are just PoC implementation details due to my screwy network :)
#ubuntu-devel 2011-09-09
<stgraber> ajmitch: yeah, config is always tricky to handle and I'm not sure we'll find a safe way to handle that any time soon
<Daviey> doko: Well it builds in both pbuilder and sbuild local.. not quite got the confidence to throw in a no-change rebuild into the archive yet.. :).. Just pushed to a virgin PPA, will see what that does.
 * Daviey ponders how nice it would be if the package build tools had the same behavior as the archive.
<lifeless> you can do that - heck, run a local PPA for testing :)
<stgraber> Daviey: can't you just grab a LP buildd chroot? that should give pretty much the same behaviour
<Daviey> lifeless: fancy writing an ensemble formula for that? :)
<Daviey> stgraber: where from?
<lifeless> Daviey: once ensemble has lxc support :)
<Daviey> lifeless: bah
<stgraber> Daviey: give me 5 minutes, I'll try to find the URL again ;) I know it's somewhere in the LP api
<lifeless> Daviey: the word 'local' being relevant there ;)
<stgraber> Daviey: https://api.launchpad.net/1.0/ubuntu/oneiric/amd64
<Daviey> stgraber: nice find!
<stgraber> Daviey: I never actually used them but I saw that once in the API :)
<stgraber> ajmitch: Quick demo of arb-wrapper (available in https://launchpad.net/~stgraber/+archive/arb-testing): http://paste.ubuntu.com/685673/
<ajmitch> stgraber: thanks
<micahg> poolie: did hallyn get back to you?
<poolie> hi, not that i noticed
<poolie> i would appreciate if you file or point out a bug and i'll see if we can do something about it
<micahg> poolie: bug 820671
<ubottu> Launchpad bug 820671 in Ubuntu Distributed Development "no libvirt in maverick-updates or natty-updates udd trees" [Undecided,New] https://launchpad.net/bugs/820671
<tjaalton> bug 824913, any archive admin know how that's possible?
<ubottu> Launchpad bug 824913 in Ubuntu "LUCID linux-headers-generic-lts-backport-maverick 2.6.35.30.38 depends on missing linux-headers-2.6.35-30" [Undecided,Confirmed] https://launchpad.net/bugs/824913
<tjaalton> the archive has the deb, but the index files not
<poolie> thanks micahg
<pitti> Good morning
<poolie> hi pitti
<didrocks> good morning
<dholbach> good morning
<dholbach> can somebody please reject https://code.launchpad.net/~sinzui/ubuntu/oneiric/gedit-developer-plugins/0.5.4-release/+merge/74628?
<pitti> dholbach: done
<pitti> still weird why core-devs can't do this
<dholbach> thanks pitti
<dholbach> and please reject https://code.launchpad.net/~paulbrianstewart/ubuntu/oneiric/alarm-clock-applet/830806-Punctuation-Correction/+merge/72373 too
<pitti> dholbach: done
<dholbach> thanks
<kelemengabor> njpatel: hi, do you have a few minutes to review my proposed branch for bug #437963 ?
<ubottu> Launchpad bug 437963 in Ubuntu Translations "Untranslatable strings in Plugin manager" [Medium,Triaged] https://launchpad.net/bugs/437963
<kelemengabor> or any evolution-indicator devs? :)
<njpatel> kelemengabor, approved, just merging
<njpatel> kelemengabor, we'll need a new release, will ping didrocks with the tarball
<kelemengabor> thanks!
<njpatel> kelemengabor, didrocks https://launchpad.net/evolution-indicator/0.2.0/0.2.20
<seb128> didrocks, njpatel: what is the new version for? do you want me to package it?
<didrocks> njpatel: thanks, maybe cyphermox_ will make the update as he's in charge of the evo stack nowdays!
<didrocks> seb128: oh yeah, please! that's more than welcome :)
<seb128> didrocks, doing
<didrocks> thanks :)
<njpatel> seb128, it's for this bug: #437963
<ubottu> Launchpad bug 437963 in Ubuntu Translations "Untranslatable strings in Plugin manager" [Medium,Triaged] https://launchpad.net/bugs/437963
<seb128> njpatel, thanks
<Snicksie> Hi all... I'd like to get started in ubuntu development, i've read the howto (UbuntuDevelopment @ wiki) and i'm looking what I can do, but I find it quite difficult to get started... Is there someone who could help me with getting started? I'm also quite unsure about what teams I need to join and what steps I need to make before I can help developing... I'd like to help bugfixing, but I've not enough knowledge to help with that :(
<tjaalton> any archive admin available to figure out why bug 824913 exists? :)
<dholbach> Snicksie, I would suggest you check out http://developer.ubuntu.com/packaging/
<tjaalton> uh, no ubottu
<tjaalton> https://bugs.launchpad.net/ubuntu/+bug/824913
<Snicksie> will read that, dholbach :)
<Snicksie> dholbach, i'm afraid i dont really have enough experience with programming languages like c/cpp/python, which seems to be the most used languages in ubuntu... do you have any helpful information how to learn that? :$ I only 'know' the basics (as in really basic) from cpp and I have some  experience with java / php/ js / etc...
<dholbach> Snicksie, you could just start trying to fix very small issues
<Snicksie> i've tried to search for 'simple' bitesize bugs, but the simple ones seem already taken :(
<lenios__> i'm wondering where to ask to get my package into main repositories
<lenios__> available at https://launchpad.net/~richard-sellam/+archive/ppa , although will need some work to merge with debian testing
<Chipzz> lenios__: a) you should mention *which* package and b) packages don't go into main easily, a package being in mai means canonical *wants* to support it, which is hardly the case for just any package out there. I suspect you want your package in universe/multiverse instead
<lenios__> oops, i meant universe
<lenios__> package is ocsinventory-agent
<Chipzz> better place to ask is #ubuntu-motu
<doko> ohh, nice, libunity5 :-/
<pitti> doko: rebuilds were uploaded
 * pitti is waiting for powerpc to catch up to drop libcamel and libnotify1
<pitti> I'll have a look at the libevent-1.4-2 rdepends
<jml> :(
<doko> barry, could you have a look at bug 621242 for the dh_python2 changes?
<ubottu> Launchpad bug 621242 in mocker (Ubuntu Oneiric) "[MIR] mocker" [High,Incomplete] https://launchpad.net/bugs/621242
<barry> doko: mp submitted for bug 621242 to switch mocker to dh_python2.  care to review?  i'm happy to upload it if it looks okay to you
<ubottu> Launchpad bug 621242 in mocker (Ubuntu Oneiric) "[MIR] mocker" [High,New] https://launchpad.net/bugs/621242
<doko> barry, looks ok
<barry> doko: thanks, pushing
<cr3> cjwatson: hi there, might you happen to remember why the chain.c32 is needed to netboot some systems from the first drive since maverick?
<cjwatson> cr3: https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/625383 has all I know
<ubottu> Launchpad bug 625383 in Release Notes for Ubuntu "grub hangs at early booting after handoff from PXE" [Undecided,Fix released]
<cr3> cjwatson: ah, so it's been fix released after maverick, so I shouldn't need the workaround anymore for natty and oneiric!
<cjwatson> err
<cjwatson> no, the release notes task is fix-released, everything else is wont-fix - just use chain.c32
<cr3> cjwatson: thanks for pointing that out, cheers!
<cjwatson> investigating what went wrong with localboot is a rathole and probably impossible without access to the PXE BIOS code
<cjwatson> or infeasible anyway
<cjwatson> chain.c32 means it doesn't matter if this particular corner of the PXE BIOS is buggy
<cr3> cjwatson: might it be worthwhile to make that assumption the default behavior, ie assuming bugginess which is probably quite common when it comes to BIOS code :)
<cjwatson> cr3: there's no default, you just write LOCALBOOT or COM32 chain.c32 (or whatever the exact rune is) depending on what you want to happen; I don't think it would be appropriate to turn one into a magic shim for the other, no
<cr3> cjwatson: or here's another idea: how about we make the chain.c32 file from the syslinux package directly available on the alternate and server images to enable sysadmins when netbooting?
<cr3> hggdh`: ^^^ do you think that would help folks?
<hggdh> yes, it would. It makes no sense to find oneself with an ISO that will not PXE-boot
<hggdh> like what happened with me...
<cjwatson> cr3: sure, it's tiny enough.  done
<cr3> cjwatson: many thanks, you've just made a few server folks quite happy :)
<hggdh> cjwatson: thank you, from the bottom of my heart, and all that :-)
<gotwig> cjwatson: hey
<gotwig> cjwatson: we talked yesterday about seeds, right?
<cjwatson> hi
<cjwatson> yep
<gotwig> cjwatson: may I ask you something about that ?
<cjwatson> sure
<gotwig> cjwatson: can I build my own ubuntu image, with custom seeds from me? If yes, how?
<cjwatson> probably simplest to direct you to https://help.ubuntu.com/community/LiveCDCustomization
<cjwatson> well, maybe, that's not a build from scratch
<cjwatson> for >= oneiric you can use the live-build package
<gotwig> cjwatson: ?
<cjwatson> and as far as seeds go, you'd update ubuntu-meta to point to your seeds and put that in a local repository
<gotwig> cjwatson: there is no manual, for using seeds to build an image
<cjwatson> no, there is not
<cjwatson> afaik
<cjwatson> honestly, though, I don't do this kind of thing because I have all the central infrastructure to hand.  I'm sure there are others who can help you much more usefully than I can
<gotwig> :/
<gotwig> cjwatson: which infrastructure?
<cjwatson> the sort of people who build derivative distributions of Ubuntu
<cjwatson> live-build, livecd-rootfs, the Ubuntu cdimage code
<gotwig> thx
<smoser> SpamapS, have you tried to re-create the users issues in bug 839595 ?
<ubottu> Launchpad bug 839595 in Release Notes for Ubuntu "failsafe.conf's 30 second time out is too low" [Undecided,New] https://launchpad.net/bugs/839595
<smoser> you can probably avoid lots of back and forth if you just boot a vm without eth0 (or you could add an 'auto eth1' entry)
<SpamapS> smoser: no, I couldn't recreate it. X starts fine for me.
<SpamapS> smoser: trying to figure out what is blocking him
<ScottK> SpamapS: I'd appreciate it if you could move clamav to natty-updates now.  It's verification done.
<SpamapS> ScottK: I'll make a sweep in a bit, Thanks for the heads up.
<ScottK> Thanks.
<sbeattie> barry: how do you get around bzr merge-package refusing to work due to uncommitted local changes from doing quilt pop -a first? I don't particularly want to add a spurious commit just for popping everything off before a merge.
<om26er> could anyone sponsor this unity fix https://code.launchpad.net/~om26er/ubuntu/oneiric/unity/unity-fix-840285/+merge/74854 the issue is quite important I believe
<highvoltage> heh, keybuk caused quite a stir
<ScottK> Oh?
<tumbleweed> highvoltage: where did you see that? I've had IRL discussion about it today, but seen nothing about it on the lists / planet since
<ScottK> About what?
 * ScottK is all confused
<tumbleweed> 20:56 < highvoltage> heh, keybuk caused quite a stir
<ScottK> right, but what was the stir?
<tumbleweed> proposed monthly releases
<broder> ScottK: http://netsplit.com/2011/09/08/new-ubuntu-release-process/
<stgraber> it was just on Planet, slashdot and LWN :)
<ScottK> Thanks.
<highvoltage> yeah, on slashdot, LWN, linux.com, etc
<nigelb> It is an interesting proposal :)
<tumbleweed> lots of noise outside Ubuntu, none inside :)
<highvoltage> and I was overhearing people in the office talking about it too
<nigelb> heh, same here.
<nigelb> servers bit especially
<nigelb> what would happen, etc
<ScottK> Just add one more layer: "Really effing stable."
<ScottK> I think he's totally right on the problem.  Not sure I agree with his solution.
<highvoltage> ScottK: yep, all the reasonable people I've spoken to about it said pretty much the same thing. things could be done a lot better, but there's not yet a nice solution that really fixes the current problems nicely without introducing other nasty ones
<ScottK> I think if things like Unity had their own feature planning/release schedule that were shifted earlier than Ubuntu's it could be sovled.
<ScottK> If, to pick an example, Unity were developed on a schedule similar to Gnome/KDEs then they could start on feature work for release +1 as soon as Ubuntu's feature freeze hits.
<ScottK> They need to decouple their planning from the Ubuntu planning schedule.
<ScottK> Basically "Development" and "Distribution Integration" are two different things.
<jbicha> the proposal is similar to the Chrome/Firefox schedule
<ScottK> Trying to do development on the distro integration schedule doesn't make for a happy solution.
<ScottK> I think he underestimates the complexity of what he's proposing.
<ScottK> I don't think it scales from one package to 20,000.
<micahg> om26er: is unity not using a patch system?
<om26er> micahg, its using quilt, everyone was just patching the source directly but I could try with quilt if required
<micahg> om26er: well, I can only speak in generalities, but usually in the distro, if there's a patch system, we use it, but you should probably ask the -desktop people
<SpamapS> slangasek: what do you think about this discussion in bug 839595 .. It would appear that at least a few users have an auto interface setup that is causing their boot to be much slower.
<ubottu> Launchpad bug 839595 in Release Notes for Ubuntu "failsafe.conf's 30 second time out is too low" [Undecided,New] https://launchpad.net/bugs/839595
<superm1> slangasek, did i read somewhere that the 700mb oversized mark was wrong on c.u.c?  that it's actually like a meg or two more that are allowed?  mythbuntu amd64 is oversized to like 701mb, so i was hoping wouldn't need to fix that.
<afeder_> I am trying to compile network-manager-applet, but it depends on 'NetworkManager >= 0.9.1'. Where can I get this package when the most recent version in main repositories is  0.9.0?
<jbicha> afeder_: why don't you compile NetworkManager while you're at it then?
<afeder_> i wouldnt know how :/
<afeder_> oh i guess i would pull it from LP too...
 * afeder_ is slow but gets there eventually
<afeder_> thanks
<cjwatson> sbeattie: it seems odd that 'bzr merge-package' doesn't have a --force option.  I use 'bzr merge --force' for that kind of thing and it works fine, although I'm probably missing some subtle bit of magic from merge-package.
<SpamapS> Does anyone know if NetworkManager for some reason edits /etc/network/interfaces ? bug 839595 has some discussion going on that suggests it might, but I don't think thats how it works.
<ubottu> Launchpad bug 839595 in Release Notes for Ubuntu "failsafe.conf's 30 second time out is too low" [Undecided,New] https://launchpad.net/bugs/839595
<cyphermox_> SpamapS: I was just running out for the weekend, but NM doesn't edit /e/n/i
<cyphermox_> it reads it though
<cyphermox_> (unless you use Debian's NM, which touches /e/n/i as part of the maintainer scripts, we don't have those)
<SpamapS> cyphermox_: thanks... still running my tests, but good to know that it *shouldn't*
<cyphermox_> give me a second, I'll make sure I can stay online while on the road (I'm not driving ;)
<cyphermox_> ok, checking that bug report now
<SpamapS> cyphermox_: thanks.. I really think its mostly just left over auto's in /etc/network/interfaces, and not something people w/ normal configurations should see
<cyphermox_> right
<cyphermox_> if /e/n/i still contains an entry with 'auto <iface>', nm will ignore it
<SpamapS> Right, whereas the new boot procedure won't.. it will try and wait for it.
<SpamapS> Which is what we *want*.. but may not be what people *expect*
<cyphermox_> sorry,, not sure I follow there
<SpamapS> We made a change to the boot..
<SpamapS> so that runlevel 2 waits for all the auto interfaces to be up
<cyphermox_> and it looks for entries with auto?
<SpamapS> since most desktops/laptops should have no auto's
<cyphermox_> ok
<cyphermox_> right
<cyphermox_> afaik it shouldn't contain it on new installs, and it's been the case for long enough that the vast majority of upgrades wouldn't have them either
<SpamapS> but 2 users , including our own RAOF, have complained because this suddenly causes their boot to take 2 extra minutes
<cyphermox_> I can think of some vm setups "require" the use of /e/n/i, for instance for bridginh
<cyphermox_> gah, I really can't type today
<SpamapS> I'm wondering if its worth making do-release-upgrade warn them or something.
<SpamapS> bridging problems actually are a big part of why we're doing this
<cyphermox_> ok
<SpamapS> If we don't wait, auto-vm's can't use the bridge for instance.
<cyphermox_> yup
<SpamapS> Its the typical gripe when you remove a race condition.. things go slower. ;)
<cyphermox_> so what's the thing about NM changing /e/n/i then?
<cyphermox_> hehe
<SpamapS> cyphermox_: I think its just FUD
<cyphermox_> oh ok
<cyphermox_> I know it reads the file, i guess it *could* be the case that it touches it, but I seriously doubt it. I haven't seen this kind of changes in that part of the code pass by, and I'm pretty sure someone would have noticed and complained
<cyphermox_> given we've already complained about touching /etc/hosts, and I think /etc/resolv.conf may still be an issue, I don't think changing /e/n/i would fly, dcbw already knows about it
<bdmurray> pitti: how will the retracer handle the case where a bug with a duplicate signature is marked as a duplicate of another without a signature?
<bdmurray> pitti: bug 845093 is an example of what I'm talking about
<ubottu> Launchpad bug 841753 in bcmwl (Ubuntu) "duplicate for #845093 package bcmwl-kernel-source 5.100.82.38 bdcom-0ubuntu3 failed to install/upgrade: bcmwl kernel module failed to build (Makefile: No such file or directory)" [Undecided,Confirmed] https://launchpad.net/bugs/841753
<cyphermox_> SpamapS: could some of this delay come from the isc-dhcp delay changes, if those landed?
<SpamapS> cyphermox: yes and no..
<SpamapS> cyphermox: yes because the delay is now "to infinity and beyond", but no because failsafe.conf boots the system after 120 seconds.. so its really failsafe's problem now. :)
<cyphermox> ok
<cyphermox> failsafe.conf or whatever brings up the interfaces to specify a dhcp timeout?
<cyphermox> well, taking off now, ttyl
<SpamapS> cyphermox: thanks for the insight. :)
#ubuntu-devel 2011-09-10
<Sarvatt> SpamapS: d-i/source/netcfg/write_interface.c in ubiquity has some /etc/network/interfaces handling that might be what did it on my machines
<Sarvatt> its too late here but i'll install a new machine tomorrow and see if /etc/network/interfaces has auto eth0 in it adding 2 minute boot time out of the box after a fresh install. i installed one of those boxes literally yesterday and did nothing more than install, boot, dist-upgrade and reboot to hit the extra 2 minute boot time and thats just crazy.
 * ScottK pokes at SpamapS again.
<slangasek> superm1: https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-great-cd-debate; mythbuntu is certainly free to pick a higher limit for their own CDs even if we aren't yet sure it's safe to raise the limit for Ubuntu
<slangasek> superm1: just send us a cdimage merge request :)
<shnatsel> infinity: you are marked as assignee for https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-image-build-documentation , is there any development anticipated and is that blueprint even official?
<shnatsel> infinity: Ubuntu Studio, Ubuntu GNOME Remix and elementary project kinda need that
<shnatsel> although for Ubuntu Studio it's not critical, they can use Canonical's build farms after all. Being able to perform local testing would be great, though.
<bludude> infinity: Ubuntu GNOME Remix actually really needs that. We've had to go on an internet treasure hunt to find image build info.
<bludude> infinity: here's some of my work so far on digging up docs: https://blueprints.launchpad.net/ugr-live/+spec/ugr-live-build
<shnatsel> but, according to https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-live-build, Ubuntu's build systems are quite different from upstream, which are documented
<shnatsel> or at least require very different configs
<bdrung> tumbleweed: which tools should be moved out of u-d-t?
<bdrung> pbuilder-dist, check-symbols, pull-*-source (?), merge-changelog (?), reverse-build-depends. more?
<Laney> do we need r-b-d when there's build-rdeps?
<bdrung> Laney: can you check if reverse-build-depends has no benefit over build-rdeps?
<Laney> r-b-d is a copy of build-rdeps with the debianisms replace with ubuntuisms
<bdrung> Laney: can b-r made universal (work for debian and ubuntu)?
<Laney> anything is possible
<Laney>  build-rdeps |  171 +++++++++++++++++++++++++++++++++++++++++++-----------------
<Laney>  1 file changed, 125 insertions(+), 46 deletions(-)
<tumbleweed> hrm, I always just grep-dctrl on my mirror. I should use these tools so that I know what they do :)
<bdrung> tumbleweed: "Upload the package to Ubuntu with dput as normal:" ?
<tumbleweed> :)
<bdrung> tumbleweed: i am currently refractoring sponsor-patch
<tumbleweed> bdrung: for this upload?
<bdrung> tumbleweed: i think yes
<bdrung> tumbleweed: but it could wait if you want to upload now
<bdrung> it's not urgent
<bdrung> tumbleweed: do you want to do an upload?
<tumbleweed> yeah, let's do it now, I'll do it
<tumbleweed> otherwise I'll start adding mirror support to pbuilder-dist, and I don't have time to finish that :)
<bdrung> tumbleweed: wait. i forgot to push one change
<bdrung> tumbleweed: pushed. you can release it now
<bdrung> tumbleweed: did you upload the SRU packages?
<tumbleweed> bdrung: natty is blocked by the last SRU
<bdrung> tumbleweed: can you open a new bug for the pending publishing states?
<tumbleweed> oh damn I meant to investigate what the effect of not stating a publication state was
<tumbleweed> we don't, in some places
<tumbleweed> they appear to all be correct
<siretart> infinity: happen to be awake and around?
<DelphiWorld> Hello Developers
<DelphiWorld> please could someone confirm that the ubuntu installer can by interactive through the serial port ?
<DelphiWorld> naba: hey Elisha:D
<sladen> DelphiWorld: this is how you install on Sparc and such
<DelphiWorld> sladen: W00T !
<DelphiWorld> sladen: i can set up ubuntu server through console ?
<sladen> DelphiWorld: You need the alternate CD
<sladen> DelphiWorld: and I think  console=ttyS0,9600
<DelphiWorld> sladen: HMMM
<DelphiWorld> sladen: where can i get it from ?
<DelphiWorld> sladen: Thank you a lot.
<DelphiWorld> sladen: you solved my blindness issue
<ScottSanbar> May I ask why you want to use a console?
<DelphiWorld> ScottK: see my message abov :)
<DelphiWorld> ScottK: i am blind
<DelphiWorld> ScottK: and can't see the screen at all
<ScottSanbar> Oh, I see - I am going blind.  I have Kerataconus.
<sladen> DelphiWorld: in theory Ubuntu is installable using a braille terminal.
<ScottSanbar> I see.  Thanks.
<sladen> DelphiWorld: in addition, the installer has a speech synthesiser
<sladen> DelphiWorld: TheMuso is also blind, and will know the latest
<siretart> ScottSanbar: https://help.ubuntu.com/11.04/installation-guide/i386/install-methods.html might help you
<DelphiWorld> sladen: please talk in #ubuntu
<ScottSanbar> That is good to know, because I may need such things in the future
<ScottSanbar> OK, will do.
<ScottSanbar> Sorry.
<DelphiWorld> TheMuso: hey !
<ScottSanbar> Hi - if we wish to talk further about this topic, we must move it to #ubuntu apparently
<DelphiWorld> ScottK: issue in #ubuntu is the traffic
<ScottSanbar> Alternatives?
<DelphiWorld> ScottK: lot of irc messages i mean
<DelphiWorld> sladen: where she's from, daniela ?
<ScottSanbar> Yes, I understaood what you meant, but thank for the clarification.  I was wondering if there are any good alternatives to #ubuntu where we could move our discussion about the blindness issue, if we still wanted to talk about it.
<DelphiWorld> ScottK: ;)
<sladen> DelphiWorld: #ubuntu-accessibility
<ScottSanbar> Cool, thanks, I'll go there now and see if anyone follow.
<DelphiWorld> ScottK: :)
<ricotz> siretart, hello, did you have a look at the mplayer bluray fix?
 * mneptok growls at 11.10
<mneptok> get a new kernel, lvm and evms give warnings of being "unavailable" and boot time has gone to ~10 minutes
<superm1> slangasek, ah.  okay.  thanks
<xperia> hello to all. quick question. i just builded and installed the clucene package from the ubuntu distro sources. but i total dont know how to start it at the moment. does anybody know how i can start clucene on my ubuntu mashine. if i do clucene nothing happen even all files are installed. readed i need to execute the command "indexer" but then i get the prompt to install other software that...
<xperia> ...include the programm indexer.
<bdrung> tumbleweed: sponsor-patch supports sync request. feel free to test it.
<tumbleweed> nice
<bdrung> tumbleweed: if syncpackage would have a module, it could use that module directly
<tumbleweed> yes, that's something we'll have to do
<infinity> siretart: I may have been at an airport when you pinged.  Or on an airplane.
#ubuntu-devel 2011-09-11
<slangasek> SpamapS: bug #839595> well, I don't see anything for it except for release noting
<ubottu> Launchpad bug 839595 in Release Notes for Ubuntu "failsafe.conf's 30 second time out is too low" [Undecided,New] https://launchpad.net/bugs/839595
<micahg> cjwatson: I actually wanted to ask someone about ichthux-* packages, the seed branches no longer exist and I can't seem to get ahold of anyone who cares about the packages, also the meta package has some rdepends on obsolete stuff, I was wondering what the policy for dropping that type of stuff is
<lfaraone> Does UDS sponsorship extend to Saturday morning, Nov 5? Or do we have to check out on Friday?
<nigelb> lfaraone: Saturday Morning usually.
<nigelb> Friday night is *the party*
<ScottK> micahg: txwikinger is who you should talk to about it.
<ScottK> aka Ralph Janke.
<micahg> ScottK: I subscribed him to a bug a while back, but IIRC, he said he wasn't involved anymore
<ScottK> If he said that, then they should all just be removed since he was the last one that cared about ichthux.
<micahg> ScottK: ah, no, he said he'd update the seeds which no longer exist, will try to talk to him
<ScottK> OK.
<cjwatson> micahg: meh, I found it easier to just fix it because removing something belonging to a specific derivative smells of politics and I hate politics
<micahg> cjwatson: ok, I just e-mailed the last known contact about it, we'll see what happens
<cjwatson> fixing it took about a tenth of the time that having to have a debate with people would've taken, too :)
<cjwatson> so yeah
<micahg> cjwatson: right, but the meta package is still missing branches as well
<cjwatson> yeah, well, I didn't really want to think about everything at once; I was blitzing Ubuntu-specific packages with build failures
<Nitesh> A bug in software center or something else in oneiric is really troubling me. After I  launch software center, every screenshot or screencast I make gets corrupted. Here is a video : http://tinypic.com/player.php?v=2nasitt&s=7
<philps> is this the right place to ask about kernel modules?
<broder> how does apport avoid racing with the crashed process's parent? i'm getting an X crash, but by the time apport tries digging around in /proc, the process is already gone
<broder> (this is on natty, so X is being supervised by gdm)
<Rovanion> Will it be possible to select input method or keyboard layout in the version of LightDM that's released in 11.10?
<RAOF> Rovanion: I don't believe that feature is planned for 11.10; as far as I know, various people have gone "will it do this" without really making a case for *why* they want to do that.
<Rovanion> RAOF: It is important that each user can type their password with the same keyboard layout which they use when logged in, otherwise they will not be able to log in.
<RAOF> Rovanion: Is the keyboard layout not a physical constraint, though?
<Rovanion> RAOF: I'm not sure I understand
<RAOF> Rovanion: The physical keyboard in front of the user will have a certain layout; is that layout not necessarily the correct one for LightDM?
<broder> hey RAOF - is there a trick i'm missing for getting apport to capture a backtrace from X?
<Rovanion> RAOF: Not neccicerily no. In france for example it's a mix of AZERTY and QWERTY. In other countries it's common to use both Latin and cyrillic alphabets
<lifeless> Rovanion: you seem to be talking about something different
<Rovanion> RAOF: If the computer is installed to use Latin caracters at login, a user with a password in cyrillic is absolutely unable to log in. In a school this situation is possible to occur
<lifeless> Rovanion: RAOF is saying 'the keyboard, whatever it is, is fixed', you are saying 'different people in one country may have different keyboards'
<Rovanion> lifeless: No, different persons on the same computer with the same keyboard use different keyboard layouts. The layouts are in software, if you recall you could change the language and layout in GDM 2.32
<lifeless> so the use case is 'It is possible that no single keyboard layout will permit all user son a shared machine to enter their passwords'
<lifeless> s/user son/users on/
<lifeless> s/use case/problem statement/
<Rovanion> lifeless: Yes, the case with Latin/Cyrillic is the absolutely worst case where it becomes absolutely impossible to log in. A less worse problem but maybe more common in your country is Dvorak/QWERTY where the user would have to find a picture of the layout or ask someone in order to log in.
<Rovanion> In asking someone he would then more or less reveal his password. It's also _very_ inconvenient.
<desrt> was anyone here hit by https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/832513 and able to provide more feedback?
<ubottu> Launchpad bug 832513 in gnome-settings-daemon (Ubuntu Oneiric) "gnome-settings-daemon assert failure: gnome-settings-daemon: ../../src/xcb_io.c:575: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed." [High,Incomplete]
<RAOF> broder: Sorry about that; unreliable network.  The short answer is "apport _should_ catch X crashes the same way that it does for everything else, but doesn't".  The long answer is similar, but includes a bunch of cases where apport does quite happily catch and retrace X crashes.
<broder> haha, ok. that sounds roughly consistent with my findings :)
<broder> after asking i realized that since this particular crash is reproducible, i should just run X under gdb
<RAOF> I'm not entirely sure how to debug that, too.
<Rovanion> RAOF: You disconnected when I further explained the use-case, should I resend it?
<RAOF> Rovanion: Yes, please.
<Rovanion> RAOF The situation is different persons on the same computer/loginsystem with the same keyboard. The layouts are in software, if you recall you could change the language and layout in GDM 2.32.
<RAOF> Rovanion: Yes, I know it was possible.
<Rovanion> RAOF: A case  with Latin/Cyrillic layout is the absolutely worst case where it becomes absolutely impossible to log in. A less worse problem but maybe more common in your country is Dvorak/QWERTY where the user would have to find a picture of the layout or ask someone in order to log in.
<Rovanion> RAOF: The reason I mention it is because lifeless asked for clearification, so I assumed that also you had misunderstood
<Rovanion> Or rather, that I had expressed myself unclearly
<RAOF> It's common for people to have both a Latin and Cyrillic layout set in software, and switch between them?  That would be necessary to fix.
<RAOF> Probably by means of taking the existing keyboard indicator from the session and running it in unity-greeter, I guess.
<broder> RAOF: shared desktop where some people use dvorak and some use querty
<Rovanion> RAOF: The password could be in different layouts for different users
<broder> i know that would be an issue at my alma mater
<RAOF> broder: Really?  They should consider it extra password obfuscation, then :)
<broder> RAOF: sure. we have shared workstations, and i know someone who used dvorak. we all laughed at him :-P
<broder> (uses - he still does)
 * RAOF notes that he uses dvorak 
 * Rovanion also uses dvorak
<Rovanion> Well not american dvorak but
<Rovanion> RAOF: The easy and always working route it to make LightDM have a setting like GDM 2.32 to switch layout in the DM for that user permanently. One could also pull the layout that's used in the active session, the problem being which one to choose if the user has more than one active.
<RAOF> Rovanion: Thanks for that use-case.  There have been various discussions on ubuntu-desktop@, but as far as I can tell they've been "why are you removing this" rather than actually presenting what will fail to work without having it.
<RAOF> Rovanion: Right.  There's already a couple of indicators in unity-greeter, though, and giving it the same UI as the session would be nice for consistency.
<ion> Is the nasty dot grid going to be removed soon from lightdmâs background image?
<RAOF> Nasty?  I quite like it.  I thought it was swanky design.
<ion> Looks like a development helper for element placement that someone forgot to remove from the local tree before uploading. :-)
<ion> (I sincerely thought it was that at first, but then it just stayed there.)
<Rovanion> RAOF: Yes, all my desktop installations that are shared with other people need this to work satisfactory. Haha oh so many problems I've had with Windows XP. The DM would inherit the layout used in the last session. In order to switch between the two layouts commonly used on the computer there were two dummy-accounts without password that you logged into before you were able to type in your
<Rovanion> password
<RAOF> Hah!
<Rovanion> ion: You are not alone. The seccond comment on this page thinks the same: http://iloveubuntu.net/lightdm-unity-greeter-oneiric-ocelots-awesome-default-display-manager The third commenter apparently thinks it represents organisation and community.
<lifeless> RAOF: my statement was:
<lifeless> 10:43 < lifeless> so the use case is 'It is possible that no single keyboard layout will permit all user son a shared machine to enter their passwords'
<lifeless> 10:43 < lifeless> s/user son/users on/
<lifeless> 10:43 < lifeless> s/use case/problem statement/
<RAOF> lifeless: Right.
<Rovanion> RAOF: My bed is screeming my nime right now. I hope my school in Khazakstan is a good enough use-case to include layout switching
<RAOF> Rovanion: I'll bring that up on the desktop mailing list; this seems to be something that we haven't yet thought about.
<Rovanion> RAOF: Great!
#ubuntu-devel 2012-09-03
 * hyperair kicks lightdm
<hyperair> it refuses to log me in, and i don't see *ANYTHING* in the logs.
<hyperair> okay, so removing ~/.Xauthority did the trick.
 * hyperair sighs
<hyperair> it would be nice if lightdm actually said something somewhere about this
<micahg> hyperair: sounds like a bug somewhere unless you were tinkering with the file manually
<hyperair> micahg: i don't know, really
<hyperair> micahg: what creates .Xauthority?
<hyperair> besides lightdm?
<hyperair> i had a root-owned .Xauthority for some reason
<micahg> sorry, this is one area i know very little about, maybe robert_ancell could help
<pitti> Good morning
<dholbach> good morning
<cjwatson> tkamppeter: it looks as though c2esp needs to be updated to version 26~rc4 or so to handle cups 1.6 (it's showing up on http://people.canonical.com/~ubuntu-archive/nbs.html) - is that something reasonable that you could take care of, or does it need the relevant changes to be backported instead, or ...?
<dupondje> We stay on kernel 3.5 for quantal?
<cc11rocks> Hey guys. Just started fixing bugs today. Fixed 15 spelling/grammer <package>/debian/control files (package descriptions). I have already proposed them. If you want to accept them : https://code.launchpad.net/~cc11rocks
<cc11rocks> Goodnight everyone
<cc11rocks> Will try to find time when I get up to do a few more
<cc11rocks> Takes approx. 4-5 min for each fix total (downloading, etc)
<cjwatson> Sigh, if I'd caught cc11rocks in time I could have advised him to stop and submit to Debian instead
<cjwatson> I've commented on one of the MPs to that effect
<cjwatson> dholbach: ^- we should amend our docs somehow to discourage this - it's well-meaning but new people don't realise the ongoing merge cost it incurs and it ends up filling up sponsorship queues
<xnox> cjwatson: I believe typpos is one of the developer initiatives we are running =) so I guess we should accept them & push to debian.
<cjwatson> If it is that is horrendously misguided
<cjwatson> We should stop
<seb128> cjwatson, I think it's https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative
<cjwatson> We should be making rational cost-benefit analyses here, not "developers at all costs"
<cjwatson> Sigh
<pitti> yeah, I used to reject those MPs as well and sent the diff as Debian bugs instead
<seb128> that page is a bit misleading
<seb128> it does ask to open a mr first then adds
<seb128> "There are obviously more packages to be fixed, but as they are also in Debian, we'd prefer to get them fixed in Debian, so you might want to take these steps as well: "
<cjwatson> It does have a tiny note at the bottom that you might want to submit to Debian
<MCR1> cjwatson: I would prefer software without spelling errors, so if someone takes the time to fix those they should ofc be accepted. Why not ?
<seb128> yeah, it should probably be the other way around
<cjwatson> MCR1: Because there is a significant ongoing cost in diverging from Debian
<seb128> MCR1, because the fix should directly go where it's useful for everyone and less work to maintain
<cjwatson> MCR1: I too prefer software without spelling errors; what I'm saying is not that they should not be fixed, but that they should be sent directly to Debian rather than going via merge proposals to Ubuntu
<MCR1> Then those should be somehow pushed upstream
<cjwatson> That's what I'm saying!
<MCR1> ok
<cjwatson> The submitter should do that directly
<cjwatson> It's no harder than preparing merge proposals (arguably easier - there's a different learning curve I suppose but the technology stack involved is simpler)
<cjwatson> I don't think this is cc11rocks' fault in any way, just that he should be given better direction
<seb128> we should reverse the instructions' order on that page
<seb128> tell them to first send to Debian (if it applies there), then to open a m-r with a link to the debian bug
<cjwatson> In general people should only do one of those; we should be careful to avoid advising them to do both
<cjwatson> Otherwise duplicate effort etc.
<pitti> I don't think we ever want MPs for those
<cjwatson> And if that fails some kind of "should be of direct benefit to Ubuntu" test, perhaps we should consider advising people to do other things
<seb128> right, that's what I was going to say, I think the idea is to get people contribute to Ubuntu (directly)
<seb128> so maybe those typo fixes are not what we should recommend
<seb128> dholbach, ^
<cjwatson> It's a good classroom exercise for preparing merge proposals, but ...
<xnox> I am ok with highly visible spelling error fixes. E.g. fontconfig started complaining a lot -> visible on the stderr on every app launch -> had a spelling mistake and we fixed it cause we are pedantic like that
<xnox> if on the other hand the spelling error is GB vs US locale in an error message I will never see in a low-popcon package....
<cjwatson> And for errors in things that are Ubuntu-specific
<xnox> yes
<cjwatson> But most new contributors won't have the ability to discern that, more or less by definition
<cjwatson> Except in the odd obvious case
<cjwatson> (Agreed on fontconfig - that was bugging me just this morning)
<Laney> those warnings are irritating me enough that I will probably take some time to fix some of them this week
<Laney> and I've seen some people worries in bug reports
<pitti> xnox: you mean fontconfig s/was/fixed/will be fixed/? it's still complaining a lot here (but then this doesn't seem to be a simple typo)
<Laney> there was some english error in the warning message
<xnox> pitti: it used to complain with a spelling error. Now it complains in correct Queen's English.
<seb128> pitti, I think he said the error message has a typo
<MCR1> xnox: Apropos fontconfig :) - I've fixed a bug in font-manager - Can I speed up the merge of this somehow ? : https://code.launchpad.net/~mc-return/font-manager/font-manager.fix-961034/+merge/114991
<pitti> oh, the "may not works", I guess
<cjwatson> xnox: Either your fix hasn't landed yet, or your fix was buggy :-)
<cjwatson> (If that was yours)
<cjwatson> Fontconfig warning: "/etc/fonts/conf.d/25-wqy-zenhei.conf", line 11: Having multiple values in <test> isn't supported and may not works as expected
<xnox> cjwatson: it was not mine =) I saw it somewhere
<xnox> oh well, it's still there
<MCR1> haha, yes I know this error message :)
<xnox> MCR1: it's annoying as hell =) i get a screenful of them on every xdg-open call
<MCR1> hehe
<seb128> xnox, there is a bug with the details, I pointed to a diff to fix one of the package and gave details on how to fix those
<seb128> xnox, I just didn't have time to work on them before ff
<seb128> ogra_, infinity: thanks for the unity fixes, could you guys commit them to the vcs?
<ogra_> nope
<seb128> ogra_, why not? ;-)
<xnox> no commit access to lp:unity?
<ogra_> because the packaing has to be fixed anyway, whoever that does can pull in the fixes in one chunk ....
<seb128> xnox, the packaging is lp:ubuntu/unity and those who can upload can commit there ;-)
<xnox> seb128: meh =) for ubiquity we use lp:ubiquity only
<seb128> xnox, bad you guys, no cookie
<ogra_> xnox, desktop is a bit weird in that regard :)
<seb128> ogra_, lp:ubuntu/... is not the desktop weird way :p
<seb128> ogra_, the desktop weird ones are lp:~ubuntu-desktop/source/ubuntu
<ogra_> oh, indeed, sorry :)
<cjwatson> lp:ubiquity is because it's a native package
<cjwatson> Which is a choice I'm happy to defend since it's the Ubuntu installer and not really intended for use elsewhere
<cjwatson> If anyone ever gets to the point of being able to use it elsewhere then we might reconsider that
<seb128> cjwatson, the only issue I have with those is that it means coredev doesn't have commit access to the vcs
<cjwatson> Well
<seb128> but it's not the end of the world, and not like ubiquity needed uploads from people out of the ubiquity team often
<cjwatson> We could fix that by making ubuntu-core-dev a member of ubuntu-installer, and almost certainly should
<cjwatson> The only reason I haven't is that I wanted to think about what that would do to bugmail
<seb128> well, then it means you might give access to trunk to more people than you want to
<cjwatson> I'm happy for anyone in core-dev to have commit access
<cjwatson> I suspect that we should have separate "commit access" and "bug mail" teams
<seb128> right
<tkamppeter> cjwatson, I will update c2esp to said version. Thanks for the hint.
<seb128> tkamppeter, what version? with the patch I sent you?
<cjwatson> 09:12 <cjwatson> tkamppeter: it looks as though c2esp needs to be updated to version 26~rc4 or so to handle cups 1.6 (it's showing up on http://people.canonical.com/~ubuntu-archive/nbs.html) - is that something
<cjwatson>                  reasonable that you could take care of, or does it need the relevant changes to be backported instead, or ...?
<cjwatson> seb128: ^-
<seb128> cjwatson, thanks, I had a patch locally to fix the ftbfs and I emailed it to Till for feedback but that staled since
<seb128> nice to see that upstream fixed it though ;-)
<seb128> I couldn't find their vcs by then
<dholbach> cjwatson, on the wiki page I advertised only Ubuntu-only packages and mention submit to Debian (and how to submit) a couple of times - https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative
<dholbach> it looks like c11rocks picked a bunch of others
<dholbach> I'll try to make it even clearer
<dholbach> and start a discussion on the mailing list about getting some help picking "useful, but easy" things
<cjwatson> thanks
<Laney> I suppose it's pretty hard though, since if the fixes are useful and easy then they are likely to be fixed fairly rapidly by existing developers
<dholbach> or we could try to bundle them - a lot of the packages which haven't been touched for a while might have multiple problems
<dholbach> in any case I agree that as much as possible should be sent to Debian
<dholbach> so I'll take care of that one
<dholbach> but first I'll have to get lunch, so see you in a bit :)
 * xnox If you use bzr-cia please pull new revision to get it working again!
<ogra_> xnox, bug 1044717 (see last comment)
<ubottu> Launchpad bug 1044717 in ubiquity (Ubuntu) "ubi-partman crash during Quantal daily install on Panda board" [Undecided,Confirmed] https://launchpad.net/bugs/1044717
<ogra_> i assume thats not arm specific ?
<xnox> ogra_: uno momento misseur
<ogra_> :)
<xnox> ogra_: *sigh*
 * Laney eyes xnox
<ogra_> how did i know you would say that :)
<xnox> ogra_: I swear I tested it......
<ogra_> wel, i find it inbtresting that we dont drown in similar bugs from other arches
<dupondje> We stay on kernel 3.5 for quantal?
<ogra_> xnox, i can confirm it on my panda, exact same issue here
<xnox> ogra_: yes. if you try to do something which needs to show warning box, it will fail.
<xnox> on any arch
<ogra_> ah, thats why we only see it on arm
<Laney> I added it to the pad as a respin trigger
<ogra_> its the only arch with a warning box by default
<xnox> ogra_: installation medium mounted.....
<ogra_> yep
<ogra_> i still think we should just blantly hide the mmc
<ogra_> (in desktop ... but keep it shown in i.e. netinst ...)
<cjwatson> dupondje: that's my understandng
<cjwatson> +i
<cjwatson> "installation medium mounted" is liable enough to happen in other situations, so worth a respin on all arches
<xnox> ogra_: can I send you a file to test?
<ogra_> sure
<dupondje> ok thx cjwatson  :)
<xnox> ogra_: see PM
<ogra_> cjwatson, whats your opinion on having the mmc (source media) show up at all in the partitioner ? it fails if you dont pre-format/pre-partition the device, i really think we shouldne encourage third party partitioning installs ... if users want to install to their source media they should better use netinst
<ogra_> *shouldnt
<cjwatson> There's a general attempt in partman to stop the installation medium showing up
<cjwatson> Doing something that's specific to MMC is likely wrong
<cjwatson> Feel free to improve the existing code if you can do it in a general way, though
<cjwatson> Perhaps first try to understand why whatever your current situation is doesn't trigger the existing checks
<xnox> cjwatson: partman prevents changing the partition table of the installation medium, but it still shows it's partitions for the installation mount points.
<xnox> ogra_ proposes to not show installation medium partitions / disk at all
<xnox> and the window saying "you cannot change the partition table" does show up in the d-i and ubiquity currently. (as seen on panda boards)
<cjwatson> If there's no remaining usable space on a disk due to the installation medium consuming it all, then I would say we should hide the dis
<cjwatson> *disk
<cjwatson> I wouldn't be in favour of hiding individual partitions from a disk with usable space, since I think that could easily get confusing
<xnox> cjwatson: ok. except that you can't change empty space =) so it has to be a pre-made partition or show nothing then?!
<cjwatson> I don't understand the question
 * ogra_ would already be fine with a preseedable option, we set aubarch specific kernel cmdlines anyway on the arm images
<cjwatson> Which of the above two cases are you talking about?
<cjwatson> ogra_: I wouldn't
<ogra_> *subarch
<cjwatson> ogra_: Similar situations arise in other cases where that is much less convenient; general code is always better where possible
<xnox> ogra_: for desktop if the sd card is less than 9GB (1GB for the installer image + 8GB for the minimum ubuntu desktop install size) i think it makes hence to hide the installation media from the partitioner.
<xnox> in the ubiquity installer.
<cjwatson> xnox: Could you please expand on "except that you can't change empty space =) so it has to be a pre-made partition or show nothing then?!"?  I don't know which case you're talking about here.
<Laney> how did the current fix test out?
 * Laney would like that in soon if possible
<cjwatson> We should never be silently hiding only some parts of a disk
<ogra_> well, moving with cjwatson's argument from above yu could use a 2G partition on the SD as /home ;)
<cjwatson> Indeed, which is why it is invalid to make deductions about free space usability based on the minimum desktop install size
<cjwatson> Let's not do that
<ogra_> (if it was pre-formatted and nothing treis to touch the partition table)
<ogra_> *tries
<xnox> cjwatson: right so. If I have an SD card: 300 MB FAT boot partition, 1.2GB ubiquity/installcd partition, the rest is empty (20GB) for example.
<cjwatson> You can generally append to the partition table even if an earlier partition is mounted
<xnox> ah
<cjwatson> The thing you can't do is manipulate anything <= the latest busy partition
<ogra_> cjwatson, well, it seems to be pretty fragile
<ogra_> i get bugs about it occasionally but its not always reproducable
<xnox> but partman doesn't seem to let me make any changes to the partition table. Not even "append" operation as you say technically is possible.
<ogra_> (about partman trying to touch the part-table regardless)
<cjwatson> It should permit it with a warning
<cjwatson> This has worked in the past
<xnox> hmm.... Ok will test again.
<cjwatson> And it's important in some USB-related use cases
<ogra_> it often enough works for me when i try to verify such a bug
<cjwatson> ISTR that some $bigcorp factory install scenario relied on it
<cjwatson> So please don't break it :-P
<ogra_> but these bugs come up
<xnox> cjwatson: =)))))) not only it's a bigcorp it also has monies on the front =)
<dholbach> does anyone have an idea how to fix https://launchpadlibrarian.net/114487674/buildlog_ubuntu-quantal-i386.ubuntu-packaging-guide_0.2.3-0~135~quantal1_FAILEDTOBUILD.txt.gz?
<tkamppeter> seb128, cjwatson, I have uploaded a fixed c2esp now, but note that I have used 25c with seb's patch, as the upstream change is a mess. It is untested,m according to the README, file and it seems to be written completely from the top of the head of the author, not working at all.
<cjwatson> Fair enough
<tkamppeter> seb128, sorry for getting to that only lately, I had higher-priority things like auto driver download integration into s-c-p iteself and CUPS USB fixes to do.
<seb128> tkamppeter, no worry, thanks for getting that uploaded
<seb128> tkamppeter, the s-c-p and cups work were higher priorities so you worker in the right order ;-)
<tumbleweed> dholbach: as far as I can tell. missing build-dep on texlive-lang-cjk
<dholbach> that'd be too awesome to be true
<dholbach> let me try
<tumbleweed> it's pretty confusing
<dholbach> I tried all kinds of other things already, but if that's it, that'd be awesome :)
<tumbleweed> but ja uses a different latex, which isn't pdflatex, causing the error we saw there
<dholbach> tumbleweed, does 'make pdflatex-ja' work for you?
<dholbach> for me it doesn't :/
<tumbleweed> dholbach: it does, now
<dholbach> hum, can you maybe pastebin the output of   dpkg -l | cut -d' ' -f3 | grep tex   somewhere? I might be missing something
 * tumbleweed has quick play in a chroot
<shadeslayer> seb128: telepathy-glib is depping on valac >= 18, but valac depends on valac-0.14
<shadeslayer> causes telepathy-glib to go into build dep wait
<seb128> shadeslayer, thanks
<shadeslayer> np
<seb128> it should depends on valac-0.18 I guess
<seb128> Laney, cjwatson: ^ is that something you would like to see fixed for beta1 or should we keep it depwaiting?
<shadeslayer> don't know enough about vala packaging to give my opinion =)
<cjwatson> I think we only care if there are important bug fixes we don't in practice have on images due to the dep-wait
 * Laney grumbles about alternate build-depends
<tumbleweed> dholbach: erm, dirty environment :( . So, we need something like the first hunk of https://bitbucket.org/birkenfeld/sphinx/pull-request/33/style-fixes-to-handle-japanese-documents#chg-sphinx/texinputs/sphinx.sty
<seb128> cjwatson, no, they are none, I will get that fixed after beta1
<brendand> is there a version of pyflakes that likes python3?
<cjwatson> I haven't found one; I just write code compatible with both Python 2 and 3 and it's OK with that
<cjwatson> Aside from a few warnings about duplicate imports
<dholbach> tumbleweed, great - I'll have a look
<tumbleweed> dholbach: (and then a platex to build it, which was the missing build dep)
<dholbach> tumbleweed, still no dice over here, but I updated the bug and subscribed you as well
<dholbach> I'll have a look at it tomorrow again, now I need to finish some other bits first :/
<tumbleweed> dholbach: not building the PDF on JA for now is the easy answer. JA PDFs are a weird special case
<dholbach> tumbleweed, I guess you're right
<rbasak> I'm going to need linux 3.2.0-30 in precise-updates d-i netboot for maas to deploy highbank correctly. It's got an RTC fix I need, and is in precise-proposed at the moment. What's the policy on bumping d-i in a stable release in order to get a new kernel?
<cjwatson> It's already done in -proposed
<cjwatson> Would have replied last week but you'd quit IRC
<cjwatson> The policy is JFDI
<cjwatson> Of course d-i will need to wait for all contained kernels to go to -updates before it can go to -updates itself
<cjwatson> But after that we can JFDI the copy
<Riddell> mhall119: any idea when we learn about UDS sponsorship?
<mhall119> Riddell: hopefully today
<rbasak> cjwatson: got it - thanks!
<Andy80> hi
<dpm> hi cjwatson, would you mind approving the e-mail I just sent to ubuntu-devel?
<cc11rocks> Bash script for repetitive bug fixes (instructions and explanations in link) : http://pastebin.com/a6AJQzJg
<cc11rocks> Updated, refresh
<jtaylor> cc11rocks: don't overdo it with typo fixes
<jtaylor> many of them aren't worth deviating from debian
<jtaylor> better forward the fixes to upstream/debian
<cc11rocks> Can I do both?
<xnox> cc11rocks: ubuntu specific packages -> send to ubuntu; if package unmodified from debian -> send to debian/upstream
<cc11rocks> So I'll have to look at each package manually beforehand to determine?
<jtaylor> in 9X% of cases its a package from debian
<cc11rocks> Okay, thank you
<bryce> cc11rocks, you could add a script that helps identify where fixes should be sent, and helps forward them the appropriate way
<cc11rocks> Eh, have to look this stuff up...
<cc11rocks> All I have to run is submittodebian ?
<cc11rocks> And I deleted the packages and such that I changed. Can I forward my packages from/through the LaunchPad branches?
<jtaylor> just download the branches again
<jtaylor> with bzr branch ...
<cc11rocks> But "submittodebian" will successfully forward it to debian?
<cc11rocks> Is there a Colin Watson here? If so, please PM me (related to Ubuntu/Debian bugs...)
<xnox> cc11rocks: his irc nick name is cjwatson and he is here.
<cc11rocks> Thank you xnox
<xnox> cc11rocks: it's better to actually type your question to start a conversation in a PM.
<cjwatson> Yes, although I prefer to talk on channel if it isn't private
 * xnox steps away =)
<cjwatson> That way others can help
<cjwatson> cc11rocks: http://irclogs.ubuntu.com/2012/09/03/%23ubuntu-devel.html#t09:48
<cc11rocks> I was wondering whether I could submit my changes to both Debian and Ubuntu...
<cjwatson> Please don't
<cjwatson> Unless it's actually urgent
<cjwatson> Otherwise it just duplicates effort
<cc11rocks> And yes, that is how I got started from that link
<cjwatson> (above discussion - up to maybe 09:57 or so, then it goes off on a few tangents)
<cjwatson> I think this is very much our documentation directing you in an inappropriate way
<cc11rocks> Should I delete my 30+ requests in LaunchPad then :| ?
<cjwatson> If they're all spelling fixes, I think they should all be forwarded to Debian rather than being applied directly to Ubuntu
<cc11rocks> Aw, crap
<cc11rocks> Alrighty then
<cjwatson> It's unfortunate nobody managed to give you better advice before you'd done a ton of work, and I'm sorry about that
<cjwatson> The intention of the docs was (as I understand it) to fix up spelling issues like this in Ubuntu-specific packages
<cc11rocks> Okay, thank you
<cjwatson> In such cases of course the option of forwarding to Debian isn't present and it's fine to work in Ubuntu
<cjwatson> You can use rmadison or packages.debian.org or packages.qa.debian.org to see whether the package is in Debian
<cjwatson> On the upside you are now presumably thoroughly familiar with branching source package branches and creating merge proposals and such and can re-apply those skills
<cc11rocks> Would this work : http://pastebin.com/PeDF5LJK
<cjwatson> And it should be possible to extract the actual patches you wrote pretty quickly and reuse them
<cjwatson> You don't necessarily have to use submittodebian as such
<cc11rocks> It's edited from my old one...
<cjwatson> Eh
<cjwatson> Not a lot of point doing the whole branching dance
<cjwatson> Patches sent to Debian should be against Debian, for obvious reasons :-)
<cc11rocks> Here was my old one : http://pastebin.com/a6AJQzJg
<cjwatson> If the package is currently in sync between Debian and Ubuntu then there's no difference
<cjwatson> It would be quicker to extract patches from your existing branches, surely
<cc11rocks> bzr branch lp:debian/$package?
<cjwatson> Yeah, or pull-debian-source
<cc11rocks> Okay, thanks
<cc11rocks> So this will work fine : http://pastebin.com/PeDF5LJK
<cjwatson> submittodebian relies on a build having happened
<cc11rocks> Oops, meant to ask you to refresh, not repost...
<cjwatson> Well, a source package build
<cjwatson> I don't think it's appropriate here
<cc11rocks> Agreed
<cjwatson> Don't commit, just use bzr diff and send that in a bug report
<cjwatson> 'reportbug -B debian' can help you file it, or you can see the Debian bug tracking system docs and send mail directly
<cjwatson> But, the point of the page you were following was to try to encourage people to contribute to Ubuntu; perhaps you want to find something where directly sending patches to Ubuntu would be appropriate?
<jtaylor> cc11rocks: if you forward stuff to debian now don't be let down if the patches won#t be applied swiftly, debian is currently frozen so updates only happen if they are important
<cjwatson> It's a cost-benefit trade-off - causing a package to diverge from Debian is a hidden cost because somebody will have to manually merge or sync it later, but that can be offset by a sufficiently beneficial change
<cc11rocks> Refresh again and confirm please :)
<cc11rocks> I see
<cjwatson> I would suggest you try the procedure by hand and then script what works for you, rather than trying to write a script first
<cc11rocks> Right
<cc11rocks> My bad
<cc11rocks> Thank you
<cc11rocks> Well, I cannot do anything more today as I have a ton of homework to do
<cjwatson> So we often enough take patches for, say, applications that are crashing in Ubuntu, and simply encourage that patch to be submitted to Debian in parallel
<cc11rocks> Talk to you guys soon. Thank you cjwatson and jtaylor for your help
<cjwatson> Because that's something where having the patch earlier might make a real difference to users
<cc11rocks> I see
<cjwatson> Or maybe I should say a substantial difference
<cjwatson> Spelling errors aren't imaginary :-)
<cc11rocks> :P
<cjwatson> I don't typically drive the entire cycle from a single script in my normal work
<cc11rocks> So how long approximately would it take for a low level fix (spelling error/etc) to show up/be applied/etc?
<cjwatson> Depends entirely on the activity level of the maintainer best placed to apply it
<cjwatson> Can't really give you an approximation
<cc11rocks> Within a month usually?
<cjwatson> Can't say
<cc11rocks> Okay, thanks
<cjwatson> cc11rocks: I do want to emphasise that we appreciate the effort - and I think this is totally our fault (collectively) for the docs being a bit vague on what the point of it is
<cjwatson> You clearly have the patience needed :-)
<cc11rocks> :)
<cc11rocks> No problem.
<cc11rocks> I am a Java dev and am scared to get into real bug fixing. Will I be okay if I dove into Python/C++/etc code?
<cc11rocks> (Scared because of the language differences)
<cjwatson> Poor jamespage might appreciate some help with bugs in our various Java packages, which we currently tend to hurl in his direction :-)
<cc11rocks> Also, because of the possible massive references, will I have to learn thousands of codebases to understand a variable, etc?
<cjwatson> IME your second language tends to be about half as hard as your first (you have the concepts but have to unlearn a bunch of stuff too); after that it gets progressively easier
<cjwatson> Better to learn to search effectively
<cc11rocks> I've tried to dive into other languages, but it is very frustrating due to the syntax differences
<cc11rocks> it seems to be not worth my time, though in the long run it would be
<cjwatson> Variables are usually local to a single codebase; functions are (hopefully) namespaced reasonably rationally so that you can figure out what package they come from, but worst case there's always google
<cc11rocks> Already, thanks
<cc11rocks> So, to confirm, delete all my bzr branches...
<xnox> cc11rocks: keep the branches, for personal reference. Delete/reject the merge proposals.
<cc11rocks> I deleted the branches. The merges should be gone. Thank you
<xnox> cc11rocks: fair enough. Thank you for your persistence. And sorry for re-directing you so late.
<cc11rocks> No problem. Will try to work on it throughout the week, though I'll get most work done this weekend
<cc11rocks> Very busy with school and work, so don't know how much I can get done, but I'll make an attempt to do it a bit :)
<cc11rocks> If we are supposed to send to Debian, how come the bugs at https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative got accepted
<cc11rocks> ?
<cc11rocks> A lot of them have "fixed (andreagrandi)" next to them, indicating they got fixed already through Ubuntu...
<jtaylor> they aren't fixed with an upload
#ubuntu-devel 2012-09-04
<FourDollars> Hi, how do I push an new package into Ubuntu precise-updates ?
<FourDollars> Is https://help.ubuntu.com/community/UbuntuBackports ?
<FourDollars> https://wiki.ubuntu.com/UbuntuBackports
<micahg> !sru | FourDollars
<ubottu> FourDollars: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<FourDollars> micahg: thanks
<pitti> Good morning
<ajmitch> morning pitti
<pitti> wgrant: ah, yay duplication :) well,  it wasn't much lost
<wgrant> Indeed, there's not a huge amount of code to either of them :)
<RAOF> pitti: Hey, how do you unwrite a bugpattern? https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/929219 is accidentally snaffling lots of dbus crashes.
<ubottu> Launchpad bug 929219 in gwibber (Ubuntu Precise) "chromium-browser, gvfsd-http and others using eglibc crash with SIGSEGV in __nscd_get_mapping() or gethostbyname2_r()" [Undecided,Confirmed]
<pitti> RAOF: just change it in lp:~ubuntu-bugcontrol/apport/ubuntu-bugpatterns, the cron job pick it up in the next 15 mins
<pitti> RAOF: but I guess in this case it should probably be refined instead of removed?
<RAOF> pitti: Probably.
<dholbach> good morning
<RAOF> pitti: Hm. Probably just switching from âThreadStacktraceâ to âStacktraceâ would do, I think.
<RAOF> Why can you match on ThreadStacktrace, anyway? That seems hugely prone to false-positives.
<pitti> bug patterns don't care -- they have no logic of their own
<pitti> they just apply whichever key/value regexp matches you specify
<pitti> ogra_: the instructions for the current armhf desktop images make it sound like they'd boot right off USB -- is that really possible now?
<ogra_> erm, no
<pitti> (from http://iso.qa.ubuntu.com/qatracker/milestones/232/builds/22473/testcases)
<ogra_> the panda ROM can only boot off SD or usbnetwork via the mini USB port
<pitti> ogra_: ok, so still "burn .iso on SD card and install onto USB-stick and generate a small boot SD"
<pitti> ogra_: merci
<ogra_> pitti, ah, i think thats just a copy/paste of the x86 instructions
<ogra_> pitti, sudo dd if=path_to.img of=/dev/your/sd/card bs=4M
<pitti> yeah, been there, done that; I just wondered whether the instructions were deliberate
<ogra_> attach a USB disk as target device to your panda, plug in the SD (and monitor,mouse,kbd) and just boot
<ogra_> the rest is like any other desktop install (except that we dont run a live session by default)
<ogra_> and dont remove the SD after install, it becomes your "bootfloppy"
<pitti> nice; I'm eager to see the progress since alpha-2, it's been a while since I touched the Panda board
<ogra_> well, we default to have the 3D driver installed now ... and you run the "real unity" :)
<seb128> ogra_, 2 USB ports, ENOTENOUGH for keyboard,mouse,usb stick
<ogra_> there are still flickering issues and since we switched to 3D by default firefox got massively slow
<RAOF> Heh. I'll need to try that again.
<ogra_> seb128, yeah, you need a hub :(
<RAOF> seb128: You mean your monitor is *not* a usb hub? :)
<seb128> RAOF, not only it's not an usb hub, but it also doesn't do hmdi, only vga and dvi... ;-)
<RAOF> seb128: You may have other problems, then :)
<ogra_> seb128, you *can* install to SD ... but need to prepare the partitioning in advance and make sure the partitioner of ubiquity doent touch the device at all during install
<ogra_> *doesnt
<seb128> RAOF, I've been using the pandobard on the TV so far, it's my only hdmi capable screen
<ogra_> seb128, so put that TV in your office and expense a new one ;)
<seb128> ogra_, I guess I can as well install with a keyboard and no mouse, or hotswap those :p
<seb128> ogra_, ;-)
<ogra_> oh, yeah, indeed
<xnox> I have single USB dongle for wireless keyboard&mouse =) Win! =)
<pitti> jibel: on the ubiquity screen about partitioning/formatting ("erase/lvm/encrypt/other"), the continue button does not work; did you see this on other platforms as well? (I'm trying current beta-1 armhf)
<xnox> pitti: hmmm...? do you have external drive plugged in or are you doing 'pre-partioned' way?
<jibel> pitti, it works on intel
<xnox> pitti: and ogra was reporting success on panda's with yesterdays beta candidates I think....
<pitti> I tried back and next again, and now it works
<pitti> I only plugged in the USB drive when the ubiquity start screen was already on, so perhaps it got confused due to that
<xnox> yes it would, cause it locks down environment / blocks device events early.
<tsdgeos> do we plan to fix/silence out that annoying fontconfig warnings each time you start an application?
<xnox> tsdgeos: Laney was planning to mass upload / fix all the fonts.
<Laney> hahaha
<Laney> I think I actually said that I /might/ fix /some/ of them :P
<Daviey> three cheers for Laney, volunteering to fix all of them. hip, hip.
<xnox> HORAY! =)
<ogra_> *clap* *clap* *clap*
<Laney> /quit
<ajmitch> heh
<Laney> but really, which ones are there on a default install?
<Laney> is it just the ones from l-s?
<ajmitch> but look at all the support you're getting
<Laney> yes... I could convert it into delicious Danish beer
<xnox> dholbach: we really need developer initiative for bug 1034928
<ubottu> Launchpad bug 1034928 in language-selector (Ubuntu) "Fontconfig warning: Having multiple values in <test> isn't supported and may not works as expected" [Undecided,Confirmed] https://launchpad.net/bugs/1034928
<xnox> they annoy everyone and there are too many font-config based fonts with these warnings which spam stderr
<Nafallo> hi
<ogra_> look another volunteer
<Nafallo> I'm just running ubuntu-support-status on a server for a customer, and I see the kernel is showing up as only 18m support.
<Nafallo> what's going on? o_O
<Nafallo> this is on LTS obviously.
<xnox> thanks ogra_ !!! I knew you would step up =)
<ogra_> erm
<ogra_> xnox, i promise to fix all fonts that fail on arm after Laney is done ;)
<ajmitch> Laney: no-change rebuilds then? :)
<cjwatson> Nafallo: Oh, that probably needs a seed tweak.  What's the ABI version here?
<cjwatson> Nafallo: And do you mean precise?
<Nafallo> cjwatson: precise indeed. ABI 29 :-)
<Nafallo> cjwatson: thanks for confirming my suspicion :-)
<cjwatson> Hmm, right - let me prod at this, the SUPPORTED_HINTS stuff looks rather unloved in precise
<Nafallo> heh
<Nafallo> another thing for the checklists ;-)
<cjwatson> Nafallo: Which package name *exactly*?
<dholbach> xnox, feel free to add it to  https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative :)
<Nafallo> Supported until October 2013 (18m):
<Nafallo> linux-image-server
<Nafallo> Supported until March 2014 (18m):
<Nafallo> linux-headers-3.2.0-29 linux-headers-3.2.0-29-generic
<Nafallo> linux-image-3.2.0-29-generic
<Nafallo> ^-- cjwatson
<cjwatson> OK, thanks
<cjwatson> I wonder what's going on with those dates
<xnox> dholbach: ok.
<Nafallo> they do seem a bit random, don't they? :-)
<dholbach> :-D
<cjwatson> Because one of "until October 2013 (18m)" and "until March 2014 (18m)" is lying
<cjwatson> Never mind anything else
<cjwatson> So linux-image-server is kind of OK as it is - the supported thing is linux-image-generic-pae, -server is just a transitional package really
<cjwatson> Oh, except this is amd64 isn't it
<cjwatson> linux-image-generic then
<cjwatson> So in that case it probably is just the usual business about bumping for new ABIs
<Nafallo> server and generic are the same these days?
 * ogra_ wonders if the back/forward buttons in the ubiquity slidesho work for anyone else or if thats a pandaboard specific bug
<ogra_> +w
<cjwatson> Nafallo: I *think* this should be fixed after the precise-updates Packages files are next regenerated (so whenever an SRU is next published there)
<Nafallo> okay, kewl :-)
<Nafallo> I'll keep testing.
<Nafallo> thanks muchly cjwatson
<pitti> ogra_: now I understand why we had had preinstalled images .. this is taking half a day
<ogra_> pitti, with a decent usb disk or key its about 1h
<ogra_> (i use a 32G USB 3.0 key here, that finishes in 45min)
<ogra_> OMAP5 will have SATA ... that should finish in 10min then
<ogra_> USB 2.0 simply only allows 24M/s max.
 * ogra_ reboots into his finished install
 * Laney joins the panda-fest
<pitti> ogra_: does unity actually work for you? I've let the blank wallpaper with a mouse cursor stay around for 10 minutes, and nothing happens
<ogra_> pitti, yes, works fine, i just reported my bugs on the running desktop
<ogra_> pitti, did it work now ?
<pitti> ogra_: no, I just set it back to my usual mode -- disable lightdm, install openssh-server, and let it sit headless under my desk
<ogra_> hmpf
<ogra_> would be good to know what failed and why
<ogra_> do you know which model your panda is ?
<ogra_> (there should be a sticker on the bottom)
<pitti> "ES Rev B1"
<pitti> PCBA: 750-2-2170-002 REV B
<ogra_> hmm, that shouldnt have any issues
<ogra_> im currently testin on a B2 but all the ES'es should be fine
<ogra_> pitti, filing a bug with ~/.xsession-errors and Xog.0.log might be helpful
<pitti> okay; will do after I finish packaging pygobject and having lunch
<seb128> ev, jodh: you guys still have workitems on https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-graceful-failure that were targetted at beta1, I'm moving them to beta2, could you set them to postponed if you think you will not get to them this cycle?
<ev> seb128: just saw - cheers
<Laney> ogra_: oh god, the flickering!
<ogra_> Laney, fun, isnt it :)
<ogra_> bug 1045491
<ubottu> Launchpad bug 1045491 in pvr-omap4 (Ubuntu Quantal) "Moving mouse messes up the desktop" [High,Confirmed] https://launchpad.net/bugs/1045491
<Laney> cheers
<Laney> the mouse seems slightly laggy too, but that could be me
 * ogra_ would more like to know why the server image doesnt give any screen output at all
<ogra_> gah !
<ogra_> seems the new framebuffer driver actually requires console= to be set
<Daviey> does it make sense for svn to still be in main?
<cjwatson> That depends on whether we care about our userbase who are developers of things other than free software.
<cjwatson> Or indeed free software in more corporate kinds of settings.
<cjwatson> In fact we use it ourselves in our datacentre (think LP code imports) so we de facto support it anyway.
<Daviey> cjwatson: right, i'm not saying throw it out of the archive :).. just trying to work out if it still has a place in main.
<Daviey> cjwatson: Does Launchpad use 'svn' for imports?
<Daviey> ah, libsvn1 from svn
<cjwatson> Daviey: What I mean is that we don't really gain much as an organisation by pretending not to support something we use ourselves
<cjwatson> I knew you didn't mean to throw it out of the archive
<mdeslaur> Is svn much of a maintenance burden? I don't really like the idea of tools our developers use to fetch upstream sources and patches not getting security updates...
<Daviey> mdeslaur: fair point.
<cjwatson> Quite.  I suspect Daviey is asking because it has a pending MIR attached.
<Daviey> The only reason i raised this was becuas eit has a Recommends showing on C-M.. and wanted a quick health check to see if it is still suitable
<cjwatson> svn2cl doesn't look that complex though.
<cjwatson> (Well, I haven't looked at the code but how much complexity can you realistically fit inside 20KB ...)
<cjwatson> * answers from information theorists not acceptable
<tjaalton> should removing /etc/dpkg/dpkg.cfg.d/multiarch be enough in disabling multiarch? doesn't seem to work on a quantal chroot, or I've missed something
<cjwatson> dpkg --remove-architecture i386
<cjwatson> (dpkg --print-foreign-architectures)
<tjaalton> thanks
<dpm> cjwatson, sent another e-mail to u-d, would you (or someone else who's got access to the moderation queue) mind approving it? I've also got another one coming later on
<seb128> dpm, you should subscribe to the list ;-)
<cjwatson> Subscription doesn't help with u-d.
<dpm> exactly :)
<cjwatson> I've processed your mail.
<seb128> cjwatson, what teams have access? I guess ubuntumembers doesn't?
<cjwatson> It's supposed to be ubuntu-dev.
<BenC> Laney: fyi, I'm working on that cryptocipher build failure
<Laney> ah, excellent
<seb128> cjwatson, ok, makes sense, it just feels weird that dpm is out of the set of people who can post there ;-)
<cjwatson> Well, I can always whitelist him.  I'll do that now.
<seb128> dpm, you should become ubuntu developer, come on #ubuntu-desktop we will find you stuff you can help with ;-)
<dpm> cool, thanks seb128 and cjwatson ;)
<dpm> seb128, oh, didn't realize the whitelisting came at a price! ;-)
<cjwatson> Whitelisted now.
<Daviey> step aside seb128.. dpm wants to make the cloud a better place.
<seb128> dpm, I was suggesting you the "proper way", whitelist is cheating :p
<dpm> hahaha
<dpm> I feel pressured now
<seb128> Daviey, heh, I was there first, I won fair and square, back off :p
<Daviey> dang.
<dpm> Daviey, oi, you've already got jcastro, you only get one community guy per team!
<seb128> or dpm could do desktop during the day and cloud at nights... ;-)
<dpm> seb128, yeah, I think it's a good idea, I've always wondered what to do with my ever growing spare time :P
<seb128> dpm, ;-)
<seb128> take example on dholbach, he keeps telling me how much he misses doing desktop work!
<dpm> seb128, I know, he was just PM'ing me about how he misses the good old desktop days, you should assign them some work items :-)
<dpm> *him
<seb128> ;-)
<janimo> doko, hi, do you know which version of gcc are supposed to support -fuse-ld=gold ? Precise one does not seem to
<doko> janimo, none upstream until now. the safe way is to use -B/usr/lib/gold-ld/
<janimo> dobey, thanks
<janimo> sorry :)
<dholbach> seb128, haha
<dholbach> seb128, try to work with these guys https://launchpad.net/~canonical-community/+mugshots for a while and see what kind of other work you think of as worthwhile afterwards :-P
<seb128> dholbach, ;-)
<BenC> Laney: I'm getting ready to test this patch: http://hackage.haskell.org/trac/ghc/attachment/ticket/6156/0001-Fix-for-optimizer-bug-on-linux-powerpc-6156.patch
<BenC> Laney: We're definitely hitting this bug: http://hackage.haskell.org/trac/ghc/ticket/6156
<BenC> The minimal test case for -O0 and -O2 shows the failure in the current powerpc ghc
<Laney> BenC: groovy
<Laney> feel free to upload that if it works
<BenC> Excellent, thanks
<Laney> but please do a binary debdiff to make sure none of the Provides change
<Laney> I will cry if they do
 * soren is slightly amazed that Haskell on PowerPC is an area of anyone's particular concern
<soren> If I were to come up with an example of "niche", it might very well involve the words "Haskell" and "PowerPC" :)
<Laney> amazingly, there are actually at least *two* people that care!
<xnox> jibel: don't want to disturb #ubuntu-release. Debug shows 16.9 TB drive.... is that really 16.9TB drive?
<Rovanion> Where are X keymaps located. I've modified a map in /usr/share/X11/xkb/symbols/ but when I set the same map and the same variant that I modified, nothing changes.
<xnox> jibel: partman might not handle that well.
<jibel> xnox, well, I'd like to allocate 16TB to each VM I use, but no it's 16GB
<xnox> jibel: ok. I wonder if there is magnitude error somewhere.
<jibel> xnox, output of sfdisk http://paste.ubuntu.com/1185781/
<seb128> slangasek, hey, do you know if qemu-linary should build the spice binary on 32bits in quantal?
<jibel> xnox, especially for you I attached the error message in russian. as I said in the comment, the key seems to be to start the live session in a non-english language
<xnox> jibel: locale which has commas as the decimal separator and hence we get shell errors....?!
<zul> mterry:  ping
<mterry> zul, hello
<zul> mterry:  can you have a look at the MIR for requests please
<mterry> zul, yes, on my list.  I'll look at it now
<zul> mterry: cool thanks
<xnox> jibel: hmm.. no crash in the current test. but i did install instead of live-session -> install. will redo again now.
<zyga> hey
<zyga> I have a question about udisks and udisks2 being on our default desktop ISOs
<zyga> udisks is being pulled by checkbox
<zyga> and apparently nothing else on the CD needs it
<zyga> so here's the question:
<zyga> or questions:
<zyga> 1) is it safe/sane to keep both running at the same time? I've observed some differences as compared to precise and while I don't know if they are caused by the two running in tandem it's certainly a possibility
<zyga> 2) is there a strong desire to eject udisks from the ISO? If so we could bump the priority of the bug in checkbox and rewrite the relevant parts to use udisks2
<zyga> slangasek, hey, since I know you, do you know who might be the best person to ask about ^ ?
<zyga> jono, hey, would you mind telling me who is the best person to talk to, from the platform team,  about udisks 1 & 2 being on the ISO
<ogra_> zyga, pitti used to maintain it in the past, not sure who has taken over
<ogra_> (or if someone has)
<zyga> oh, cool
<zyga> pitti, ^^
<pitti> zyga: udisks 1 should disappear; hasn't it yet?
<zyga> nope
<pitti> urgh
<zyga> it's right on the iso
<zyga> because of checkbox
<zyga> and it's running
<jono> :-)
<zyga> so scroll up to see my questions above
<pitti> ah, and usb-creator
<brendand> pitti - usb-creator also pulls udisks?
<pitti> yes, there is a strong desire; udisks1 is unmaintained, and just mirrors what udisks2 is doing
<zyga> pitti, IIRC usb-creator was not in rdepends
<pitti> it is
<zyga> oh, sorry then
<pitti> usb-creator-common depends on it
<zyga> right usb-creator-common
<pitti> bug 1024405
<zyga> ok
<ubottu> Launchpad bug 1024405 in usb-creator (Ubuntu Quantal) "Port to udisks2" [Medium,Triaged] https://launchpad.net/bugs/1024405
<zyga> so I'm working on a bug to rewrite checkbox to udisks2
<pitti> zyga: nice, thanks!
<zyga> https://bugs.launchpad.net/checkbox/+bug/1016035
<ubottu> Launchpad bug 1016035 in checkbox "Add udisks2 support to scripts/removable_storage_* scripts" [High,In progress]
<zyga> pitti, we need to decide on priority
<zyga> if udisks1 will absolutely go away from the iso we'll bump it an get rid of udisks1 from quantal checkbox
<pitti> well, it can't go away as long as there are rdepends
<pitti> so we need to port checkbox and u-c
<pitti> then it'll fall off itself
<zyga> right
<xnox> is it hard to port between the two?
<pitti> the concept is the same
<zyga> xnox, the api has changed to some degree
<pitti> the API is a bit differently structured
 * xnox has a local port to python3 of the u-c which needs to land
<zyga> xnox, it's not just a x/1/2/ in the strings you send
<xnox> zyga: =(
<pitti> the biggest issue with usb-creator is that it has a full udisks mock implementation for the test suite
 * xnox lol
<zyga> ah
<brendand> !
<pitti> the actual parts that are being used at runtime are fairly small
<zyga> ok
<zyga> pitti, one last question, in case both end up on the CD
<zyga> pitti, and we run both by default
<zyga> pitti, is that safe?
<pitti> yes, should be
<zyga> pitti, as I've noted in my bug it seems to do less than it did in precise
<pitti> (and udisks 1 doesn't run until something talks to it)
<zyga> pitti, to be precise, it is not sending the signal on fs mounts anymore
<zyga> pitti, ah, good point, it's service activated
<pitti> I still see it in the udisks and gvfs monitors, and gvfs depends on tracking mounts
<zyga> what do you see?
<zyga> the job FilesystemMounted?
<zyga> I don't see that in dbus-monitor anymore
<pitti> 16:56:28.416: /org/freedesktop/UDisks2/block_devices/sdb: org.freedesktop.UDisks2.Filesystem: Properties Changed
<pitti>   MountPoints:          /mnt
<zyga> udisk2 yeah
<zyga> udisk1 nope
<pitti> yeah, sure -- since it doesn't run by default
<zyga> we have a bug in checkbox where it fails to detect a thumb drive
<pitti> unless you actually activate it?
<zyga> hmmm
<zyga> sure but I look at that attachment:
<zyga> https://launchpadlibrarian.net/114785262/device-inserted-quantal.txt
<zyga> udisk is running there as checkbox requests it
<zyga> but the signal it sends are different from precise where it also reported all fs mounts
<zyga> I'm not sure what's going on in the plumbing layer
<zyga> who does the mounting actually?
<zyga> is that udisks2 or udisks1 or something even lower?
<pitti> udisks2
<zyga> but that would explain why there is no signal
<zyga> (udisks2 was faster)
<zyga> right
<zyga> ok
<zyga> that explains everything then
<pitti> through gvfs, triggered by a gnome-settings-daemon plugin (but that doesn't matter)
<zyga> so in quantal udisks is just as capable, just not used by the relevant desktop machinery that requests the mount
<pitti> yes, it didn't really change
<zyga> ok, then it all makes sense now, thanks pitti
<zyga> I'll try to get rid of that dependency :)
<pitti> cheers!
<pitti> and with that, good night everyone!
<Riddell> barry: what is it about python3 that stops this working? http://paste.kde.org/543998/   importing pyqt should give you a qstring surely
<barry> Riddell: that might be a better question for ScottK?  i don't know the pyqt4 api very well and i wouldn't be surprised if the api were different for python3
<cjwatson> yes, it's different
<cjwatson> QString going away is a *good* thing, you get plain old python strings by default
<cjwatson> cf. ubiquity r5465 and r5466
<cjwatson> Mostly the latter
<cjwatson> If you don't have to worry about py2 compat then you can just throw plain python strings around and not worry about it
<BenC> Laney: The patch worked, so upload eminent
<slangasek> seb128: my recollection is that spice only works on 64-bit; hallyn would be able to confirm
<slangasek> zyga: maybe pitti
<slangasek> oh, already sorted ;)
<seb128> slangasek, some of the redhat people working on gnome-boxes says that's not true anymore and that spice got fixed to work on 32 bits
<seb128> slangasek, should work in the version we have
<zyga> :)
<seb128> slangasek, I will check with hallyn, thanks
<Riddell> barry: yeah, just wanted to make sure I haven't come across some fundamental python3 change I didn't know about
<barry> Riddell: not that i know of :)
<cjwatson> It's a change in pyqt, not a change in python3
<Riddell> pitti: I want to make a change to apport to fix bug 1028984 and I'm lost in the twisty maze of branches, where do I commit it and how to upload? http://paste.kde.org/544016/
<ubottu> Launchpad bug 1028984 in python-qt4 (Ubuntu Quantal) "apport errored when filing bug on test image alpha3" [High,Confirmed] https://launchpad.net/bugs/1028984
<Riddell> oh he's gone to bed
<Riddell> smoser: you uploaded apport, can you tell me what the right way is to make changes to it in bzr and the archive?
<jbicha> hi, I'm getting certificate errors when I visit wiki.ubuntu.com, anyone know if an rt ticket has been opened for that yet?
<TJ-> what's the error? the cert looks valid
<smoser> Riddell, i can tell you because i did it wrong :)
<jbicha> The certificate is only valid for the following names:
<jbicha> *.canonical.com , canonical.com
<TJ-> jbicha: I'm seeing it issued as a wildcard for *.ubuntu.com
<smoser> the upstream branch is a core dev branch, so suerly changes are supposed to be made there before being uploaded.
<smoser> https://code.launchpad.net/~ubuntu-core-dev/ubuntu/quantal/apport/ubuntu is the branch, but i'm not exactly sure how pitti wants it handled. bdmurray surely knows.
<jbicha> TJ-: what if you restart your browser?
<TJ-> jbicha: very strange! Firefox shows *.ubuntu.com but openssl s_client shows *.canonical.com
<TJ-> jbicha: And Chromium also shows *.ubuntu.com and I've never used Chromium on that site previously
<TJ-> jbicha: Could be an issue with front-end SSL load-balancers being out of sync
<jbicha> ok, filed rt ticket 20372
<xnox> jbicha: TJ-: the certificate there is blancket, i.e. cloud friendly. not all browsers / ssl implementations will accept it.
<xnox> but most modern browsers should.
<xnox> check which extensions the certificate is using.
<xnox> afaik it is not bound to particular IPs for *.ubuntu.com
<jbicha> ok, I restarted Firefox & it's working now, thanks
<seb128> xnox, for sound indicator integration you need mpris enabled in rb, not sure if you disabled that?
<seb128> xnox, it's in rhythmbox-plugins
<xnox> seb128: having that package uninstalled doesn't help me, does it?!
<seb128> xnox, no it doesn't
<seb128> ;-)
<xnox> seb128: that's what I get for partially upgrading at one point, don't I =)
<seb128> xnox, indeed, got what you deserved for using dist-upgrade :p
<xnox> seb128: now If you could help me regain overlay-scrollbars that would be wonderful. As I managed to disable them (when glade was crashing) and can't seem to "re-enable" them any more.
<seb128> xnox, did you export OVERLAY_SCROLLBAR=0 or something?
<seb128> LIBOVERLAY_SCROLLBAR=0
<xnox> nope. plus that won't work anymore since it became gtk module instead of pre-load.
<seb128> xnox, otherwise check that overlay-scrollbar and overlay-scrollbar-gtk3 are installed
<xnox> yeap have all 5 of them (i.e. including dbgsymbols)
<seb128> xnox, the first one has a /etc/X11/Xsession.d/81overlay-scrollbar which does append overlay-scrollbar to the gtk loader list
<seb128> xnox, did you hack that to not doit?
<xnox> yeah, that file is still there.
<seb128> echo $GTK_MODULES?
<xnox> $ env | grep GTK_MODULES
<xnox> GTK_MODULES=canberra-gtk-module:canberra-gtk-module:overlay-scrollbar
<seb128> env | grep -i scrollbar
<xnox> seb128: same output, i.e. just in the GTK_MODULES.....
<seb128> xnox, gsettings get org.gnome.desktop.interface ubuntu-overlay-scrollbars
<seb128> (we have too many way to handle those ;-)
<xnox> seb128: was set to false.....
<xnox> seb128: set to true, but restarting apps doesn't make difference. I guess i need to restart a session.
<xnox> seb128: thanks though =)
<xnox> seb128: will see if I have scrollbars tomorrow.
<seb128> xnox, you shouldn't...
<ogra_> seb128, yeah, we should all just move to SuSE ... they just have yast :)
<ogra_> (wrt too many places to configure)
<seb128> haha
<seb128> xnox, but yeah, doesn't seem to pick it dynamically...
<jcastro> xnox: in the future if you dist-upgrade you can just reinstall ubuntu-desktop to get default "stuff" back.
<seb128> jcastro, does that bring back recommends?
<xnox> jcastro: thanks. Apparently I don't have update-manager installed. No wonder using quantal was so peaceful for me =)
<jcastro> seb128: I think there's a flag for recommends?
<jcastro> usually just reinstalling it fixes it up for me, after I shoot myself in the foot anyway...
<seb128> jcastro, yeah, things is when recommends quite uninstalled it's hard to flag if it's because you didn't want them or if that was an error or upgrade issue
<seb128> quite->get
<seb128> jcastro, so they are cases where they will not be reinstalled because they were flagged as something you didn't want
<jcastro> also I'm assuming that whatever conflict is going on in the archive that led him to a partial upgrade be resolved
<mips1911> Hi, where can I get a 12.10 netinstall cd image?
<directhex> http://archive.ubuntu.com/ubuntu/dists/quantal/main/installer-amd64/current/images/netboot/mini.iso ?
<cjwatson> mips1911: http://cdimage.ubuntu.com/netboot/ has an index
<jamespage> slangasek, I appear to be struggling to reproduce the issue with iscsi root boot that I saw during alpha-3...
<mips1911> cjwatson, thanks I found it via http://iso.qa.ubuntu.com/qatracker/milestones/219/builds
<slangasek> jamespage: well, ok then :)
<jamespage> slangasek, hmm - maybe not - I just added another comment to the bug which seems to relate to when I see the problem
<jamespage> bug 1028458 for reference
<ubottu> Launchpad bug 1028458 in plymouth (Ubuntu) "iSCSI root based servers appear to fail to boot completely" [High,New] https://launchpad.net/bugs/1028458
<slangasek> jamespage: oh, hah; then you're seeing bug ##1038055
<jamespage> slangasek, certainly seems a little more reliable when i switch cirrus -.> vga
<slangasek> jamespage: a little more reliable, or completely reliable? :)
<jamespage> slangasek, rebooting lots to see
<jamespage> slangasek, OK - I'd go with completely reliable for my small set of reboot tests (~10)
<jamespage> slangasek, not sure why I'm seeing a splash screen at-all - I thought that was disabled for server?
<slangasek> jamespage: I'm afraid I don't know the answer to that
 * jamespage puts that on his list
<slangasek> cjwatson: ^^ do you know what the server install is currently supposed to be doing wrt splash screens?
<jamespage> certainly not like that for 12.04
<slangasek> could be a regression introduced by the squashfs work
<mips1911> which would be the best mirror to use for a 12.10 netinstall?
<mips1911> I'm getting a no kernel modules found error from the installer?
<mips1911> ok, seems like the US mirror works while some others don't
<xnox> mips1911: archive.ubuntu.com should always have the latest/greatest
<xnox> mips1911: it's best to run your own local mirror though.
<mips1911> xnox, I always thought it might be the UK one seeing that's where canonical is 'located'. Anyway the 12.10 mini.iso netinstall seems to be doing it's thing now, only at 6% though.
<mips1911> xnox, my own local mirror ZA & the UK one would not work with the net install
<zul> mterry:  ping sorry to bug you again but can you have a look at the MIR for python-quantumclient as well
<xnox> mips1911: local as in the one you created yourself on the local network by mirroing / proxying the good mirror e.g. archive.ubuntu.com.
<xnox> mips1911: https://launchpad.net/ubuntu/+archivemirrors
<xnox> will tell the status for each distro release series. Many mirrors have $dev release behind or not at all.
<xnox> mips1911: so https://launchpad.net/ubuntu/+mirror/ftp.wa.co.za-archive should work fine.
<mips1911> xnox, meant local = country ZA
<mterry> zul, yeah
<zul> cool thanks
<xnox> mips1911: sorry. yeah =) check launchpad for the correct & up to date onces.
<mips1911> xnox, thanks but I will just stick to the main one from now on. I'm on a slow link anyway and get no speed difference between the mirrors
<mips1911> Are the packages in the 4.10 PPA newer than those in the Quantal repos?
<mips1911> Ignore that question, wrong channel. Sorry.
<pcarrier> hey
<pcarrier> any chance I could remove a binary package from a PPA? it got superseded
<mips1911> hi
<trism> pcarrier: in your ppa? on your ppa page, go to package details, then delete packages
<pcarrier> trism: ooh, good point, just forgot to login :D
<pcarrier> trism++
<pcarrier> hmmm contents files would be nice :)
<mips1911> Is it possible to continue a netinstall that got interrupted? ie use the existing files on the hdd?
<pcarrier> mips1911: depends on when it was interrupted, but probably a bad idea
<mips1911> pcarrier, towards the end, it was busy downloading linux-image-extre-3.5.0-13-generic
<pcarrier> mips1911: in the middle of package downloads? nah, not worth the effort
<mips1911> pcarrier, no it was towards the end where most of the packages were installed and then it did a update to apt and had twelve packages to update
<jtaylor> mips1911: is the download the bottleneck or the installation? the latter can be speed up ~factor 5 by preloading eatmydata
<pcarrier> mips1911: if it's a VM, you use a caching mirror, at worth on the hypervisors... in case it happens again
<pcarrier> mips1911: then sure
<mips1911> pcarrier, so if I reboot with the install media ho do i continue?
<pcarrier> mips1911: not sure of the order in which things happen. did grub install?
<pcarrier> mips1911: already created your first user?
<mips1911> pcarrier, no grub install but was asked particulars for user
<pcarrier> mips1911: so mount your system in a chroot, bind mount /{proc,dev,sys}, dpkg-reconfigure grub2
<pcarrier> mips1911: check that the user exists and is in the adm group with 'id $username'
<pcarrier> mips1911: last 2 operations from the chroot
<pcarrier> mips1911: oh, and that's not the right channel (topic).
<mips1911> is it not possible to continue in rescue mode?
<pcarrier> mips1911: if you have a complete system, a bootloader and a user to log as, the rest can be fixed from the virtual machine
<mips1911> pcarrier, thanks will give it a bash
<pcarrier> oooh quantal has linux-image-extras generic. now I wonder what's in there.
<pcarrier> Q: when dput'ing into a ppa, looks like debian/changelog is used to establish which distro to build for. is there a magical way to use the same source package for multiple ones?
<jtaylor> no
<jtaylor> but often you can just copy packages to other series
<pcarrier> jtaylor: ok. that'd probably feel a bit too wrong
<pcarrier> another question :) is there a trick to build source packages without .git/? (I've used debuild -S so far which doesn't seem to offer such an option)
<jtaylor> source format 3 should automatically ignore vcs folders
<pcarrier> oooh, good, thanks
<pcarrier> learning every day he he
<pcarrier> last place I would have thought of
<pcarrier> and maybe a last one for the road... anyone knows a way to make git rebases friendly to debian/changelog? i'm getting a bit annoyed by those conflicts
<pcarrier> oh my, thank you google. http://raphaelhertzog.com/2009/10/08/3-way-merge-of-debian-changelog-files/
<pcarrier> superseded by dpkg-mergechangelogs in dpkg-dev
<jtaylor> there is a changelog merge driver for git
<pcarrier> jtaylor: yup, just saw that. pretty awesome :)
<cnd> I'm running into a stupid libtool error: when I run autogen, which runs gnome-autogen.sh under the covers, then make, I get:
<cnd> libtool: Version mismatch error.  This is libtool 2.4 Debian-2.4-2ubuntu1, but the
<cnd> libtool: definition of this LT_INIT comes from libtool 2.4.2.
<cnd> libtool: You should recreate aclocal.m4 with macros from libtool 2.4 Debian-2.4-2ubuntu1
<cnd> libtool: and run autoconf again.
<cnd> I've tried everything I can think of
<cnd> autoreconf -vfi
<cnd> various incantations of all the autotools scripts
<cnd> but nothing seems to work
<roaksoax> cjwatson: howdy! around or still on holidays?
<BenC> Laney: haskell-cryptocipher successfully built on powerpc with the new ghc
<Laney> yay
<Laney> you should be able to give your way back up the stack
<iulian> \o/
<BenC> Laney: what's the best way to handle that so I do it in the right order?
<Laney> I doubt you'll be able to get it wrong
<Laney> you'll just get more failures
<Laney> but start at the lowest level on http://people.canonical.com/~ubuntu-archive/transitions/ghc.html and work upwards
<Laney> they should all be give-backs; no uploading required
<BenC> Laney: lowest being lowest number, or lowest on the page?
<Laney> number
<BenC> Great, thanks
<BenC> Laney: how is a give-back done without an upload?
<Laney> it means to retry a failed build
<BenC> Everything I see in "X" on there is already builtâ¦not ftbfs, so I can't do retry
<Laney> you only have to do the reverse-depends of cryptocipher
<BenC> Does that just mean skew between the page and actual builds?
<Laney> as those are the ones that you would have just fixed
<Laney> so cross-check it with the other ftbfs list
<Laney> BenC: https://launchpad.net/ubuntu/+source/haskell-cprng-aes/0.2.3-3build1/+build/3744085 is one example
<BenC> Yeah, I realized I only need to look at things higher than cryptocipher :)
<BenC> Laney: Ok, I have a chain of 6 packages I'm working and watching for give-backs
<Laney> sweet
<Laney> now I just have to look at arm
<cjwatson> slangasek: server/splash> I believe things are meant to be arranged such that plymouth uses the "details" splash, i.e. displays boot messages in text style - if that's not happening it's definitely a bug
<cjwatson> roaksoax: please leave a message
<cjwatson> roaksoax: much better to say what you want directly rather than doing the ping/pong thing
<bjf> cjwatson: the issue i spoke of the other days is bug 1046029 (just fyi)
<ubottu> Launchpad bug 1046029 in debian-installer (Ubuntu) "Network device not configured correctly" [Undecided,New] https://launchpad.net/bugs/1046029
<roaksoax> cjwatson: ehe sorry :). Well I was just trying to try the live-installer with the squashfs image but I kept seen a failure apparently related to lack of memory
<roaksoax> cjwatson: i will provide logs tomorrow as i'm EOD right now
<roaksoax> cjwatson: other than that, I was wondering if you will make the server squashfs image available on archive.ubuntu.com or will it just stay inside the iso
<cjwatson> roaksoax: Certainly not archive.ubuntu.com - it's not produced by any machinery that feeds into there
<cjwatson> roaksoax: I'd rather just publish the ISO and let people worry about unpacking it if they have special needs, since they're going to need other bits of the ISO anyway
<slangasek> cjwatson: right, and 'details' is the one you get by not passing 'splash' as a boot arg; so seems something's setting up the boot args wrong
<cjwatson> Will add to the queue - what's the bug#?
#ubuntu-devel 2012-09-05
<cjwatson> jamespage: you're touched-it-last on r-base - mind if I merge it?  no desperate rush but I have a change to make to it and might as well bring it up to date at the same time
<ikepanhc> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Beta Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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: ikepanhc
<jdstrand> bdmurray, Riddell: hey, so I am rejecting 2.5.1-0ubuntu5 because bdmurray's 2.5.1-0ubuntu6 includes it and I am rejecting 2.5.1-0ubuntu6 because my 2.5.1-0ubuntu7 will include both 2.5.1-0ubuntu5 and 2.5.1-0ubuntu6
<pitti> Good morning
<RAOF> Hey pitti!
<ajmitch> morning pitti
<pitti> Riddell: it's not that bad -- lp:apport for trunk, and Vcs-Bzr: for packaging
<pitti> RAOF, ajmitch: hello to downunder!
<pitti> Riddell: applied your patch to trunk, thanks!
<cc11rocks> Hello guys. My first Debian patch went through :D >> http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libxml-csv-perl.git;a=commitdiff;h=c934802
<jk-> ^5
<cc11rocks> ?
<RAOF> (High five)
<jk-> yep
<pitti> bdmurray, jdstrand: can you please commit your apport changes in http://launchpadlibrarian.net/114828232/apport_2.5.1-0ubuntu7_source.changes to the Vcs-Bzr: branch?
<jk-> I guess you could XOR with 5 instead, but not sure that really conveys the same sense of congratulations.
<cc11rocks> Thank you :)
<dholbach> good morning
<didrocks> hey dholbach :)
<dholbach> salut didrocks
<sivang> anbyody knows florian's email? the guy who does qml ?
<pitti> sivang: https://launchpad.net/~fboucault :)
<sivang> pitti: yep, thanks :)
<sivang> pitti: how are things , long time ..
<pitti> sivang: quite well, thanks! and yourself?
<sivang> pitti: doing quite well as well, following with interest Ubuntu / Linaro and Canonical's use of Qt.
<jamespage> cjwatson, merge away!
<cjwatson> jamespage: thanks
<cjwatson> hm - actually, it might be a sync
<cjwatson> I'll do some test-builds to check
<cjwatson> Or I would if porter-armhf weren't apparently down.  Is there a usable armhf porter box somewhere?
<cjwatson> Oh, but Adam's argument in the Debian bug that it's daft to use a substring match to detect if you're on an architecture where substring matching is broken is kind of compelling
<pitti> cjwatson: I can do a test build of something on my Panda board, if you need me (or give you ssh on it)
<cjwatson> I've decided against for now, but thanks
 * sivang has a Pi
 * tsdgeos is confused his public bug was marked as duplicate of a private one 
<tsdgeos> how am i supposed to verify the duplicate status is correct? :D
<cjwatson> Sounds unintentional.  Contact whoever duplicated it and ask them.
<tsdgeos> i can't :D
<tsdgeos> it's a bot ;)
<tjaalton> tsdgeos: what was your bug
<tjaalton> bug #
<tsdgeos> https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1046187
<ubottu> Error: Bug #1046187 is a duplicate of bug #1045755, but it is private (https://launchpad.net/bugs/1045755)
<tsdgeos> see ubottu agrees with me this shouldn't happen :D
<tjaalton> don't see why the other bug should be privat
<tjaalton> e
<iulian> That's a bit strange. I guess the bot needs to be taught not to do this again.
<tsdgeos> tjaalton: thanks for making it public
<tsdgeos> anyone else getting bzr qdiff on an dir without changes corrupting unity/compiz ?
<pitti> tseliot: hey Alberto, how are you?
<tseliot> pitti: hey Martin, I'm fine, thanks. You?
<pitti> tseliot: I'm fine, thanks!
<pitti> tseliot: I wondered if you knew whether ubuntu-drivers-common needs any change/fix for bug 1026518?
<ubottu> Launchpad bug 1026518 in ubuntu-drivers-common (Ubuntu) "Add support for the Cedarview graphics driver" [High,Incomplete] https://launchpad.net/bugs/1026518
<pitti> AFAICS this should be a matter of packaging the driver only, but I'd rather get your confirmation before I invalidate it
<tseliot> pitti: I don't think we'll ever have that package in Quantal or higher
<pitti> tseliot: ah, ok; so it's moot either way; thanks!
<tseliot> pitti: ;)
<dholbach> can somebody please reject https://code.launchpad.net/~bmanojkumar/ubuntu/quantal/bygfoot/typo-fix/+merge/122384?
<pitti> <jedi wave> gone!
<pitti> dholbach: ^
<dholbach> thanks
<iulian> Hah. Nice move.
<ikepanhc> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Beta Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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:
<cjwatson> Ooh ooh they added a GDB stub to GRUB
<cjwatson> Fantastic, that might make serial debugging moderately fun
<BenC__> Laney: I've kicked off all the rebuilds pre-depending on cryptocipher. What's the deal with haskell-{gtk,webkit,pango}? Are you doing rebuilds of those?
<Laney> BenC__: what's the problem there?
<Laney> I don't see them on the tracker page
<BenC> Laney: things like hbro, the builds logs show it can't install those packages (bad deps)
<Laney> oh, so they were probably bad when that build was tried
<Laney> should be OK now if the tracker doesn't show them as being bad
<Laney> (in other words, please do a test build and if it works then give-back)
<BenC> Ok
<Laney> we should remove the OODs on armel/hf
<mpt_> dpm, have you seen <http://www.reddit.com/r/Ubuntu/comments/zdyrh/i_want_to_add_marathi_language_translations_to/>?
<dpm> hi mpt, I hadn't seen it, but the poster has just sent me an e-mail. Thanks for the heads up!
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Beta Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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: mdeslaur
<BenC> Laney: haskell-haddock looks like it needs an actual rebuildâ¦want me to upload?
<Laney> BenC: sure, feel free
<Laney> -dpkg needs looking at too
<Laney> BenC: and likely haskell-hint can have its arch restrictions relaxed (could you test build that on ppc?)
<BenC> Sure thing
<sabdfl> hi folks, who's the best person to speak with about apparmor config for bind?
<BenC> sabdfl: Hey
<BenC> Laney: Looks like ghc-mtl needs rebuild too, is that safe?
<sabdfl> hi benc
<mdeslaur> sabdfl: jdstrand or jjohansen
<Laney> BenC: no choice, if it's uninstallable it must be done
<Laney> i'm looking at silently and ghc-syb-utils right now
<Laney> woe is ghc's random changing of ABI hashes; at least it's relatively small
<BenC> Laney: ok, so I've uploaded haddock, gtk-mtl and haskell-dpkg
<Laney> BenC: great. My only concern is that haskell-dpkg possibly should have been re-merged from Debian instead
<BenC> Laney: Going to do a local build of ghc-mtl (*ghc-mtl above) to test hint build on ppc
<Laney> to be updated to cope with the interface changes that were introduced vs. our early dpkg with MA
<BenC> Laney: Ah, well, on that one I didn't do a *buildX, I left it *ubuntuX
<Laney> probably it can just be synced
<Laney> BenC: iulian is looking at that one, so no worries
<sabdfl> ah, found what i was looking for, thank you guys
<BenC> Laney: I did a give-back for clientsession on ppc that should kick all of the yesod related dep-waits
<BenC> That should clear out most of the ppc stuff
<bdrung> dholbach: should packaging-dev recommend ubuntu-packaging-guide or ubuntu-packaging-guide-html?
<BenC> Laney: any idea why haskell-type-level is only built on x86 and the control file says arch-any? is there a build override for it?
<cjwatson> BenC: Yep, it's in Packages-arch-specific
<cjwatson> Ah, but not in Debian
<cjwatson> Let me merge that ...
<cjwatson> Oh, Laney already did
<cjwatson> BenC: Should sort itself out next time it's uploaded
<BenC> Same with haskell-syb-with-class
<BenC> cjwatson: So if I do a build-only upload, it will get built now?
<cjwatson> Yeah
<BenC> Thanks
<cjwatson> And likewise for haskell-syb-with-class
<cjwatson> And haskell-debian (if that's in that state too)
<BenC> cjwatson: Any quick way to check haskell-* in general on that list?
<cjwatson> lp:~ubuntu-core-dev/packages-arch-specific/ubuntu
<BenC> I'm not sure if it's annotated for anything related to ghci, but powerpc at least has ghci now
<cjwatson> Laney removed haskell-* from it in r155
<BenC> Ah, thanks
<BenC> Laney: I did uploads of syb-with-class and type-level to get non-x86 builds going
<BenC> That should kick in a few more dep-waits
<BenC> I'll let things settle till tomorrow
<iulian> BenC: I've rejected -dpkg and sync'd it instead.
<BenC> iulian: I saw, thanks
<jdstrand> pitti: done
<jdstrand> bdmurray: I committed your change to apport too
<pitti> jdstrand: thanks; I'll commit that to trunk, too
<jdstrand> cool, thanks
<pitti> jdstrand: hm, shouldn't it export the newly set PATH as well?
<jdstrand> that is a good question
 * jdstrand checks
<jdstrand> pitti: it doesn't seem so, but I am reading. I think I may want an additional change anyway
<dholbach> bdrung, ubuntu-packaging-guide should be good enough
 * dholbach hugs mdeslaur
 * mdeslaur hugs dholbach back
<iulian> dholbach,bdrung: What about Suggests instead of Recommends? Do we really want to pull in the tex* packages when we install packaging-dev?
<dholbach> iulian, tex* packages are build-depends, not depends
<iulian> Oh, right.
<dholbach> :)
<iulian> dholbach: Yea, you'd have to ignore me from time to time, especially when I say stupid things like this. :)
<dholbach> not going to happen :)
 * dholbach hugs iulian
 * iulian hugs dholbach back.
<mterry> slangasek, do you know the answer to tedg's question about selinux at the end of bug 1039636?
<ubottu> Launchpad bug 1039636 in lightdm-remote-session-freerdp (Ubuntu) "[MIR] lightdm-remote-session-freerdp" [Undecided,In progress] https://launchpad.net/bugs/1039636
<bdrung> dholbach: ok, done. packaging-dev 0.5 is uploading.
<dholbach> perfect!
<dholbach> thanks a bunch
<bdrung> dholbach: yw. now to the plan of having the packaging guide in Debian. who should be the maintainer and where will the source branch be?
<dholbach> lp:ubuntu-packaging-guide - up until now it was just "Ubuntu Developers <ubuntu-devel-discuss@...>"
<jdstrand> pitti: ok, updated. I am using export just to be sure, and also unsetting ENV and CDPATH, also to be sure
<bdrung> dholbach: how about using http://qa.debian.org/developer.php?login=ubuntu-dev-team@lists.alioth.debian.org as maintainer?
<dholbach> bdrung, that'd be perfect
<bdrung> this is more specific than just ubuntu-devel-discuss
<bdrung> dholbach: http://paste.ubuntu.com/1187298/
<dholbach> perfect
<bdrung> dholbach: http://paste.ubuntu.com/1187303/
<bdrung> i should save the changed file.
<bdrung> dholbach: http://paste.ubuntu.com/1187304/
<dholbach> great, all Is dotted and Ts crossed :)
<bdrung> dholbach: committed. should i upload the current revision to debian as version 0.2.3?
<dholbach> bdrung, it'd be nice if we could get in the 'bug fixing example' article still
<dholbach> I made the changes you asked for in the MP
<bdrung> dholbach: okay. just ping me once it is ready for upload.
<bdrung> dholbach: i will look at the MP later.
 * dholbach hugs bdrung
<dholbach> thanks a bunch
<slangasek> mterry, supporting selinux for this service is definitely a "should" rather than a "must"
<mterry> slangasek, OK, so you're fine with it is as in terms of MIR?
<slangasek> mterry: yes.  would you mind filing a bug about the missing selinux handling?
<mterry> slangasek, sure
<Quintasan> mhall119: ping
<mhall119> Quintasan: pong
<Quintasan> mhall119: Do you happen to know if all sponsorship requests have been answered already?
<mhall119> Quintasan: they've been mailed, but it seems a lot of them have been flagged as spam
<mhall119> some going into spam folders, some never reaching their destination
<Quintasan> mhall119: I think I belong to the latter, nothing in spam and nothing in inbox either.
<Quintasan> mhall119: Should I wait for it to get sorted out or email Marianne?
<mhall119> Quintasan: I'd wait, she's working on sorting it out
<Quintasan> Okay
 * Quintasan stocks on patience
<tsdgeos> seb128: should https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1018896 be marked as Fix Released in "nautilus (Ubuntu)" too?
<ubottu> Launchpad bug 1018896 in nautilus (Ubuntu Quantal) "nautilus crashed with SIGSEGV in gtk_ui_manager_new_merge_id()" [High,Confirmed]
<seb128> tsdgeos, likely set to invalid for nautilus
<seb128> since it was a gtk issue
<tsdgeos> seb128: ok, want me to do it?
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Beta Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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:
<herton> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Beta Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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: herton
<smoser> i'm interested in hearing ideas on https://bugs.launchpad.net/ubuntu/+source/hostname/+bug/1046405
<ubottu> Launchpad bug 1046405 in hostname (Ubuntu) "hostname.conf should prefer kernel cmdline 'hostname=' to contents of /etc/hostname" [Undecided,New]
<tkamppeter> slangasek, hi
<achiang> herton: hi, was wondering if you could take a look at #1046102
<herton> achiang, sorry, I can only look into kernel bugs
<achiang> herton: oh, ok. thanks.
<micahg> achiang: looking
<achiang> micahg: thanks
<micahg> achiang: is it critical for beta 1?
<achiang> micahg: upstream would like very much to see it in quantal as it fixes quite a bunch of bugs and enables new hardware. i don't know how that matches up with "critical for beta1" though... if we miss beta1, can it go in later?
<smoser> cjwatson, or slangasek would you have comments on my 'hostname' suggestion above?
<micahg> achiang: yeah, just not sure if it needs an FFe or not and would prefer not to bother the release team with it until after beta 1
<achiang> micahg: as long as it gets into the final release, i'm ok with it. :)
<slangasek> smoser: adds complexity, will slow down the boot for all users, and I don't understand why you would have a shared read-only filesystem for multiple netbooted systems?
<achiang> micahg: i can fill out more paperwork if needed, but unsure what my required next steps are
<smoser> its readonly iscsi root.
<slangasek> ok, but I don't understand why
<slangasek> why would someone do that?
<slangasek> tkamppeter: hi
<smoser> its an "ephemeral boot environment" .  a way to deliver a working environment to a node without modifying disk content (or making assumption of the contents).
<smoser> it uses overlayfs to write delta elsewhere (we're just wrigint to tmpfs)
<smoser> and i disagree with "slow down boot".
<slangasek> er
<slangasek> it does slow down boot
<slangasek> you're adding an extra shell invocation
<smoser> for the cost of my 'read < /proc/cmdline' i will go find you 6 different forks that will take 1000s of times longer.
<slangasek> every one of which contributes to slowing down the boot; this is part of why boot speed has been regressing over time
<slangasek> no, the fork you've added here *is* the cost
<slangasek> I don't think this belongs in the stock system
<smoser> this is fair. it does add a fork.
<smoser> i really dont think boot speed alone is reason to nak it.
<smoser> honestly, i assure you i can probably remove 5 forks in the next 30 minutes if you want me to.
<slangasek> When you're proposing a change to the base system, it is.  There should be other ways to implement this without modifying the common path - a separate package installed only in the ephemeral environment?
<smoser> well, yes. and we could just write another job that runs on stopped hostname (or stopping or something).
<slangasek> that would IMHO be better
<tkamppeter> slangasek, it is about your invitation. Do I need a Google+ account for it? And who at Canonical is supposed to have a Panda board, I do not have one.
<slangasek> tkamppeter: you need a G+ account to participate in the live hangout, but your attendance is certainly not required (and the video will be posted afterwards on youtube for all to see).  A number of Pandas have been distributed to the Desktop team, I don't know exactly who has one or doesn't so I just invited a bunch of people
<smoser> thanks for the input, slangasek . i dont disagree, but i really, *really* dont think boot speed alone is reason.
<smoser> as a gesture of good will http://paste.ubuntu.com/1187592/
<smoser> theres 1 removal of a fork.
<tkamppeter> slangasek, I did not get one, probably they got distributed in the short time when I got moved to Product Strategy.
<smoser> http://paste.ubuntu.com/1187594/ and theres a benchmark showing my path is significantly faster.
<smoser> thanks.
<slangasek> smoser: I appreciate the help with optimizing some of the other cruft, I'll see about getting that one into quantal.  But we are sufficiently far off the mark on boot speed that I am still going to push back on changes that slow down the common path
<smoser> no worries.
<smoser> i agree, i can sufficiently do it outside of 'core' so it makes sense to do it there.
<smoser> slangasek, fwiw, if you're wanting to save forks, the initramfs is chock FULL of them.
<slangasek> smoser: well, I want us to be able to eliminate the initramfs entirely for the common path ;)
<slangasek> but the kernel team has not been accomodating!
<smoser> i thought you said quantal
<smoser> :)
<smoser> and yeah, i knew that was a goal.
<smoser> slangasek, so, i'd appreciate your thoughts on another issue i have.
<smoser> its related to bug 1031065 (or at least related to our 'start networking' hack that was added).
<ubottu> Launchpad bug 1031065 in cloud-init (Ubuntu) "cloud-init-nonet runs 'start networking' explicitly" [Medium,Confirmed] https://launchpad.net/bugs/1031065
<smoser> rbasak is hitting (consistently) a condition where cloud-init-nonet never gets stopped. as if it blocking (start on mounted MOUNTPOINT=/) is stopping the interface from coming up.
<slangasek> smoser: so wrt that bug, I asked you a couple weeks back for some verbose upstart syslog output, which you said you were going to get me "in a bit" :)
<smoser> i can get that to you now if you'd like. but i was confused by "syslog" comment.
<smoser> what did you mean by syslog
<slangasek> smoser: upstart logs to kmsg, which is supposed to wind up in syslog
<slangasek> (in practice, this seems to be broken in quantal for reasons I don't yet understand)
<smoser> ok. well i'll get that to you reall y quick.
<slangasek> /var/log/kern.log, if it works; dmesg output, if it doesn't
<smoser> hm..
<smoser> well, dmesg wont have init output
<smoser> which is what you really need and kern.log wont have it either (since htis is lxc)
<slangasek> why won't dmesg have init output?
<smoser> https://pastebin.canonical.com/73830/ is rbasak's collection on his arm system.
<smoser> the lxc containe'rs init output would find its way into dmesg?
<slangasek> I would hope that it would go somewhere :)
<slangasek> it's supposed to be logged with kmsg
<smoser> i ran into an issue when trying to collect init output on lxc that i raised with hallyn.  ideally it'd go to stdout and i could just log it.
<smoser> but it seems to not.
<smoser> anyway. i'll see what i can get.
<slangasek> smoser: what is /dev/kmsg within the lxc container?
<smoser> and rbasak's data there is unfortunately slightly confusing as its intermixed output.
<smoser> i'll see what i can find slangasek
<slangasek> if it isn't already, you can set it up to be a link to the controlling tty the same way that /dev/console is
<slangasek> smoser: the other consideration is that I was assuming lxc init worked the same way as a chrooted init, which sounds like it's not actually the case
<slangasek> smoser: so you probably need to pass --verbose when starting init
<smoser> yeah, i hoped it did. it did not.
<slangasek> smoser: oh - in any case, that pastebin looks like exactly the kind of info I was looking for (the init: lines)
<smoser> but chrooted init ?
<slangasek> in a chroot you don't actually run a separate init, and jobs just talk to pid 1
<slangasek> and pid 1 keeps track of whether a job is in a chroot or not
<stgraber> slangasek: lxc containers work like "regular" Ubuntu systems, so they have /sbin/init running as the pid 1 of their PID namespace
<slangasek> yep
<slangasek> stgraber: I understand that once I thought it through :)
<smoser> so yeah, i tried passing --verbose. but i only get output to my console that goes explicitly to /dev/console (ie, task output from cloud-init getst there).
<slangasek> stgraber: and does /dev/kmsg get pointed somewhere useful?
<slangasek> smoser: well, the pastebin from rbasak shows exactly the kind of information I'm looking for
<slangasek> so... do whatever he did? :)
<smoser> well, he got console output from a real system.
<smoser> ie, serial console output
<smoser> i dont havaccess to that.
<slangasek> ok
<slangasek> smoser: so, fixing /dev/kmsg within the container should do the trick
<smoser> how would i fix? youhave a solution for that?
<slangasek> smoser: "make it match /dev/console"
<slangasek> I know /dev/console is magically pointed at the controlling tty from the host; I don't know how this is done.  But the same should be done for /dev/kmsg
<smoser> slangsek. that was impressive.
<smoser> ln -sf console kmsg
<smoser> and poof! data!
<stgraber> apparently /dev/kmsg doesn't actually exist at boot time, I seem to have containers where it's a simple text file (instead of char device), probably because something tried to directly write to it without checking whether it existed first...
<slangasek> smoser: right, I was going to suggest that ;)
<stgraber> hallyn: ^
<slangasek> stgraber: current upstart calls mknod first if it doesn't exist, fwiw
<stgraber> slangasek: how current? I checked in 12.04 containers here
<stgraber> (though maybe something created /dev/kmsg as a file before upstart had a chance to mknod it)
<slangasek> stgraber: upstart 1.5-0ubuntu8 - this is a fix that jodh is planning to SRU to precise soon-ish
<smoser> http://paste.ubuntu.com/1187658/
<stgraber> ah, ok, well once that lands, and if /dev/kmsg is allowed in the container, it's going to get in the kernel log buffer
<stgraber> problem is that at this point it's shared between the host and containers (until we have a syslog namespace)
<slangasek> smoser: great :) so is this one with the original cloud-init-nonet job, or the one modified to not call networking start?
<hallyn> stgraber: still waiting for syslog ns to be bumped in priority :)
<smoser> that is a precise container (from latest daily build) with 'start networking' commented out
<smoser> (showing the hang)
<slangasek> smoser: ok, great
<smoser> slangasek, http://paste.ubuntu.com/1187672/ is with mountall --verbose
<smoser> yeah, and that shows the issue there i think
<smoser>  /run gets mounted after cloud-init-nonet starts
<smoser> meaning virtual-filesystems can't be emitted
<smoser> meaning udev cant start
<smoser> this is a different problem then rbasak saw. as he does get virtual-filesystems emitted before cloud-init
<smoser> so maybe there goes my hopes of it being the same root cause.
<bryce> slangasek, ogasawara, hey question came up from NVIDIA...  if a user grabs the 12.04.3 ISO and installs it, is there any option or text in the installer that mentions they have the option of installing the 12.04.0 iso as an alternative?  IOW how are we messaging the existence of 12.04.0 to end users?
<slangasek> bryce: I would expect this to only be messaged via the web page documentation, not on the image itself; and why does it make me nervous that nvidia cares about this? :)
<bryce> slangasek, web page documentation == release notes?  or the cdimage site? or...?
<ogasawara> bryce: there were discussions about providing an option on the DVD's to install with the original 12.04 stack, but we did not reach a decision there yet.  otherwise I assumed it was as slangasek noted above.
<slangasek> bryce: release notes + help.u.c, I think
<bryce> ok
<bryce> hmm, not seeing mention of it on help.u.c.  http://www.ubuntu.com/download/desktop looks like it ought to link to it but not finding mention or link there either
<slangasek> bryce: right, I don't think there's anything there *currently*; we also don't have a point release out yet that includes a backported stack so there's no actual need
<slangasek> bryce: also, I imagine we should be messaging 12.04.1 rather than 12.04.0
<bryce> ok
<bryce> slangasek, ok, so it's in the plans for including those links and/or messaging?  That should suffice for this.
<slangasek> ogasawara: can that go in the plan then? :)
<bryce> ogasawara, thanks.  Might be worth stimulating that discussion again.
<ogasawara> bryce, slangasek: I post this to the thread I sent to ubuntu-devel
<bryce> ogasawara, thanks
<smoser> slangasek, so i'm remembering more and more bits and pieces of this.
<smoser> the issue i ran into when using overlayfs was that i wasn't mounting / as 'ro'.
<smoser> which cauased the 'mounted MOUNTPOINT=/' to occur before /run was mounted
<smoser> which is the same scenario as my lxc i think
<smoser> but this is very much not the case that rbasak was running into (from ihis log output).
<slangasek> smoser: hmm, I'm puzzled as to the stated cause of / being mounted before /run; I'll have to look at the mountall code
<smoser> slangasek, well, that is admittedly "my fault"
<smoser> here.
<smoser> see cloud-init upstart jobs
<smoser> /usr/share/lxc/hooks/mountcgroups
<smoser> err...
<smoser> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/cloud-init/quantal/files/head:/upstart/
<slangasek> smoser: ah, it's because mountall first scans for all filesystems that don't require further processing and reports them mounted
<smoser> cloud-init-nonet runs on 'mounted MOUNTPOINT=/ and stopped cloud-init-local' and mounted MOUNTPOINT=/ blocks
<smoser> which stops the /run from ever being ounted, so udev cant start
<slangasek> ah
<smoser> so networking can't come up
<slangasek> so, why do you want mounted MOUNTPOINT=/ there?
<smoser> because i want to block boot
<slangasek> ah right
<smoser> in order to allow people the earliest entry point into the boot
<smoser> in "normal boot", /run gets mounted before / gets mounted RW
<slangasek> and if mounted MOUNTPOINT=/ happened after /run was mounted, would that solve your problem?
<slangasek> (and remove the need for manually starting networking?)
<smoser> i think so. i was trying to just see if i could get lxc to do that, but didn't see how.
<smoser> i would still have rbasaks' problem, which i think is not the same.
<smoser> because his log shows 'virtual-filesystems' running before cloud-init (which would mean /run was mounted)
<slangasek> if / were mounted ro initially, that would trigger the correct ordering
<smoser> it *does* trigger that, but that might just be happenstance.
<slangasek> no, it's not
<smoser> yeah, with what you ssaid above.
<slangasek> I'm suggesting that as a solution for the lxc case - are you saying you can't get it to be mounted ro for lxc?
<smoser> hallyn, ^
<smoser> that is what i was asking him.
<slangasek> ok
<smoser> honestly, it seems to me like if you're invoking /sbin/init its a bug to by default mount rw
<smoser> at least possibly
<hallyn> smoser: i wouldn't want to count on initramfs always leaving / ro
<hallyn> especially in fancy raid situations
<hallyn> but if jodh says it's so, i'll accept it as a bug (in ubuntu, probably not in upstream lxc)
<slangasek> hallyn: it darn well better leave it ro
<slangasek> (the initramfs)
<slangasek> because fsck is only run post-pivot
<slangasek> so yes, this is something we rely on
<hallyn> hm
<smoser> well, yeah, and if the kernel cmdline says 'ro' then it a bug to not be 'ro'
<hallyn> fsck, what's that? :)
 * hallyn makes a note in his journal
<smoser> but, hallyn, lxc is a special case here, because nothing told it 'ro'
<smoser> *and* the case where you run something other than /sbin/init,  you most likely dont want 'ro'
<hallyn> right, and fsck better detect that the fs is mounted and not run.
<hallyn> in most cases, / is just a dir on the host's rootfs,
<hallyn> so actually it can't be ro
<smoser> you can mount bind ro
<slangasek> sure, fsck will detect the case that the fs is mounted rw, but that doesn't help the fact that we actually want the root fs to be fscked ;)
<hallyn> smoser: sort of
<smoser> real men 'ln /sbin/fsck /bin/true'
<hallyn> slangasek: but you don't :)  not when / is just a subdir of /var on the host
<stgraber> is there any reason to boot with / ro other than fsck? because on lxc, the container root is on an fs that's already been checked when the host booted
<slangasek> hallyn: I'm talking about the initramfs case
<slangasek> on real hardware, we have a guarantee that the rootfs is mounted ro when upstart starts
<hallyn> slangasek: oh right
<hallyn> yup
<smoser> hallyn, hm..
<slangasek> lxc deviates from this, so the question is if we can change that or if we need to change mountall
<smoser> i guess the other thing i could do ofr this is tell lxc to mount /run for me
<smoser> before it calls /sbin/init
<smoser> right?
<slangasek> note that I don't actually care if it's mounted ro, I just care that mountall *sees* that it's ro ;)
<slangasek> smoser: nope
<smoser> no?
<slangasek> smoser: because udev needs 'virtual-filesystems' emitted, which is a whole bunch of filesystems, not just /run
<smoser> true.
<smoser> so s/run/all-of-those/
<smoser> but... yeah.
<slangasek> and there's a change to the set of those filesystems staged in the unapproved queue.  not maintainable.
<smoser> well, it could be maintainble.
<smoser> the change you speak of would just have to be tied to a change in lxc that was release aware
<smoser> but , yeah. suck.
<hallyn> ok wel lif we're just trying to fool mountall, then yes we could remount the container / ro (two-step process, but you don't care about that)
<slangasek> that would probably help
<slangasek> though I actually haven't worked out yet that the virtual filesystems are guaranteed to be mounted before /
<slangasek> smoser: so I believe there's a potential race condition for whether / gets mounted before or after virtual-filesystems is emitted, even with this change
<slangasek> smoser: if you haven't run into it yet, then all to the good; but I mention it in case that is happening somewhere
<smoser> its not that i know of.
<smoser> i think imight have hit it once when /dev/pts didn't exist... or something like that.
<smoser> yeah, if root didn't hae a mount point in it that a virtual mount needed
<smoser> i guess if root didn't have /dev
<smoser> but thats somewhat busted anyway
<slangasek> well, root waits for /dev to be mounted, but it doesn't wait for /proc /sys /run /proc/sys/fs/binfmt_misc /sys/fs/fuse/connections /sys/kernel/debug /sys/kernel/security /dev/pts /tmp /run/lock /run/shm, any of whom will block the virtual-filesystems signal
<slangasek> I wonder if fixing bug #643289 would make this better or worse
<ubottu> Launchpad bug 643289 in nfs-utils (Ubuntu Lucid) "idmapd does not starts to work after system reboot" [High,Triaged] https://launchpad.net/bugs/643289
<slangasek> if done right, that would allow the virtual filesystems, which do not block on /, to continue being mounted even while the mounted MOUNTPOINT=/ hook is blocked
<slangasek> so I *think* that makes it better
<slangasek> indeed, it might make it irrelevant whether / is mounted ro in lxc
<smoser> slangasek, well, yeah, sort of better.
<smoser> but that would sort of viorlate my reading of 'mounted'
<slangasek> smoser: note that the change in question would not cause the 'filesystems' event to be emitted before the 'mounted' hook returns
<smoser> mountall(8) will wait for all services started by this event to be running,  all tasks started by this event to have finished and all jobs stopped by this event to be stopped before continuing with other filesystems.
<slangasek> yeah, I know that's what it says
<slangasek> I'm suggesting this is the wrong thing to do ;)
<slangasek> I think it should still continue in parallel with *unrelated* filesysetms
<slangasek> just not with any which depend on the current one
<smoser> well, that woudl defeat a lot of my intent
<slangasek> not really
<slangasek> because the only filesystems that are unrelated to the rootfs, in mountall's view, are the virtual filesystems
<smoser> yeah. and not much starts on virtual-filesystesm alone
<slangasek> except things like udev, which is exactly what we're trying to unblock ;)
<smoser> yeah
<smoser> so yeah, that would fix this case.
<smoser> so i should update this bug with our understanding of it
<smoser> as i failed to do that before, and that resulted in much lost time.
<slangasek> ok, great
<smoser> and while i do that, you can come up with a solution :)
<slangasek> well, there's a proposed patch to mountall that's been sitting for a while
<slangasek> I'll put it on my queue to look at, but I don't think I'm going to get to it this week, and jodh is on vacation
<smoser> slangasek, yeah, thanks for your help
<melodie> hi
<melodie> I try to use the "LiveCDFromScratch" howto, and I would like to get some help to understand or improve the way to use some parts of that page, and I don't know where would a chan with people likely to have the knowledge. Anyone here can give me an advice ? Here is the page and I am at about the middle : https://help.ubuntu.com/community/LiveCDCustomizationFromScratch
<herton> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Beta Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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> slangasek, it would seem to me to be "early enough" (and even ideal) if i could run when virtual filesystems were available and / was mounted.
<smoser> i dont think there is any way to block at such a state though.
<slangasek> smoser: there indeed is not
<slangasek> stokachu: I don't think I understand https://bugs.launchpad.net/ubuntu/+source/libgnome/+bug/977959/comments/6 and https://bugs.launchpad.net/ubuntu/+source/libgnome/+bug/977959/comments/7.  The debdiff you provided doesn't include any changes around dlopen(), which libgnome in fact doesn't use.  But I'm also not sure what "gnome-program" refers to here?
<ubottu> Launchpad bug 977959 in libgnome (Ubuntu Precise) "Please transition libgnome to multi-arch" [Medium,In progress]
<barry> cjwatson: correct me if i'm wrong, but i believe software-properties is now py3
<melodie> hi again
<melodie> is there a chan where I could ask help specifically with some parts of this page ? https://help.ubuntu.com/community/LiveCDCustomizationFromScratch
<cjwatson> barry: believe so
<barry> cjwatson: awesome, that's what i though.  spreadsheet updated
<barry> cjwatson: thx
<cjwatson> barry: buggy #! I notice, though.  must fix that.
<barry> cjwatson: /usr/bin/env lines?
<cjwatson> Was more thinking of #! /usr/bin/python3.2 at the top of add-apt-repository
<cjwatson> Likely needs the same pile of stuff I worked out for germinate to avoid that
<barry> cjwatson: ah, yes.  /usr/bin/python3 i suppose would be better ;)
<cjwatson> Indeed
<barry> jdstrand: ufw is python3 now?
<slangasek> barry: apt-cache show ufw | grep python
<slangasek> :)
<barry> slangasek: yep, just looking for mindless confirmation :)
<melodie> gn
<slangasek> barry: hey, did you ever get a resolution to your vmvga issue in quantal?
<barry> slangasek: nope.  we've had some traffic on the issue today.  i have a workaround, but no fix
<slangasek> drat
<barry> slangasek: or really, understanding of what's wrong
<barry> yeah
<slangasek> barry: I see that qemu actually implements vmvga as one of the options; I was vaguely hoping that this would prove to work with guest acceleration :)
<RAOF> barry: That's the llvmpipe-doesn't-kick-in-under virtualbox, rigth?
<slangasek> but we can't very well test it until we have a driver
<slangasek> RAOF: vmware, not vbox
<barry> RAOF: actually, it's a kernel module no longer getting loaded by default
 * RAOF waves hands. Some sort of virtualisation thingy!
<slangasek> RAOF: also, I'm pretty sure llvmpipe does kick in correctly everywhere, and just fails to be up to the task of lifting unity off the floor?
<RAOF> slangasek: Apparently not; I got assigned a bug last night about llvmpipe not kicking in in some virtualisation thingy.
<barry> yep. llvmpipe does work better now than the day i filed the bug (but still painfully slow on fusion)
<slangasek> RAOF: hmmm, bug #?
 * RAOF wishes evolution wasn't in the process of slowly throttling itself to death
<slangasek> :-)
<RAOF> Hah. It's finished. Now there's an apport popup instead :)
<RAOF> slangasek: Bug #1039155
<ubottu> Launchpad bug 1039155 in nux (Ubuntu) "Unity fails to load on old hardware. Missing automatic fallback to LLVMpipe" [High,Confirmed] https://launchpad.net/bugs/1039155
<RAOF> Urgh. I've just looked at that.
<slangasek> RAOF: isn't https://bugs.launchpad.net/ubuntu/+source/nux/+bug/1039155/comments/8 the real issue?  I've definitely had llvmpipe get used correctly on armhf
<ubottu> Launchpad bug 1039155 in nux (Ubuntu) "Unity fails to load on old hardware. Missing automatic fallback to LLVMpipe" [High,Confirmed]
<slangasek> so I suspect the problem is the user has some other GL driver that's not up to snuff
<RAOF> Possibly.
<RAOF> There's also the case where the user has a mesa GL driver, but it doesn't support what Unity needs; in that case we *do* need to force llvmpipe.
<slangasek> how do you do that effectively?
<slangasek> since the choice of driver is an X server thing as much as a client thing...
<RAOF> Set LIBGL_ALWAYS_SOFTWARE in Unity's environment.
<RAOF> libGL is all client-side; it asks the X server what driver it should be loading, but it's under no compulsion to accept that.
<slangasek> ah
<slangasek> doesn't the server have to load /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so ?  does it do that automatically when a client says the magic word?
<ion> Why should the client care about how the GL implementation renders stuff? :-( Shouldnât the GL implementation choose between hardware acceleration and LLVM-and-CPU transparently in a perfect world?
<RAOF> No; libGL loads swrast_dri.so (or r600_dri.so, or whatever hardware driver is appropriate)
<RAOF> The server *also* loads a dri driver, but that's for AIGLX, which nothing uses anymore.
#ubuntu-devel 2012-09-06
<RAOF> ion: In an ideal world, yes. In the real world different renderers support different GL extensions (or GL versions), and exporting all GL extensions that can be implemented in software is user-hostile.
<slangasek> RAOF: ah, heh.  Thanks for the explanation, I'd completely forgotten the name AIGLX :)
<ion> How about exporting all GL extensions but telling the user which ones are hardware-accelerated?
<RAOF> GL doesn't support that :)
<ion> A Mesa extension? :-P
<slangasek> ion: to what end?  when would you have more than two drivers in practice - one accelerated, one sw?
<slangasek> I think the problem here is some oddball driver loaded that doesn't implement the bits that mesa's in-tree drivers do, no?
<RAOF> That's one possible problem, yes
<slangasek> so even if mesa had awesome support for proxying unsupported extensions over to the llvmpipe swrast driver, that doesn't help if you're not using a mesa driver to begin with, I think
<slangasek> btw, did linaro's gles proxy lib ever manifest?
<slangasek> (which, er, was supposed to handle exactly this sort of thing)
<jdstrand> barry: re ufw> yep, as of 0.32
<pitti> Good morning
<ajmitch> hi pitti
<SpamapS> any reason not to upgrade a precise box to quantal right now?
<micahg> SpamapS: qemu-kvm has some issues
<micahg> libreoffice has no menus in non-unity envs
<SpamapS> yeah I briefly looked at the critical bugs
<SpamapS> just sometimes people say NO WAYT THEARCHIVE IS BZORKEN when I do that ;)
<micahg> SpamapS: the archive is frozen ATM :)
<ahsan> hi all
<ahsan> i wanted to write an upstart job which kicks in just before halt/reboot.
<ahsan> any pointers on how to do that
<ahsan> I tried with "start on runlevel [06]". But, I guess that starts as soon as runlevel 0 or 6 is reached
<RAOF> Right.
<RAOF> At what point in the shutdown process does it need to run? If it's âjust as FOO is shutting downâ, then âstart on stopping $FOOâ would get you something like that.
<ahsan> yeah, i was looking for something like that..
<ahsan> like a S89mytask in rc6.d for sysV
<RAOF> You can of course just have a sysv task if you want; upstart supports it.
<ahsan> RAOF: ok, just wanted to do it the upstart way.
<RAOF> There probably is an event you can start on.
<ahsan> yes, I was looking for that event. like you said "start on stopping foo"
<ahsan> I am looking for that foo
<RAOF> So when does it need to run?
<ahsan> just before the halt/reboot is issued
<SpamapS> ahsan: what exactly do you want it to stop after?
<SpamapS> ahsan: shutdown has a very specific order.. stop services, kill processes, unmount network filesystems, stop networking, kill off straggler processes, unmount filesystems, halt/reboot
<SpamapS> ahsan: for instance, a few things do need to be stopped between unmounting network filesystems, and stopping networking. For those, 'stop on deconfiguring-networking' is a good choice, as it will block the shutdown until those things are stopped.
<SpamapS> ugh, touchpad on MBA 4,1 is not working now
<ahsan> SpamapS: thanks, will give it a try
<ahsan> SpamapS: I wanted to just delete a marker, as late as possible
<cc11rocks> Can I delete a patch sent to Debian?
<SpamapS> ahsan: so you have to do it before filesystems are unmounted
<cc11rocks> I accidentally submitted a duplicate to someone else's fix...
<ahsan> SpamapS: ok, can you please tell the syntax
<ahsan> SpamapS: "start on starting mountall" will be a race condition?
<SpamapS> ahsan: mountall is started during the system boot. I thought you wanted on shutdown
<ahsan> SpamapS: oh, you're right. sorry
<ahsan> SpamapS: btw, when does mountall stops? .. also, which task handles unmounting filesystems?
<SpamapS> ahsan: there's no event, currently, attached to unmounting filesystems, but you could either a) push it back to just before networking is deconfigured, or b) add the event to /etc/init.d/umountfs
<SpamapS> ahsan: mountall never stops IIRC
<SpamapS> ahsan: unmounting is done by /etc/init.d/umountfs
<ahsan> SpamapS: thanks
<ahsan> SpamapS: which event is emitted when networking is disconfigured
<ahsan> ie "start on stopping foo" .. whats foo here? or disconfiguring-network itself is an event which is emitted?
<ahsan> /s/disconfigured/deconfigured
<dholbach> good morning
<dholbach> bdrung, AFAICS ubuntu-packaging-guide is ready for upload :)
<MCR1> didrocks: I noticed some important python applications do not work on Quantal (they all fail with the same error: Gtk-CRITICAL **: IA__gtk_widget_style_get: assertion `GTK_IS_WIDGET (widget)' failed) - who can/should I nerve with this ?
<MCR1> didrocks: examples are qbzr or trimage packages...
<tsdgeos> it happened again, a bug i just reported got duplicated of a private one https://bugs.launchpad.net/ubuntu/+source/colord/+bug/1046690 and https://bugs.launchpad.net/bugs/1038768
<ubottu> Error: Bug #1046690 is a duplicate of bug #1038768, but it is private (https://launchpad.net/bugs/1038768)
<ubottu> Error: malone bug 1038768 not found
<didrocks> MCR1: those are using pygtk or pygi?
<tsdgeos> can someone mark the second public and tell me where i open a bug so that this doesn't happen again?
<MCR1> didrocks: qbzr says it depends on python-qt4, python2.7
<tsdgeos> MCR1: yeah having the same problem :-/
<didrocks> MCR1: ok, are all python applications having this kind of gtk warning qt apps?
<didrocks> I wonder if it's not just the qt -> gtkstyle binding which is broken
<MCR1> didrocks: trimage is also depending on python-qt4 and python >= 2.6
<MCR1> didrocks: I am not sure if all have this kind of warning, but many python applications work, while those 2 don't anymore, while at least trimage was working on Precise
<MCR1> but I guess qbzr also works there...
<MCR1> tsdgeos: Which python applications are creating this problem for you ?
<tsdgeos> MCR1: to be honest i'm only using qbzr
<didrocks> MCR1: so, I would say it's a Qt issue to not work with latest GtkStyle, maybe some people are knowledgeable on #kubuntu-devel
<MCR1> didrocks: ok, I'll ask there. Thx. After all qbzr is a quite important tool for Ubuntu development as there is no real replacement I know of (bzr explorer is slow and buggy)
<tsdgeos> it seems someone decided to break qt on quantal, assistant is also crashing on startup :D
<brendand> does anyone know why i might be seeing:
<brendand> Qt: Session management error: None of the authentication protocols specified are supported
<brendand> in Precise (12.04.1)?
<brendand> i read something about no X server - which couldn't be possible
<cjwatson> barry: http://en.chys.info/2011/11/a-problem-with-pipes-in-python-3/ - gotcha, possibly worth mentioning somewhere.  Note my comment
<cjwatson> Relevant if you do things like  subp = subprocess.Popen(blah, stdout=subprocess.PIPE); for line in subp.stdout:  without universal_newlines=True
<cjwatson> Because now it defaults to unbuffered for byte streams
<zyga> pitti, https://plus.google.com/116315264177593873442/posts/aQq8vV7gUnE :-)
<pitti> hey zyga
<pitti> zyga: ah, nice! this looks similar to what "apport-bug storage" is doing
<zyga> pitti, cool, I didn't know that
<pitti> zyga: hm, wouldn't it be easier to run udisksctl monitor? or is that missing some signals?
<zyga> pitti, I'll be using that to port checkbox to udisks2
<zyga> pitti, no, it's just something I wrote for this task, the code is shared with checkbox actually
<pitti> zyga: anyway, if it helps, it should build just fine on precise, so we can put it into a PPA or so
<zyga> pitti, hmm, udisks2 in precise ... it might be cool but then again some things (mounting) will still happen via udisks1
<zyga> pitti, I'll think about it but the focus right now is to get results from standard installs
<pitti> makes sense
<zyga> pitti, so that we have predictable behavior in practice
<xnox> mpt: what is your opinion on tooltips? bug 1045799
<ubottu> Launchpad bug 1045799 in ubiquity (Ubuntu) "Manual partitioner: Add tooltips to icons 'Add', 'Remove', and 'Modify'" [Undecided,Confirmed] https://launchpad.net/bugs/1045799
<mpt> KILL THEM ALL
<mpt> KILL THEM WITH FIRE
 * mpt reads the bug report
<nigelb> lol
<mpt> xnox, is <https://launchpadlibrarian.net/114858452/result.png> how it looks with the default theme?
<mpt> Those are some weird icons.
<mpt> Wait, that isn't even the installer, that's GParted!
<xnox> mpt: so I did change "Add partition","Remove partition", "Edit partition" to symbolic icons "+","-","cog"
<mpt> xnox, may I see a screenshot?
<xnox> mpt: now I am confused if people are confused about Gparted or Ubiquity.
<xnox> mpt: one moment.
<cjwatson> I suspect Erick is confused in ways that jibel is not.
<xnox> mpt: i really want the "Pencil" icon, instead of/in addition to a "cog"
<mpt> xnox, I specced "Change..." as text: https://docs.google.com/a/canonical.com/document/d/1bZ4yQIVgGaUGSYu3qiUHnQt3ieBZoqunP_DcleHCr3I/edit#heading=h.6zratkhfgk60
<xnox> mpt: I was naughty =)
<bdrung> dholbach: done.
<dholbach> thanks bdrung! :)
<mpt> xnox, I don't know why you'd add tooltips post-UIF but not just switch to the specced label post-UIF
<xnox> mpt: here is link how it currently looks like https://picasaweb.google.com/lh/photo/jsf4RKjSfg6IKFMoShVwtlh0btKKriD5FR8jiayHfxc?feat=directlink
<xnox> mpt: I personally hate tooltips and status bars with passion
<mpt> xnox, why don't the buttons have borders?
<xnox> mpt: also the right click menus
<xnox> mpt: ask the theme designers =/
<xnox> mpt: the border appears on mouse-over
<mpt> Are you sure this is a theme issue?
<xnox> mpt: the onces on the right are "button box" the onces on the left is "toolbar"
<mpt> Does the theme say "whoa, this button has only an icon in it, I'm dropping the border"?
<mpt> xnox, ok, well don't do that then, use a normal button :-)
<xnox> mpt: I was naughty =) menubar is the easiest / quickest way to get symbolic icons, but I couldn't get mixed labels/icons in the same toolbar.
<xnox> mpt: =)))))
<mpt> My designs can take only so much abuse before they break, you know.
 * xnox LOL
<xnox> mpt: ok. What about the size of the + and - ? big enough? just right? too small?
<mpt> xnox, looks right to me.
<xnox> mpt: let me change it to what it was suppose to be and then I'll give you another screenshot.
<mpt> ok
<tjaalton> ppa queue ~7h..
<SpamapS> hm, seems xserver-xorg-input-mtrack has restored my trackpad
<SpamapS> tho I seem to recall having lots of other problems with this driver
<tjaalton> restored how?
<SpamapS> tjaalton: with evdev, I get no working trackpad
<tjaalton> SpamapS: ok
<SpamapS> bug 1046675 btw :)
<ubottu> Launchpad bug 1046675 in xorg (Ubuntu) "macbook air 4,1 trackpad does not work on upgrade to quantal from precise" [Undecided,Confirmed] https://launchpad.net/bugs/1046675
<tjaalton> well I've got xserver 1.13 ready, but nowhere to build it
<tjaalton> since half the builders are idle or offline, queue ~7h
<barry> cjwatson: yes, that does seem unfortunate.  at least it's documented though ;)  http://docs.python.org/py3k/library/subprocess.html and search for 'bufsize'
<mpt> ev, should configuration file prompts in upgrades (bug 86028) be considered errors like debconf prompts? What do you think?
<ubottu> Launchpad bug 86028 in update-manager (Ubuntu) "RFE: ask all config-file questions at the start or end of the upgrade" [Wishlist,Confirmed] https://launchpad.net/bugs/86028
<ev> mpt: I'm inclined to say yes, but we should chat with someone who knows conffiles better than I do.
<stgraber> pitti: I'm not an archive admin, so can't commit to ubuntu-archive-tools
<slangasek> mpt: a conffile prompt for a conffile that the user didn't edit is an error; a conffile prompt for a conffile that they did is the standard conflict resolution method; there's no way for us to tell the difference from an automated report
<pitti> stgraber: ah, I thought as ~ubuntu-release you were
<stgraber> pitti: ~ubuntu-release now has direct queue admin rights on <dev> and <dev>-proposed, so I can accept packages but I'm not in ~ubuntu-archive
<mpt> slangasek, what would we need to change to make them distinguishable? (store the modification date somewhere? or a hash value?)
<slangasek> mpt: there's nothing you can do
<slangasek> it's *either* a user modifying it, *or* it's software going rogue and modifying it
<slangasek> you can't distinguish these unless you know what software is going rogue, e.g. by reproducing it in an autotest
<bdmurray> barry, pitti: could one of you review an aptdaemon merge proposal? https://code.launchpad.net/~brian-murray/aptdaemon/bug-875879/+merge/122979
<ubottu> Launchpad bug 122979 in xserver-xorg-video-intel (Ubuntu) "[aiglx][intel][r300] Video playback is buggy under Compiz" [High,Fix released]
<pitti> url 1
<pitti> oops
<pitti> bdmurray: seems fine to me, thanks
<bdmurray> pitti: are you going to upload aptdaemon then? also do you have any ideas for an SRU test case for this?
<pitti> we are still frozen anyway, and mvo is working on a few branches which I guess he'd want in soon as well, so I guess he'll do an upload soon
<mvo> yeah, I would love to get a new version in on friday
<bdmurray> mvo: do you have an idea of an sru test case for bug 875879?
<ubottu> Launchpad bug 875879 in update-manager (Ubuntu Quantal) "update-manager crashed with AttributeError in show_diff(): 'NoneType' object has no attribute 'group'" [High,Triaged] https://launchpad.net/bugs/875879
<shadeslayer> cjwatson: you mentioned a couple of days ago that something was misbuilt
<cjwatson> I fixed it
<cjwatson> https://launchpad.net/ubuntu/+source/syslinux-themes-ubuntu/5
<cjwatson> That was the cause of the iso-hybrid failures in live-build
<mvo> bdmurray: hm, we could have to find a package that changes the conffile during a upgrade, I could try to fabricate something
<BenC> Laney: haskell-hint builds on ppc, and it looks like it's restrictions on architecture are based solely on needing ghci. Should I set it to Arch: any and update the build-deps to use ghc-ghci?
<mvo> bdmurray: hrm, hrm, so I created a artifical conffile prompt, but couldn't trigger the bug with it
<bdmurray> mvo: with quantal or precise? errors.ubuntu.com doesn't show any quantal versions of the error for some reason
<mvo> bdmurray: tested on my precise box
<dholbach> can somebody please reject https://code.launchpad.net/~ianrob1201/ubuntu/quantal/libmoosex-semiaffordanceaccessor-perl/typo-fix/+merge/122370?
<BenC> Laney: â¦so that seemed to the the correct way to handle it based on other packages, I've uploaded that change
<bdmurray> mvo: that seems strange
<dholbach> https://code.launchpad.net/~radumstoica/ubuntu/quantal/libnss-pgsql/typo-fix/+merge/122383 too please
<BenC> Laney: And after that, it seems the transition is basically done for powerpc (two dep-waits that will eventually trigger today sometime)
<mvo> bdmurray: I put info how to reproduce into the bugreport now, its a artificial thing that should only be done in a VM
<bdmurray> mvo: okay, thanks I'll have a look in a bit
<mvo> bdmurray: its really odd, the conffile is there and all but the diff looks valid instead of crashing
<xnox> does update-manager -d work against a local mirror?
<xnox> as in, when there is no network to archive.ubuntu.com
<xnox> but there is to some other official mirror
<mvo> xnox: if the mirror is the only server then yes, if you mix it with a official mirorr it will ocmment the local one out
<BenC> infinity: Is ghci segfaulting on arm?
<xnox> mvo: what if the official one times-out?
<xnox> mvo: or otherwise inaccessible? e.g. blocked by firewall?
<mvo> xnox: I'm not sure, but I don't think its very clever in this case and will just fail
<xnox> mvo: ok.
<BenC> Is anyone able to give me shell access to an arm box so I can try to fix ghc?
<tumbleweed> BenC: http://arm.trystack.org/ <- public access to the calxeda machines
<tumbleweed> (takes a while to get an account, but I can spin one up and give you acesss to it, if you want)
<BenC> Thanks, I think I'll actually just fire up a qemu
<tumbleweed> yaeh, that works well enough for ARM
<mpt> ev, interesting how errors.ubuntu.com has a spike in errors/day during the weekends, but trunk has a dip in the weekends.
<ev> hmm, nice spot
<mpt> (In both cases the pattern might be clearer if they were PDT or CT days rather than UTC -- not that that means you should switch.)
<ev> some day we'll calculate it by hour
<ev> and let you zoom in
<ev> ah
<ev> I guess that doesn't help here
<xnox> mpt: buttons as per spec: https://picasaweb.google.com/lh/photo/IX7RCztyVR5RU0OPsX2CXVh0btKKriD5FR8jiayHfxc?feat=directlink
 * xnox is dissappointed that (a) gtk does not have symbolic stock buttons (b) that I couldn't simply use + and - ascii characters for those "labels" and had to hack together symbolic image with empty text label next to it
<mpt> xnox, better, thanks. Someday we'll have buttons smart enough to glob together (like USC's Back and Forward buttons) if you put them right next to each other.
<mpt> A really smart theme could do that.
<xnox> mpt: well that was one reason I used toolbar buttons originally, naÃ¯vely thinking they'd do the globbing
<zyga-w510> cr3, http://pastebin.ubuntu.com/1189171/
<cr3> zyga-w510: sweet, thanks man!
<xnox> mpt: although in System Settings we have globbing! Open System Settings -> Appearance and notice that (all settings|appearance)
<shadeslayer> cjwatson: awesome, thanks :)
<xnox> mpt: I am committing this for now, can do globbing later.
<cr3> zyga-w510: so, your Wacom ISDv4 E2 Finger touch doesn't seem to be detected as a multitouch device. is it appearing in the System Settings -> Wacom Graphics Tablet?
<shadeslayer> let's see if it works
<zyga-w510> cr3, yes
<zyga-w510> cr3, it's dual touch technically
<cr3> zyga-w510: technically, but it's not currently working as mutitouch, right?
<zyga-w510> cr3, it does't work at all now
<zyga-w510> cr3, touching the screen randomly moves the pointer around
<mpt> thanks xnox
<zyga-w510> cr3, actually
<cr3> zyga-w510: good for me, bad for me :) this is valuable information
<zyga-w510> cr3, when I tried that just now it _did_ work
<cr3> err, s/bad for me/bad for you/
<cr3> zyga-w510: it's working as a touch device but not a multitouch device though, right?
<zyga-w510> yes
<zyga-w510> cr3, although a moment ago I'm pretty sure that id did something rather stupid and made the pointer dance around the screen
<zyga-w510> cr3, in precise I did apply a few udev tweaks that I forgot about and got lost later when I wiped this machine
<cr3> zyga-w510: ok, so we need to determine whether we want to test whether touchscreens work as touch devices separately from whether they work as multitouch devices
<zyga-w510> cr3, definitely
<zyga-w510> cr3, testing this now I realize one more thing is important and relevant for udisks2 and other tests
<zyga-w510> cr3, the speed of discovery -- it's not instant
<zyga-w510> cr3, I suspect there's some polling behind the scenes
<zyga-w510> cr3, I'll add timestamps to my output so that we know better what to do, maybe the 20 second timeout should be changed
<cr3> zyga-w510: while you're on that machine, could you also pastebin the output of /usr/share/checkbox/scripts/udev_resource? it's so great having all the scripts in checkbox readily available onthe live image to test hardware!
<zyga-w510> sure
<zyga-w510> cr3, http://paste.ubuntu.com/1189198/
<cr3> zyga-w510: hehe, I meant the output of running that script :)
<zyga-w510> oh
<zyga-w510> I was curious after doing that
<zyga-w510> why would you need it ;)
<cr3> zyga-w510: I love the python3 part, barry will be proud :)
<zyga-w510> http://paste.ubuntu.com/1189202/
<zyga-w510> cr3, that the script is written in python3?
<barry> cr3: rock!
<cr3> zyga-w510: lines 480 to 492 look pretty darn good!
<ogra_> so drop the rest !
<cr3> ogra_: we're still talking about lines, right? :)
<ogra_> yeah, but then your code becomes *perfect*
<ogra_> like a haiku :)
<zyga-w510> cr3, in the pastebin?
<cr3> ogra_: 0 lines == 0 bugs
<ogra_> ++
<zyga-w510> category touch?
<cr3> zyga-w510: yeah, your wacom device seems to be properly detected by the udevadm parser. so at least we're reporting complete information and accurate too, as it's being properly recognized as a TOUCH device
<zyga-w510> cr3, right, I understand that now, cool, that's very good
<cr3> zyga-w510: we might need to refine that category for touch vs multitouch
<zyga-w510> cr3, do you think you'd like a separate multi-touch category (or extra property somewhere)
<cr3> zyga-w510: I'm very careful before adding categories, so we'll evaluate the need for it as we write tests
<zyga-w510> barry, why oh why py3k/py2k bytes type is such a mess :-)
<zyga-w510> barry, couldn't py3k use raw_bytes or something
<barry> zyga-w510: i'm not sure what you mean ;)  okay, yeah it's a mess in py2
<zyga-w510> barry, I mean that since it means something totally different then for the sake of easier compatibility the true bytes type in py3k could have been called raw_bytes, leaving bytes as an alias of str to keep the old crappy behavior
<zyga-w510> barry, I probably want the impossible
<zyga-w510> (I now have to do the ord/chr dance)
<cr3> ogra_: I find it unfortunate that the industry still rewards people adding code more than those removing it
<zyga-w510> cr3, evolution did the same, mind you
<cr3> zyga-w510: never settle for anything less than the impossible :)
<ogra_> heh
<barry> yeah, given that python 2 is a dead end, it's impossible :)
 * zyga-w510 wishes for py2.7.9(9) release with from __future__ import bytes3k
<zyga-w510> to suck less
<cr3> zyga-w510: evolution is slowly getting rid of the appendice routine
<cr3> appendix in english, I mean
<zyga-w510> barry, was there a 3to2 program or is there only 2to3?
<barry> zyga-w510: pep 404 :)
<zyga-w510> heh
<zyga-w510> yeah
<zyga-w510> barry, but in all fairness that policy huts the transition -- I'm not asking for a real 2.8
<barry> zyga-w510: there's a rumored 3to2 program, but i've never tried it.  frankly i'm not a fan of 2to3 for production or development either (although a cool framework, it's just too slow)
<zyga-w510> barry, it's like u getting back to 3k
<zyga-w510> s/huts/hurts/
<barry> zyga-w510: yeah.  it's just that i think that if your py2 code is unicode clean, you will have a much easier time with the transition.  caveat that with the tricks we've learned, tools like the six module, and maybe even the re-introduction of u'' in py3.3 for the web framework guys
<cr3> barry: wait, why reintroduce u'' for web framework guys?
<zyga-w510> barry, what would you do when you had to ship 2/3 programs for the next few years?
<zyga-w510> cr3, for 2to3 to indicate where it is safe, web is not unicode
<zyga-w510> web is _B_Y_T_E_S_ man
<barry> cr3: http://www.python.org/dev/peps/pep-0414/
<ScottK> I have packages that run 2to3 at build time and ship both python and python3 binaries, it's not that hard.
<zyga-w510> Scott, I wrote mine in py3 so I'm hosed
<didrocks> ScottK: waow, and you didn't have to adjust anything else?
 * didrocks always has some adjustement to do after running 2to3
<barry> zyga-w510: i agree, but i'm not the project leader of django/zope/cherrypy/wtfwebetckthxbye
<ScottK> Upstream coded for it to be done that way.
<barry> zyga-w510: i've written lots of single-code base py2/py3 compatible code.  it's not that hard
<didrocks> ah ok, it's not the pure python2 first draft, it had been adapated :)
<barry> zyga-w510: w/o 2to3
<infinity> BenC: I haven't been paying attention to GHC (or much of anything) lately. :/
<zyga-w510> barry, so did I today
<didrocks> adapted*
<ScottK> Personally, I find it easier for stuff I'm writing to target 2.6+ and make the code work with python and python3.
<zyga-w510> barry, except for bytes that I'm actually fixing now
<ScottK> didrocks: Yes.  It's upstream's method for supporting older than python2.6 and python3.
<cr3> barry: thanks, I can appreciate this harsh reality: Most of those users couldn't care less about the "purity" of the Python language specification, they just want their websites and applications to work as well as possible.
<barry> ScottK: >= 2.6 is a requirement imho, but some folks have been able to go all the way back to 2.4 with single code base.
<didrocks> ScottK: that's nice :)
<zyga-w510> cr3, end of quote ;)
<barry> zyga-w510: yeah, that's what i mean.  the bytes v. strings model must be solid, which is not always easy. (e.g. email is both)
<ScottK> So is DNS.
<zyga-w510> yeah, I fully agree
<barry> ScottK: yeah
<barry> zyga-w510, cr3, ScottK: many people have found this compatibility library to be very helpful: http://packages.python.org/six/
<ScottK> I've heard about it, but haven't used it.
<barry> and of course it's available as python-six and python3-six
<zyga-w510> wow
<zyga-w510> six.binary_type
<zyga-w510> ++
<zyga-w510> cool, thanks
<barry> i haven't needed to use it myself, but i've occasionally lifted tricks from it :)
<cr3> barry: exponent is even more powerful than multiplication, so eight will certainly be even better than six!
<mpt> ev, speak of the devil: https://launchpadlibrarian.net/114961700/libreoffice-upgrade.png
<ev> mpt: ICK
<cjwatson> barry: Oh, which reminds me: am I safe to assume at this point that we really aren't going to revert to py2, and start ripping out compatibility code from ubiquity?
<zyga-w510> heh
<cjwatson> It's not a desperate hardship to keep it, but I kind of figure I'd have heard by now if we were going back
<zyga-w510> barry, I wonder if angry mint-switching users will fork python2.7 and release minthoon-2.8 ;)
<xnox> zyga-w510: mint users are ok, until they take my packages from ubuntu (!) and report bugs against debian (!!) that it doesn't work with mint-foo (!!!)
<zyga-w510> ^_^
<zyga-w510> well
<zyga-w510> you can't blame them
<zyga-w510> they go upstream, right
<silverarrow> what`s wrong with mint then?
<xnox> silverarrow: forking core libs & changing API&ABI without rebuilding r-deps in the whole archive.... shall I continue?
<barry> cjwatson: no going backward only forward :)  it does mean will have to ship py2.7 and 3.3 for 12.10 and try again to remove 2.7 from the 13.04 isos, but i have no problem with you ripping out the compatibility code and making it a clean py3 app.  that's what we're doing with gwibber (though it won't make it for 12.10 obviously)
<ogra_> silverarrow, supressing security updates
<silverarrow> might get messy
<barry> zyga-w510: :)
<silverarrow> ubuntu have at least been very good with security updates
<xnox> barry: should the rest of the task still be completed on the best effort bases from the python-versions spec?
<xnox> s/task/tasks/
<xnox> barry: and is xapian the road-block blocking everything else?
<barry> xnox: yes, if possible.  i've copied the spreadsheet to a new one for 13.04 and removed all the green.  i'll publish that soon, but i definitely want to get a jump on the ports for 13.04.
<barry> xnox: xapian, twisted, and the launchpadlib stack are big blockers
<barry> xnox: twisted is probably in the best shape (people are actively working on it).  the lplib stack and xapian are still the most problematic
<xnox> barry: ok.
<xnox> barry: by launchpadlib you mean the bug reporting integration for apps or just the pythonic api to talk to launchpad (e.g. stuff like lp-shell and etc)?
<barry> xnox: well, actually, i will have to re-evaluate it for 13.04.  launchpad-integration was the package that needed porting but it no longer has an ubuntu-desktop task afaict
<barry> xnox: if we can ignore that stack, i would be ecstatic
<xnox> barry: yes, because it's dropped. We have whoopsie & apport instead.
<xnox> barry: it's dead =) & on the way out.
<ev> whoop
<didrocks> sie? :)
<barry> ev you are my bff :)
<ev> barry: well lets get bracelets made then
<[snake]> can I compile something into a directory that I specify?
<[snake]> with make
<barry> xnox, ev: which cuts out wadllib, and a host of other really nasty and difficult to port stuff.  win!
<[snake]> I've written a patch for xchat and I want to compile it somewhere where it doesn't overwrite my normal xchat
 * xnox is googling for custom made bracelets "whoop" for ev and "sie" for barry
<ev> haha
<barry> :)
 * xnox they will have "signed by didrocks" signature trademark. And inside will have a writting like in Lord of the Rings "To collect all bugs and unite all crashes..."
<didrocks> heh :)
<[snake]> target in the man page for make is where it compiles correct?
<xnox> [snake]: #ubuntu-app-devel for app development on ubuntu. This a channel for developing ubuntu itself.
<[snake]> xnox, what if I am make-ing ubuntu?
<mpt> "Replace the customized configuration file '/etc/update-manager/release-upgrades'?" </irony>
<[snake]> xnox, I mean, I'm not, but the question is just about make
<[snake]> :(
<xnox> mpt: I call BS =)
<bismay> Hii I want to be an ubuntu app developer any suggestions from where I should start?? Currently i have knowledge of c and c++
<xnox> [snake]: google for out of the tree builds, or VPATH builds then
<mpt> xnox, https://launchpadlibrarian.net/114963812/update-manager-conf-file.png
<tsimpson> [snake]: set a different --prefix with configure
<mpt> bismay, questions like that are better in #ubuntu-app-devel, but the short answer is <http://developer.ubuntu.com/get-started/>
<[snake]> tsimpson, oh, thanks :) I checked and target was just what you're compiling. so thanks for telling me that
<bismay> mpt, thanks..:)
<xnox> mpt: that bug was already reported =)
<mpt> xnox, I didn't see it when I searched.
<mpt> xnox, it's bug 1046942 if you want to mark it as a duplicate.
<ubottu> Launchpad bug 1046942 in update-manager (Ubuntu) ""Replace the customized configuration file '/etc/update-manager/release-upgrades'?"" [Undecided,New] https://launchpad.net/bugs/1046942
<xnox> bdmurray: what was the bug for Libreoffice prompt vs Prompt? Or is mpt the first reporter?
<mpt> I was not
<xnox> mpt: wait.... why update manager. Me is confused.
<xnox> maybe it's a different one
<mpt> xnox, the libreoffice one is bug 918352
<ubottu> Launchpad bug 918352 in libreoffice (Ubuntu) "Debconf prompt for /etc/libreoffice/sofficerc when upgrading to precise" [Medium,Confirmed] https://launchpad.net/bugs/918352
<nuclearbob> can anybody field a casper question for me?
<mpt> Now I'm about to report a gdm one
<bdmurray> xnox: bug 1045579
<ubottu> Launchpad bug 1045579 in software-properties (Ubuntu Quantal) "software-properties-gtk makes a change resulting in a conf file prompt on upgrade that's unnecessary" [High,Triaged] https://launchpad.net/bugs/1045579
<xnox> bdmurray: thanks. mpt ^^^^
<mpt> ohhhh
<xnox> mpt: I can totally understand how easy it is to relate your & that bug titles
<xnox> =))))))))))))
<mpt> xnox, also, it was filed against a different package, so I wouldn't have seen it anyway.
<xnox> mpt: haha. True. It has now been marked against the package that is causing the error, not the package where the file belongs nor the window that shows it.
<xnox> mpt: it's same way that adobe acrobat reader, is causing similar errors on gnome-mimetypes package upgrade. Or something like that =)
 * mpt arrives at the "Remove obsolete packages" stage (bug 940789)
<ubottu> Launchpad bug 940789 in update-manager (Ubuntu) ""Obsolete packages will be removed" dialogue is too tall for netbook screen with KDE front end" [Medium,New] https://launchpad.net/bugs/940789
<xnox> mpt: you are using KDE?!
 * xnox is a bit sad =(
<xnox> mpt: or does it affect gtk front-end as well?
<mpt> xnox, I think it affects GTK coincidentally
<mpt> It's a typical GTK2 dialog that hasn't been ported to GTK3 and ballooned in height
<mpt> reported as bug 1046955
<ubottu> Launchpad bug 1046955 in update-manager (Ubuntu) ""Remove obsolete packages?" prompt is taller than the screen" [Undecided,New] https://launchpad.net/bugs/1046955
<xnox> mpt i will take it for the jam then.
<stokachu> hi has anyone seen an error like this before > http://paste.ubuntu.com/1189405/
<stokachu> attempting to checkout a branch on precise
<stokachu> not sure if this is a launchpad issue or not
<mpt> stokachu, I get the same error, so I think it is a Launchpad problem. Try asking in #launchpad.
<mpt> stokachu, I get the same error, so I think it is a Launchpad problem. Try asking in #launchpad.
<stokachu> mpt: thanks will do
<scott-work> skaet: i have done what i can at this time
<skaet> thanks scott-work
<stokachu> cyphermox: is http://pad.lv/872824 something you would approve a full a quantal patch for precise even though strongswan has seen at least 2 release bumps
<ubottu> Launchpad bug 872824 in network-manager-strongswan (Ubuntu Precise) "Network-manager locks up when adding strongSwan VPN connection" [Critical,Triaged]
<stokachu> there seems to be several code changes from precise to quantal and i dont think cherry-picking will be trivial
<cyphermox> stokachu: what about backporting strongswan? I think it should be doable, it's in universe and IIRC has no reverse-depends except itself
<cyphermox> stokachu: the bzr error, I got the same earlier this morning; but I don't know what causes it, let me know if you find out
<stokachu> cyphermox: ah, yea its a bug i had to add launchpad.packaging_verbosity = off to my ~/.bazaar/bazaar.conf
<cyphermox> blarg
<stokachu> cyphermox: https://bugs.launchpad.net/bzr/+bug/888615
<ubottu> Launchpad bug 888615 in Bazaar "UDD branch freshness checker breaks on incomplete history" [High,Confirmed]
<stokachu> the history is incomplete on that branch as well
<stokachu> it isn't showing the latest changelog for the released version of network-manager
<cyphermox> it isn't?
<cyphermox> stokachu: anyway, there is the right stuff in lp:~network-manager/network-manager/ubuntu.precise
<stokachu> network-manager (0.9.3.995+git201203152001.04b2a74-0ubuntu1) precise; urgency=low is the latest one in changelog
<cyphermox> let me know if you
<cyphermox> need to make changes, I'm preparing a SRU locally
<stokachu> ok will do
<stokachu> cyphermox: yea i think it would be best to backport strongswan and network-manager-strongswan to precise
<cyphermox> stokachu: can you file the appropriate bugs?
<stokachu> cyphermox: sure thing, thanks :)
 * micahg points stokachu at requestbackport
<stokachu> micahg: ah nice
<ev> pitti: if you're still around. Why does apport-retrace now need a terminal emulator?
<ev> r2009
<ev> I can't find any other reference in the log
<trism> ev: it pops up a terminal to show progress when downloading packages if you use "Examine Locally" from the apport dialog (though depend might be a bit strong)
<ev> trism: but that's in apport-gtk, not apport-retrace
<trism> ev: yes but apport-retrace enables the functionality
<ev> trism: sure, but that seems the wrong way around to me. apport-retrace is a headless application, it doesn't need to pull in the universe.
<trism> ev: good point, the changelog hints it was added a couple months ago in 2.2.3-0ubuntu1, not sure
<mterry> ev, heyo!  Do you know how to extract a trace-with-symbols from errors.ubuntu.com?
<dobey> mterry: hrmm; actually, looking at the "Problem failed:/blah/blah" strings, I wonder if it is due to some obscurbe multiarch issue on the error reporting box that breaks the retracing
<ev> mterry: can you point me at the problem you're looking at?
<mterry> ev, like https://errors.ubuntu.com/bucket/?id=failed%3A%2Fusr%2Fbin%2Findicator-weather%3A11%3Ax86_64%3A%2Flib%2Fx86_64-linux-gnu%2Flibglib-2.0.so.0.3200.3%2B1cf08%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibdbusmenu-glib.so.4.0.13%2Baca2%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibdbusmenu-glib.so.4.0.13%2Bcafa%3A%2Flib%2Fx86_64-linux-gnu%2Flibglib-2.0.so.0.3200.3%2B47d53%3A%2Flib%2Fx86_64-linux-gnu%2Flibglib-2.0.so.0.3200.3%2B480a0%3A%2Flib%2Fx86_64-linu
<mterry> x-gnu%2Flibglib-2.0.so.0.3200.3%2B4849a%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibgtk-x11-2.0.so.0.2400.10%2B1342f7%3A%2Fusr%2Flib%2Fpython2.7%2Fdist-packages%2Fgtk-2.0%2Fgtk%2F_gtk.so%2B1ac046%3A%2Fusr%2Fbin%2Fpython2.7%2B9890a%3A%2Fusr%2Fbin%2Fpython2.7%2B98602%3A%2Fusr%2Fbin%2Fpython2.7%2B9f1c0%3A%2Fusr%2Fbin%2Fpython2.7%2Ba9081%3A%2Fusr%2Fbin%2Fpython2.7%2Ba9311%3A%2Fusr%2Fbin%2Fpython2.7%2Baa8bd%3A%2Flib%2Fx86_64-linux-gnu%2Flibc-2.15.so%2B2176d
<ev> mterry: that's one that failed to retrace
<ev> mterry: https://bugs.launchpad.net/daisy/+bug/1044418
<ubottu> Launchpad bug 1044418 in Daisy "Reprocess failed retraces" [Undecided,New]
<mterry> ev, OK...  is that what the "failed:" prefix means?
<ev> yes
<ev> I'm making a note to make that more obvious
<ev> as this is not the first time it's come up
<mterry> ev, OK makes sense.  Thanks!
<jdstrand> barry: hi! are we expecting only one python3 in main? I see python3.3 in the archive is wanting to come in (I'd really prefer to support only one py2 and one py3)
<xnox> jdstrand: due to a bug in python3-defaults 3.3 will not become default, which blocks switching to it.
<xnox> jdstrand: so while it might be in the archive both 3.2 & 3.3 will not be supported (e.g. modules will not be compiled against both)
<xnox> jdstrand: my guess is that it will mean that python3.3 will be in universe this cycle.
<jdstrand> xnox: thanks, that works fine for me
 * jdstrand points to http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<jdstrand> 'distribute' wants it in main
<barry> jdstrand, xnox plus 3.3 final is not out yet, so yeah, we're carrying 3.2 and 3.3 for 12.10
<barry> and we know that there are a few bugs in 3.3 that will bite people.  e.g. the ancient version of zope.interfaces is not compatible w/3.3 so we (and debian too) need to upgrade that to z.i 4.0.1
<xnox> barry: jdstrand cares about 3.3 in the main or in the universe ?
<xnox> barry: will 3.3 be supported in any way (e.g. modules compiled for it)
<infinity> Methinks this means 3.3 should stay in universe, and distribute should be made to love 3.2.
<barry> yeah 3.3 in uni
<xnox> oh... yes, I agree with infinity.
<ScottK> Distribute does love 3.2, it's just not monogamous
<barry> % apt-cache showsrc python3.3 | grep -i section
<barry> Section: universe/python
<barry>  
<infinity> barry: Yeah, we know it's in universe, that's what started this whole conversation. :P
<barry> oh :)
<infinity> barry: doko uploaded a version of distribute that build-deps on 3.3
<jdstrand> one of them in universe is all I care about :)
<infinity> doko: Plz fix.
<infinity> doko: Or I will.
<jdstrand> thanks! :)
<barry> infinity lays the smackdown
<xnox> infinity: I was about to ask how did a package manage to build-dep on 3.3 if only doko uploaded 3.3 & didn't add it as supported....
<ScottK> infinity: I'm sure he got an FFe before uploading that.
<infinity> ScottK: Sarcasm is unbecoming.
 * barry runs away back to #gwibber
<xnox> slangasek: was that I hint, I should write release notes ? =)
<xnox> slangasek: was that a hint, I should write release notes ? =)
<slangasek> xnox: yes :)
 * infinity waits for the second "xnox: yes :)"
<xnox> slangasek: also the whiteboard needs clean up
<slangasek> probably
<slangasek> xnox: release note is a higher priority though, as this is currently a gap in the tech overview for beta1
<doko> infinity, xnox: distribute should support 3.3 as well
<doko> but maybe I'll just b-d on 3.2
<xnox> doko: danke.
<haakonn> Why is not ubuntu updating packages from debian sid? or at least my package
<infinity> doko: I was just fixing it to not b-d on 3.3
<xnox> haakonn: because ubuntu is currently frozen.
<doko> ahh, thanks
<xnox> haakonn: and so is debian.
<haakonn> already? ok
<xnox> haakonn: check quantal release schedule, debian import freeze is quite early. This is when we stop auto syncing. You can request a sync with requestsync if it is suitable per ubuntu policy, you might also need FFe
<haakonn> FFe?
<jbicha> haakonn: it's short for Feature Freeze Exception, bug fixes are fine but new features need approval
<jbicha> https://wiki.ubuntu.com/FreezeExceptionProcess
<haakonn> jbicha: Hm. it has both bugfixes and new features. Is it hard to get approval?
<jbicha> haakonn: it depends; is it in universe? does it affect many other packages? how well tested is it?
<slangasek> xnox: prelim release notes added to https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta1
<haakonn> jbernard: it is in universe yes, and it does not affect any other packages. It has been tested for a month by me and a few other poeple.
<haakonn> https://launchpad.net/ubuntu/+source/mactelnet
<jbernard> jbicha: ^
<haakonn> yes, sorry
<jbernard> haakonn: no worries
* ChanServ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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:
#ubuntu-devel 2012-09-07
<BenC> cjwatson: Good news: I had to use video=ofonly, but the latest quantal-live ISO boots and installs on my iMac G5
<TheMuso> jbicha: Urm, stuff in proposed will eventually be let out...
<jbicha> TheMuso: yeah, I just get impatient though :(
<TheMuso> jbicha: Well in teh case of those packages I uploaded to proposed and that you sponsored into quantal proper, it means the archive admins will now have to reject those.
<TheMuso> WHich will probably make a little more work for them, as they probably accept from proposed on mass.
<pitti> Good morning
<sshaw> hi, I'm trying to build f-spot from source on ubuntu 12.04 and when I run the autogen.sh script I get this error: autogen.sh: 10: autogen.sh: Syntax error: "(" unexpected
<sshaw> the function it errors out on is check_autotool_version
<pitti> ev: yes, I think we can move the dependency to apport-gtk and apport-kde
<sshaw> am I missing some gnome devel package
<sshaw> or should this question be better asked in a different channel? #ubuntu?
<pitti> ev: pushed to packaging branch
<slangasek> pitti: morning
<pitti> ah, we're unfrozen, nice! /me releases his staged -proposed uploads
<slangasek> pitti: there seems to be a problem with glib2.0 and gobject-introspection in quantal... the latter has been copied to quantal and has a dependency on the former, which is still in -proposed?
<slangasek> heh :)
<pitti> hm, I'm not sure why someone copied one without the others
<pitti> I'll leave the linux bits, I don't know about their state
<TheMuso> jbicha: ^^^
<slangasek> pitti: well if you're about to fix it, then that's fine ;)
<TheMuso> Goes back to what I was saying.
<pitti> erk @ http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html
<pitti> http://people.canonical.com/~ubuntu-archive/testing/quantal-proposed_probs.html looks slightly better, but I guess linux still needs some love
<slangasek> TheMuso: which packages need rejecting?
<dholbach> good morning
<iulian> Morning dholbach.
<dholbach> hey iulian
<cc11rocks> 10th Debian patch forwarded : http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=cc11rocks%40yahoo.com (1 pending upload, 9 outstanding)
<tkamppeter> Someone around who can sync qpdf from Debian Experimental for me?
<pitti> syncpackage doesn't work for you?
<pitti> tkamppeter: does it need a FF etc. exception? or just bug fxies?
<mpt> E: /var/cache/apt/archives/libgnome2-bin_2.32.1-2ubuntu2_i386.deb: trying to overwrite '/usr/bin/gnome-open', which is also in package libgnome2-0 2.32.1-2ubuntu1
<ev> pitti: cheers!
<didrocks> mpt: fixed
<tkamppeter> pitti, it is part of a bug fix, for https://bugs.linuxfoundation.org/show_bug.cgi?id=1063.
<ubottu> bugs.linuxfoundation.org bug 1063 in cups-filters "pdftops - page management options not being removed" [Blocker,New]
<davmor2> pitti: why does every release hate my Sansa fuse so, It's showing up but as a usb drive rather than a music player
<mpt> didrocks, thanks. Anything I need to do to repair before installing next updates?
<didrocks> mpt: should be nearly available: https://launchpad.net/ubuntu/+source/libgnome/2.32.1-2ubuntu3
<pitti> davmor2: not sure; when did this start breaking again? it's not like we do a whole lot of m-p-i updates..
<didrocks> mpt: the easiest way is to download this .deb package: https://launchpad.net/ubuntu/quantal/+package/libgnome2-bin
<cjwatson> pitti: tkamppeter doesn't have upload access to qpdf, according to edit-acl
<davmor2> pitti: it's the first time I've plugged it into Quantal so not sure
<pitti> cjwatson: ah, thanks
<tkamppeter> cjwatson, pitti, as QPDF serves mainly for printing and usually needs to be updated if there is a printing problem or change it should perhaps be added to my list.
<mpt> didrocks, doing that says "Failed to satisfy all dependencies (broken cache)."
<didrocks> mpt: ok, I thought that stokachu didn't put a strong dep in his new faulty -bin package, so the easiest way is to wait the fix to be published (should be in less than 30 minutes) or download this -bin package, libgnome2-common and libgnome2-0 + dpkg them
<pitti> tkamppeter: ok, libqpdf8 does not have many rdepends, just cups-filters and "qpdf"; I guess you tested those wit 3.0.2?
<didrocks> from https://launchpad.net/ubuntu/+source/libgnome/2.32.1-2ubuntu3
<mpt> didrocks, I think I can avoid restarting for 30 minutes. :-) Thanks.
<didrocks> yw :)
<tkamppeter> pitti, qpdf was introduced only for cups-filters. The change in the new Debian package is only support for injecting comments into the PDF output. These comments are needed so that pdftopdf can communicate with pdftops, which the old pdftopdf to prevent N-up coming out as N*N-up.
<pitti> tkamppeter: synced
<tkamppeter> pitti, thanks.
<Daviey> cjwatson: hey, i wanted to see what you thought about adding X-Fields to .changes files?  Thinking of adding an optional jenkins based gate to the archive to do pre-testing before pushing to the archive.. but want extra data on knowing what to do.
<Daviey> So for example, "X-ON-SUCCESS-UPLOAD: True" or something.. totally useless to LP/Ubuntu, but purely for Jenkins to know if it should push the signed upload to the archive
<dholbach> can somebody please reject https://code.launchpad.net/~vericalcroft/ubuntu/quantal/liborigin/typo-fix/+merge/122417?
<cjwatson> Daviey: Once all the pieces are put together, you should be able to use DEP-8 tests for that, and have that control movement from -proposed - XS-Testsuite: autopkgtest
<cjwatson> Daviey: In the meantime, sure, it's fine to use random X- fields
<dholbach> https://code.launchpad.net/~bmanojkumar/ubuntu/quantal/gluas/typo-fix/+merge/122388 too please
<Daviey> cjwatson: Yeah, we were looking to run DEP-8 tests
<Daviey> cjwatson: ok, thanks.
<cjwatson> XS-Testsuite: autopkgtest is the "official" X- field for that
<dholbach> https://code.launchpad.net/~bmanojkumar/ubuntu/quantal/eikazo/typo-fix/+merge/122386 too please
<cjwatson> And (AFAIK) our jenkins instance is already configured to automatically run tests for any packages that include that
<jamespage> cjwatson, Daviey and I are working on this idea of a build/test pipeline pre-upload
<cjwatson> jamespage: it's on the foundations-p-upload-intermediary plan
<Daviey> cjwatson: so it does that as a reaction to uploads in the archive, rather than pre-testing?
<cjwatson> Daviey: Yeah, we were intending to do it based on -proposed
 * Daviey reads foundations-p-upload-intermediary
<cjwatson> dholbach: done
<dholbach> thanks a lot cjwatson
<dholbach> the next few I'll pastebin
<dholbach> I'm cleaning up the should've-gone-to-Debian ones
<dholbach> and the bug-fixing article with a few examples is online now too
<dholbach> I hope that'll prevent things like this in the future
<Daviey> cjwatson: What would make me a happy bunny is if -proposed had /some/ promise of stability, so people wanting real craziness can run that.. with people wanting a little more stability running the release pocket.
<cjwatson> Daviey: That isn't going to happen
<cjwatson> I mean not with any kind of automatic promise
<Daviey> cjwatson: why can't we consider gating?
<cjwatson> Pre-testing isn't going to help when you can't even install the packages
<Daviey> cjwatson: I mean, catching the real obvious crap that people seem to miss
<cjwatson> Because scope
<cjwatson> This project is already a cycle late
<Daviey> cjwatson: We wanted to do this from a server-dev POV anyway.. But i don't want to duplicate work either.
<cjwatson> Also doing autopkgtest after upload allows you to parallelise the builds required
<cjwatson> If you want to layer some independent stuff on top just for server, be my guest
<cjwatson> Obviously people are entitled to test their uploads as much as they like before pushing them to the archive
<Daviey> right, that was the plan.  If it worked out well, i'd like to welcome others to use the same infrastructure
<cjwatson> In general, I don't want to cause all XS-Testsuite: autopkgtest to use pre-testing because autopkgtest at least sometimes involves building the source package, and I want to be able to do that in parallel with the official builds so that we don't slow everything down too much
<cjwatson> If you can manage some arrangement where developers can opt in on an upload-by-upload basis (perhaps by using a different dput upload target), cool
<Daviey> ok
<Daviey> cjwatson: yeah, that was the plan
<Daviey> so i dput to jenkins, and if it passes, jenkins dputs to the archive for me.
<cjwatson> So that's fine certainly, I just don't want it to turn into "developers are being irresponsible if they don't use this" in time, since there may very well be good reasons not to
<cjwatson> And I don't think it's useful to have an expectation of "<devel>-proposed is usable" since it's solely intended as a location for staging automatic checks
<Daviey> sorry, you mean.. -proposed IS a location for staging automatic checks.. or shoudln't be thought as such?
<cjwatson> It is such a location, and the checks are intended to be such that it really doesn't make sense to "want real craziness" and bypass them
<cjwatson> It would only be interesting to run -proposed if there were a delay, in the style of Debian propagation from unstable to testing - but I think all concerned (especially those with some experience of operating the Debian testing migrator) have agreed we don't want to do that
<dholbach> shadeslayer, do you think you can have a look athttps://code.launchpad.net/~andreagrandi/ubuntu/quantal/kdevelop-custom-buildsystem/typo-fix/+merge/121225?
<xnox> Daviey: upload to $(devel)-proposed, wait for everything to build & settle, (autopkgtests run and give OK), (britney runs & says it's installable and ok to transition), (britney moves the batch into $devel)
<xnox> Daviey: apart from we don't have the bits in () yet....
<cjwatson> I believe we have "autopkgtests run and give OK"
<xnox> ok. cool.
<xnox> one down =)
<xnox> cjwatson: And $devel-proposed, even if you have it enabled does not auto-install from it? (like debian-backports)
<Daviey> xnox: well, that is just a priority.
<xnox> true.
<cjwatson> xnox: There's a work item for that somewhere
<cjwatson> xnox: But see https://code.launchpad.net/~laney/launchpad/proposed-notautomatic/+merge/113921
<cjwatson> bug 1016776
<ubottu> Launchpad bug 1016776 in Launchpad itself "Users are offered updates to packages in -proposed" [Low,In progress] https://launchpad.net/bugs/1016776
<cjwatson> Laney: *poke*
<Laney> cjwatson: argh
<Laney> that
<Laney> it got blocked because I didn't see what to refactor in the area for LoC
<Laney> should look harder
<dholbach> can somebody reject http://paste.ubuntu.com/1190481/?
<cjwatson> Laney: Next time I see something obvious I'll punt it your way, how about that
<cjwatson> Laney: The usual no-imagination answer is to rewrite some doctests as unit tests, which tends to come out positive
<xnox> what is GUdev and how is it different from udisks?!
<davmor2> guys quick query I have a virtual box install in place I've go to additional drivers and I expect to see the vbox addition drivers in there but there is nothing
<davmor2> should it appear there like it did in jockey?
<pitti> xnox: GUdev is a glib wrapper around libudev; it's got nothing to do with udisks
<xnox> pitti: thanks. got mislead.
<pitti> xnox: i. e. it provides GLib main loop integration and an "uevent" signal which you can connect to for listening to hw changes
<pitti> xnox: udisks is the dbus system service for managing disks
<xnox> pitti: any idea why does thunar ignores udisks --inhibit and automounts stuff which it (presumambly) sniffed from uevents.
<xnox> ?
<pitti> xnox: hm, I had expected thunar to call udisks as well -- I'm not aware of another d-bus system service which provides mounting
<pitti> xnox: one thing that could happen here is that we are talking about udisks vs. udisks2?
<xnox> well. ubiquity is run under udisks --inhibit, yet thunar jumps in the middle and automounts partitions breaking the installer "partition is mounted....."
<pitti> xnox: in ubuntu we use udisks2 now, and thunar recommends that as well
<pitti> xnox: ooh -- presumably ubiquity needs to inhibit udisks2, not udisks
<xnox> pitti: i have no idea =) I added a call to xfconf-query to flip automount off. And I presume udisks --inhibit is udisks2
<xnox> pitti: ah =)
<cjwatson> Yeah, probably
<pitti> no, /usr/bin/udisks is udisks1
<cjwatson> http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2008-04-12-desktop-automount-pain.html *whine*
<cjwatson> DEAR EVERYONE PLEASE STOP CHANGING THIS
<xnox> OK, so we should try udisks2, udisks1, devkit-disks, hal........
<pitti> let me figure out the current equivalent
<xnox> pitti: any ETA on udisks3?
<cjwatson> We can probably afford to drop devkit-disks now
<pitti> yeah, and hal as well
<cjwatson> I kept that just in case since the package was still around
<cjwatson> Needs to work on all flavours/derivatives no matter what mad stuff they do ...
<pitti> as soon as usb-creator and checkbox get ported, udisks will fall off the CD
<xnox> pitti: I am hoping to do usb-creator tomorrow as part of Global Jam
<xnox> together with re-packaging to use python3 by default
<pitti> xnox: oh, is that the "Stop thunar from auto-mounting, above didn't work?!" part in ./bin/ubiquity-wrapper?
<pitti> xnox: right, your r5638
<pitti> xnox: so yes, that should be replaced with an udisks2 inhibitor
<xnox> pitti: that does work, but it's not ideal. I really don't want to care about xfce/lubuntu/gtk/kde/etc changing the names of their options.
<pitti> xnox: there is no direct counterpart for this in udisks2, but how about I put a script for this (/usr/lib/udisks2/udisks2-inhibit) into our udisks package?
<pitti> "udisks2" package, I mean
<xnox> pitti: can i stop that dbus service? and restarted when I am done?
<pitti> xnox: my current idea was to change the polkit rules to only allow changes for root, and nobody else
<pitti> i. e. what udisks --inhibit did as well
<pitti> that seems to be the most robust solution to me
<xnox> hmm... is that what udisks did?
<pitti> not with polkit, but with --inhibit it only allowed operations from root
<xnox> it seemed to me that it also made dbus calls to return "inhibited" or something like that.
<xnox> pitti: that should do it.
<pitti> yes, org.freedesktop.UDisks.Error.Inhibited
<pitti> with the temporary polkit rule you'd get a "no permission" error
<xnox> the desktop is started as $user with passwordless sudo, so users could still screw the installer over
<pitti> well, with "sudo command" you can always screw the instlaler
<pitti> no need to talk to udisks, you can jsut directly "sudo mount", etc.
<xnox> pitti: yes, please add that wrapper =) and please don't change it's name =)
<xnox> and we can improve it later.
<xnox> pitti: it would be awesome to have a package $inhibit-any which will inhibit udisk, udisk2, hal and what not =)
<xnox> pitti: cause I'd use it in ubquity, usb-creator not sure about others.
<pitti> just curious that this hasn't been discovered in testing so far
<xnox> oh it has been.
<xnox> the first xubuntu bug is from ~2011
<cjwatson> I think I saw a bug on Ubuntu desktop amd64 from this testing cycle as well
<cjwatson> Though that might be cognitive leakage from something else
<xnox> on Ubuntu Desktop we have default settings in nautilus to prevent automounting, similar to how I now did it for thunar
<cjwatson> Anyway this is the sort of bug that's pretty hard to track down if you don't recognise it
<pitti> xnox: so http://paste.ubuntu.com/1190766/ is my first working iteration
<pitti> xnox: however, not quit happy with the trap yet; I'll change it to an absolutely failsafe approach
<xnox> ok. looks good.
<pitti> oh what would I give for a mount -t tmpfs -o overlay
<ogra_> ++
<BenC> $ dpkg -S /debian
<BenC> ubuntuone-client-gnome: /debian
<BenC> Is that a known issue?
<ogra_> lol
<ogra_> sexy
<pitti> dobey: ^ yay easter eggs!
<dobey> err?
<Laney> indeed
<ogra_> (the shiniest new quantal feature ...  we're turning your rootfs into a sourcepackage you just "dpkg-buildpackage -rfakeroot -b" in / and you get a full backup alread packaged !)
<ogra_> y
<pitti> it's a binary package, though
<dobey> wtf
<iulian> ogra_: Heh.
<ogra_> well, once cjwatson added .deb support to grob that will just work ;)
<ogra_> *grub indeed
 * cjwatson checks 2.00 feature set
<cjwatson> You never know
<ogra_> **
<ogra_> err *g*
<pitti> c'est vendredi, Ã©videmment
<didrocks> pitti: tout Ã  fait! :)
<dholbach> haha
<tkamppeter> pitti, can you upload cups-filters to Debian and to Quantal? Thanks.
<dobey> yay dpkg :-/
<dobey> is the beta release done now so i can upload to quantal?
<pitti> dobey: yes; and you could have uploaded before as well (it'll just get caught in unapproved)
<pitti> tkamppeter: in a bit, sorry
<dobey> right; just don't see a mail to devel-announce
<pitti> xnox: ah, my trick with using unshare -m won't help, I'm afraid (the running polkitd won't see that); so, just tmpfs then
<dobey> BenC: is there a bug for that?
<ogra_> dobey, the release mail was cross posted to -release and -announce
<ogra_> probably your filter dropped into -release (as mine did)
<cjwatson> Exactly why I don't believe in automatic deduplication of mails :)
<dobey> ogra_: i don't think i'm subscribed to -release, and i am not filtering the -announce mail so it should just go into my inbox; but i only see the "beta freeze now in effect mail" :)
<cjwatson> Mm, there's nothing on https://lists.ubuntu.com/archives/ubuntu-devel-announce/
<ogra_> weird
<ogra_> i definitely see it in the mail header
<cjwatson> Oh, -announce, not -devel-announce, perhaps
<pitti> oh, oÃ¹ est xnox?
<ogra_> yup
<cjwatson> There ought to have been a separate mail to -devel-announce that the archive is open again
<cjwatson> Oh well
<dobey> right, i was expecting to see the archive mail :)
<pitti> udisks2-inhibit: http://paste.ubuntu.com/1190807/ ; ugly, but working
<pitti> more pairs of eyes appreciated
<ogra_> well, you could have guessed by the traffic on -changes that its open again :)
<BenC> dobey: I just noticed it, so no bug yet
<dobey> BenC: ok, should i wait for a bug or just fix it?
<BenC> dobey: Would take longer to file the bug :)
<stgraber> dobey: just fix it please
<pitti> tkamppeter: erledigt
<jamespage> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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: jamespage
<pitti> xnox: http://anonscm.debian.org/gitweb/?p=pkg-utopia/udisks2.git;a=commit;h=93ccffecb0
<xnox> pitti: (1.99.0-4) UNRELEASED
 * xnox =(
<pitti> xnox: yes, I just committed it; I want to fix another bug, and will then upload
<xnox> pitti: ping me when it's in quantal =)
<xnox> pitti: I will fix up ubiquity then.
<tumbleweed> dobey: BTW, lintian complains fairly loudly about that. Maybe pay a little more attention to it in future? :)
<pitti> xnox: jsut in case you want to test it locally already
<xnox> ok.
 * dholbach hugs jamespage
<dobey> tumbleweed: complains where?
<xnox> pitti: 'testing ubiquity locally' is not a 30s setup =)
 * xnox is deep in partman right now.
<tumbleweed> dobey: when you run it on the binary. do you run lintian in your test builds?
<pitti> xnox: no worries; I just gave you the URL in case you were waiting for it
<xnox> thank you =)
<pitti> xnox: (I usually test such stuff in a live system and edit files in-place)
<dobey> tumbleweed: it isn't run automatically?
<Laney> lintian your _arch.changes file after test building
<Laney> or configure your build environment to do it for you
<tumbleweed> lintian is run by default when you use debuild. But debuild -S only builds a source package
<dobey> pbuilder/sbuild don't run it by default?
<tumbleweed> pbuilder has an example hook that runs pbuilder after the build. And in sbuild It hink it does it by default
<Laney> no I think it's false by default
<tumbleweed> no, not by default, but you just set $run_lintian = 1;
<dobey> set it where? i found http://askubuntu.com/questions/140697/how-do-i-run-lintian-from-pbuilder-dist which suggests i have to make a new directory in my home directory and copy things to it, then set it as the dir to use in ~/.pbuilderrc
<tumbleweed> that all sounds right
<dobey> and i see dh_lintian being run in the build log for the package, but no complaints from lintian, on lp
<tumbleweed> dh_lintian copyies lintian overrides into a binary package
<tumbleweed> nothing else
<tkamppeter> pitti, thanks.
<dobey> so i guess the archive builders aren't running lintian by default?
<tumbleweed> no. But we do have an external lintian lab: lintian.ubuntuwire.org
<didrocks> can anyone rejects https://code.launchpad.net/~logan/ubuntu/quantal/notify-osd/debian-merge/+merge/118465? thanks :)
<pitti> didrocks: *zap*
 * didrocks hugs pitti
<didrocks> (beautiful zap btw ;))
<pitti> didrocks: do you say "fini" for this, BTW?
<didrocks> I would say "fait" rather
<ogasawara> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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, jamespage
 * dholbach hugs ogasawara :)
<dholbach> it seems to be pilot friday
<hualet> hello, guys, i'm developing an app now, but there's some problem...how can i make the .gschema file installed  while install the software?
<smoser> does this seem wrong to anyone: http://paste.ubuntu.com/1190880/
<jamespage> dholbach, I seem to be following you though bugs
<smoser> err... try http://paste.ubuntu.com/1190881/
<smoser> actually, yes it does seem wrong
<dholbach> jamespage, I stopped :)
<smoser> anyone have thoughts on how to figure out why an apt-get dist-upgrade on a cloud-image would pull in all those packages ?
<zul> mterry:  ping
<mterry> zul, I see it  :)
<mterry> zul, urllib3 right?
<zul> mterry:  how did you guess? :)
<mterry> zul, email wins the race against IRC
<zul> mterry:  yeah sorry im not fast enough
<smoser> there it is.
<smoser> i think
<smoser> bdmurray, your fix for bug 1043725 seems to have added a ton of dependencies to cloud-images
<ubottu> Launchpad bug 1043725 in update-manager (Ubuntu) "dep8 test test_stop_update.TestStopUpdate failed: missing dependency on update-notifier (schema com.ubuntu.update-notifier missing)" [High,Fix released] https://launchpad.net/bugs/1043725
<smoser> http://paste.ubuntu.com/1190881/
<mterry> zul, can you port the patch they had on their embedded urllib3 to our system one and forward on?  It seemed like a generally useful thing
<zul> mterry:  for requests?
<mterry> zul, yeah.  requests had a tiny patch for AppEngine support in their embedded urllib3
<mterry> zul, just diff it with our system one to see it
<zul> mterry: sure
<SpamapS> are there people assigned to making Unity less battery hungry? since updating to quantal my MBA 4,1 has lost an entire hour of battery life. RIP unity2d...
<smoser> SpamapS, that bug is [marked] fixed :)
<smoser> https://bugs.launchpad.net/ubuntu-power-consumption/+bug/917210
<ubottu> Launchpad bug 917210 in unity (Ubuntu) "compiz+unity3d generates > 50 wakeups a second on idle system" [High,Fix released]
<zul> mterry:  are you talking about the ntlm stuff?
<mterry> zul, http://pastebin.ubuntu.com/1190918/
<zul> mterry:  ah ok...i can add that sure
<mterry> zul, just don't want to regress as we move to a system urllib3
<zul> right
<pitti> cjwatson: bug 1039022 says it's being filed from a 64 bit platform; stat(2) says that EOVERFLOW should only occurr on 32 bit platforms; did you file this from the same computer than the one showing the error?
<ubottu> Launchpad bug 1039022 in udisks2 (Ubuntu) "No large-file support?" [Undecided,New] https://launchpad.net/bugs/1039022
<cjwatson> pitti: 64-bit kernel, 32-bit userspace.  Yes I did.
<pitti> cjwatson: aah, missed the Architecture: field; thanks
<cjwatson> Yep, I have a 32-bit installation I don't want to bother reinstalling, but I want to be able to use 64-bit chroots and VMs, so I run a 64-bit kernel with multiarch.
<Daviey> bdmurray: bug 1043725 .. seems to have added gui stuff to server/cloud images
<pitti> fortunately I just created a 32 bit chroot yesterday
<ubottu> Launchpad bug 1043725 in update-manager (Ubuntu) "dep8 test test_stop_update.TestStopUpdate failed: missing dependency on update-notifier (schema com.ubuntu.update-notifier missing)" [High,Fix released] https://launchpad.net/bugs/1043725
<dobey> /tmp/hooks/B90lintian: 6: /tmp/hooks/B90lintian: Bad substitution
<dobey> awesome!
<dobey> :(
<Daviey> smoser: As bdmurray isn't around, Can you back out the fix for 1043725 please?
<cjwatson> dobey: sbuild FTW
<zul> mterry:  ping anything else...im just queueing up the upload for urllib3
<cjwatson> </predictable>
<smoser> Daviey, sure.
<cjwatson> dobey: You could just run lintian foo.changes after your build anyway.
<dobey> cjwatson: automation FTW
<dobey> :)
<mterry> zul, oh I haven't been looking through yet.  If you don't mind just holding on to that until I get to it
<zul> mterry:  yeah i just did a quick check and its using python2 and it runs the testsuite
<cjwatson> dobey: Absolutely, but I assumed if you hadn't already switched to sbuild you must have had some reason
<cjwatson> Given that pbuilder is awful
<dobey> cjwatson: mostly time
<mterry> zul, you server people and your python2!  Living in the past, man
<zul> mterry:  yeah well um...:P
<Daviey> mterry: Did i just hear you volunteer to help port upstream code to py3?  I *think* i did.
<Daviey> zul: did you hear that?
<zul> Daviey: i did...mterry get on it ;)
<mterry> Daviey, it's my foss-given right to bitch at other developers to do work I want to see done
<Daviey> mterry: Hah, yes it is. :)
<bdmurray> smoser: I'm here now are you working on it?
<pitti> xnox: there, have a new udisks2 with an inhibit script: https://launchpad.net/ubuntu/+source/udisks2/1.99.0-4
<xnox> pitti: thanks =)
<smoser> i just branched the source so far.
<smoser> so if you wanted to do that, i'd appreciate it.
<bdmurray> smoser: okay, I'll fix it
 * cjwatson wonders if installing https://code.launchpad.net/~cjwatson/ubuntu/quantal/grub2/2.00 on his laptop on a Friday afternoon is a Really Bad Idea
<cjwatson> Maybe a VM test first would be the path of wisdom
<Daviey> cjwatson: Oh, i thought you were brave.  Just. Do. It.  Man or Mouse?
<Daviey> Unrelated, I just did a dist-upgrade on a Quantal server.. and it complained of FD leaks... now the partition seems fubar'd.  I don't know if it's just hardware failure, or something more serious.
<cjwatson> FD leaks almost certainly nothing to do with anything of importance.
<cjwatson> Daviey: mouse, when it comes to being able to work :P
<Daviey> cjwatson: fdisk exited non-zero on subsequent boot, directly after.  I wondered more if it was an indicator of something more serious.. or just a boring disk failure.. which FD leaks were indicating
<Daviey> *shrug*
<cjwatson> That's not what an FD leak means.
<shadeslayer> dholbach: ofcourse
<cjwatson> It means that some process isn't being tidy about its file descriptors when forking some other process.  LVM likes to whine about this.
<dholbach> shadeslayer, shukria
<xnox> yeah I am annoyed at that myself.....
<shadeslayer> :D
<cjwatson> Once in a blue moon something actually cares (it can break debconf from time to time), but it's very rare and the symptom would be much more likely to be a hang or something, not data corruption.
<xnox> well or python3 really disliking those
<xnox> ev loves fixing leaked FDs =)
<Daviey> cjwatson: right.. I could be entirely wrong.. but I wondered if a disk failing would block an app from closing it's FD.. hence run out?
<shadeslayer> dholbach: there's a new KDevelop release as well
<ev> xnox: :)
<pitti> cjwatson: ah, I also understand it as a long-running process which is missing a close() and piles up open files, so that eventually your user hits the 1024 files ulimit
<Daviey> anyway.. i just found it odd that a box failed to boot.. with that as it's only odd thing before it shutdown.
<wookey> how practical is it to use only python3 in quantal?
<dholbach> shadeslayer, ok cool I'll leave it with you then
<wookey> 3.3 is already multiarched, so wondering if I can just use that for python build-deps rather than finishing mulitarching 2.7...
<Daviey> wookey: As soon as you install someting, you'll probably end up with py2.  The intention was to keep py2 off the cd.. don't know if that has been achieved
<wookey> Any idea how many builds would break due to 2/3 diffreences?
<Daviey> but real world usage, will end up with py2.
<wookey> I am doing this in a forked repo so can change build-deps
<wookey> I'm just wondering if it is at all likely to actually work...
<cjwatson> pitti: Oh, well, it depends on the exact message, but that's usually phrased as "out of FDs" rather than "FD leak"
<cjwatson> Daviey: No, it would not cause that.
<pitti> it's similar to a memleak in that regard
<pitti> anyway, terms...
<mterry> zul, go ahead and upload python-urllib3 with that tiny fix, looks fine to me
<zul> mterry: k...it has a dependency of python-tornado when i just have a MIR for as well
<pitti> meh, defining _LARGEFILE64_SOURCE doesn't seem to do the trick :(
<mterry> zul, yeah I noticed, doing that nxt
<cjwatson> Well.  You can get EIO from close().  But it would be astonishingly rare for the process in question not to fall over somewhere else afterwards; IOW you would certainly not see an FD leak as the only error in this case.
<xnox> wookey: s/python2/python3/ will fail. code needs to be ported to python3.
<xnox> wookey: 3.2 vs 3.3 should mostly work
<cjwatson> pitti: You probably want -D_FILE_OFFSET_BITS=64
<pitti> cjwatson: ah, thanks
<cjwatson> _LARGEFILE64_SOURCE isn't generally your friend
<Daviey> Ah, i think it was bad file descriptor.. not leak.. duh.
<wookey> xnox: OK, that's what I thought, but wondering actually 'most' code might work anyway (for building purposes - I don;t care if it doesn;t install/run properly (much)
<cjwatson> wookey: No.
<cjwatson> Daviey: That usually indicates either a lack of correct error handling somewhere or corruption in some variable, not anything due to disk.
<wookey> OK. I'll finish the 2.7 work then :-) cheers
<cjwatson> wookey: It's possible to write code that works in both >= 2.6 and 3.x if you're careful, but most packages that have gone to that effort have already been ported to 3.x.
<cjwatson> wookey: Anything that hasn't gone to that effort will almost certainly break immediately.
<mitya57> wookey: to _build_ most python packages, you need python2 anyway (as it's rare case when the package supports only 3.x)
<cjwatson> It's not even trying to be a drop-in replacement.
<zul> mterry: done
<cjwatson> wookey: I guess if all the build were doing was shuffling files around then you might get away with it; but many Python packages run tests too.  I doubt the small saving in up-front effort is worth debugging the consequential problems.
<wookey> OK. I was just looking for a possible shortcut to test some other stuff. turning off the tests is easy. (assuming nocheck is properly supported). I think it's mostly done anyway, but I just know it'll fiddly getting it all right (not helped by my exceedingly week python-foo)
<mterry> zul, tornado looks to have some kind of test suite, but nosetest doesn't seem to be the right way to run it.  Do you know how?
<shadeslayer> cjwatson++
<shadeslayer> cjwatson: yer fix works
<zul> mterry:  no i dont
<cjwatson> shadeslayer: Oh good
<shadeslayer> :D
<shadeslayer> cjwatson: what would be the right way to provide ubiquity the release name and what not via live buid though
<cjwatson> wookey: Oh, in any case it will probably be explicitly using dh_python2 and the python3 packaging doesn't provide that.
<shadeslayer> oh wait
<shadeslayer> I can just put it in the binary folder
<shadeslayer> and it'll end up on the binary ISO
<cjwatson> shadeslayer: It should be picking it up from .disk/info on the image, which is written by lb_binary_disk.
<cjwatson> Wait, is that right
<cjwatson> Yeah
<cjwatson> Just make .disk look vaguely like Ubuntu images
<shadeslayer> right, my question is how? :P
<shadeslayer> is there a config option in live build for that?
<zul> mterry: server team is subscribed to the bug reports for both tornado and urllib3 btw
<mterry> zul, cool.  I just added a comment to the tornado mir on how to run the test.  It should be enabled
<zul> mterry: ack
<cjwatson> shadeslayer: I don't know.  You'll have to investigate for yourself, I'm afraid.
<cjwatson> I've moved on from live-build stuff and am trying to sort out grub2 now.
<xnox> wookey: it will fail at ./debian/rules build, if not at resolving build-deps
<mitya57> wookey: check http://developer.ubuntu.com/packaging/html/python-packaging.html if you need help with python packaging
<shadeslayer> cjwatson: yeah np :)
<shadeslayer> thanks for your live build fixes however
<cjwatson> mitya57: I suspect wookey is working on cross-building, not packaging
<cjwatson> I note that the debian/rules advice for Python 3 in that page is wrong
<mitya57> cjwatson: which one?
<zul> mterry:  adding
<cjwatson> It will result in programs with #!/usr/bin/python3.2
<cjwatson> (http://developer.ubuntu.com/packaging/html/python-packaging.html)
<dobey> cjwatson: how does one avoid that?
<cjwatson> You need something like https://bazaar.launchpad.net/~ubuntu-core-dev/software-properties/main/revision/794
<cjwatson> Or you can look at germinate's debian/rules if you need to support both Python 2 and 3
<dobey> hrmm, the suggested (documented) method also doesn't work on natty; but that may be a packaging issue with python3.1 there
<cjwatson> Worrying about Python 3 on natty is a waste of time
<dobey> yeah, i just noticed it in my nightlies builsd
<dobey> builds
<cjwatson> (Actually, software-properties supports Python 2 as well, but it doesn't have an override_dh_auto_test target so doesn't need to worry about the same things that germinate does)
<zul> mterry: i dont think tornado testsuite is python3 ready yet http://pastebin.ubuntu.com/1191038/
<mterry> zul, that's weird.  That's a line of code from tornado proper, which otherwise seemed pretty ready for python3
<mterry> zul, (testing.py is a feature of tornado for writing test suites, which its own suite uses)
<zul> mterry: odd
<mterry> zul, if you change that one line is everything else fine?
<mterry> wondering if that's just a small typo or a larger problem throughout
<zul> mterry: i havent gotten that far yet (checking the tornado git tree)
 * cjwatson files bug 1047457 for the above
<ubottu> Launchpad bug 1047457 in Ubuntu Packaging Guide "python-packaging.html will result in incorrect #! lines for Python 3" [Undecided,New] https://launchpad.net/bugs/1047457
<zul> mterry:  can we accept on the condition that testsuite will be enabled and possibly fixed after?
<mterry> zul, possibly.  If it's harder than that one fix, we can delay on the python3 one.  But we might as well enable the python2 tests now
<zul> mterry: ok
<zul> lemme poke at it
 * cjwatson laughs at https://launchpad.net/ubuntu/+source/firefox/15.0.1+build1-0ubuntu2
<mdeslaur> lol
<zul> mterry:  testsuite ftbfs in a chroot
<mterry> :(
<mterry> zul, it needs internet access?
<zul> mterry: http://pastebin.ubuntu.com/1191051/
<mterry> Just one test! So close
<dobey> hrmm
<mterry> I wonder why that would be different in a chroot
<dobey> if you do dh --with python3,python2 instead of python2,python3, will it run the setup.py install with python2 last?
<cjwatson> No, debhelper has no code to run setup.py install with python3 at all right now
<zul> mterry:  probably because it does some io thingy
<cjwatson> Which is why we still need overrides for that
<cjwatson> So you write your overrides to call the underlying dh_auto_* either first or last depending on what you want to do
<mcclurmc> is there a way to do a requestsync from a launchpad PPA into quantal universe?
<cjwatson> lifeless: I'm not quite ready yet, but do you think at some point you might be able to retest a PPA grub2 in quantal on the system where you encountered bug 803658?  Forward-porting that patch to 2.00 was non-trivial, and I dropped a piece which no longer applies and which I *think* is now unnecessary but I'm not totally susre.
<ubottu> Launchpad bug 803658 in grub2 (Ubuntu) "grub-install /dev/mapper/isw_$UUID_$NAME0 failing with ICH10R raid 1+0" [High,Fix released] https://launchpad.net/bugs/803658
<cjwatson> mcclurmc: No, but if you write it out by hand then somebody with upload access can sync it for you.
<mcclurmc> as in, write it out in IRC, right here?
<cjwatson> Well, if they know how :-)  syncpackage won't do it
<cjwatson> I meant in a bug really
<mcclurmc> yeah, i've filed a bug
<cjwatson> Is the PPA package not versioned in a PPAish kind of way, though?
<mcclurmc> just marked it "committed"
<mcclurmc> yes, it's got ~quantal on it
<cjwatson> That's not normally appropriate for uploads to the archive
<mcclurmc> so probably not good to sync as-is
<mcclurmc> yea
<cjwatson> Maybe just get somebody to reupload
<mcclurmc> okay, should i email the ubuntu-server list? (it's a server-ish package)
<cjwatson> Subscribe ~ubuntu-sponsors to the bug
<mcclurmc> okay, thanks
<jamespage> mcclurmc, or just ask a pilot - which bug?
<cjwatson> Or that, yeah
<mcclurmc> #1028135   https://bugs.launchpad.net/xcp/+bug/1028135
<ubottu> Launchpad bug 1028135 in XCP "blktap-dkms links to missing symbols in kernel 3.5" [Critical,Fix committed]
<mcclurmc> what's a pilot? like an MOTU?
<dobey> hmm
<jamespage> mcclurmc, patch pilot - reviewing the sponsorship queue and sponsoring things/providing feedback
<cjwatson> see /topic
<dobey> cjwatson: would running dh_auto_install after all the python3 installs, result in it running the install with python2 last? (which i guess implies that page is wrong in that respect as well then as the resulting package would still default to /usr/bin/python for any scripts)
<mcclurmc> jamespage: ah, i see ;)
<dobey> hmm; what was that wiki page where i got the py3 packaging info from that i used in dirspec :-/
<dobey> ah
<dobey> http://wiki.debian.org/Python/LibraryStyleGuide
<dobey> which is yet again slightly different
<tumbleweed> there's more than one way to skin a cat :)
<jamespage> mcclurmc, is this likely to land in experimental in Debian first - or are you targetting Ubuntu as we have the 3.5 kernel?
<mcclurmc> the latter. when i started work on this bug, 3.5 wasn't yet in experimental
<jamespage> ack
<tumbleweed> dobey: but yes, that approach will have the same problem.
<mcclurmc> i'm going to be working with my debian maintainer to get it in experimental, if experimental is ready for that
<dobey> tumbleweed: in that the final "install" run will be with python2?
<tumbleweed> dobey: will be run by python3.X
<tumbleweed> rather than python3
<dobey> tumbleweed: wouldn't the way dependencies are handled result in plain dh_auto_install being run last? and would that not run with python2 since it doesn't do the python3 bits automatically?
<jamespage> mcclurmc, OK - so we need to stuff a 0ubuntu1 release into it somehow so syncs/upgrades work in the future
<tumbleweed> dobey: I can't parse that
<mcclurmc> jamespage: do you mean in the version number in the PPA?
<jamespage> mcclurmc, almost
<dobey> tumbleweed: override_dh_auto_install: $(PYTHON3:%=install-python%) <- this says the "install-python%" rule is depended on by the override_dh_auto_install, so the "install-python%" for every version of python3 would happen first, and then dh_auto_install would run last; and since dh_auto_install does not handle python3 automatically (hence the overrides for it, but not for python2), it will run the install step with python2, an
<cjwatson> dobey: If you have an override_dh_auto_install target that runs dh_auto_install and then your additional commands to run setup.py install with python3, then that will work
<mcclurmc> jamespage: lol. let me know what i need to do (if it's something i have control over)
<tumbleweed> dobey: that clipped at "python2, an"
<dobey> cjwatson: and running dh_auto_install last will result in scripts being installed with python2, right?
<tumbleweed> dobey: the problem isn't wit hthe python2 / python3 ordering. It's simply that you need to do the install with python3. dh_python3 doesn't correct shebangs any more
<dobey> tumbleweed: "python2, and it will run last, no?"
<mitya57> cjwatson: will "s/PYTHON3=$(shell py3versions -r)/PYTHON3=$shell py3versions -r) python3/" be sufficient?
<tumbleweed> or am I missing something. Do you have scripts that you are only installing with python3?
<xnox> mitya57: should be.
<dobey> tumbleweed: right, to install the files in the python3 dir it has to be run with python3; but what i want is to install the library code with python2 and python3, but have the scripts that are installed, have "#!/usr/bin/python" so they are still python2
<cjwatson> mitya57: I think it's distinctly preferable to avoid calling the default one there, as my rules do.
<dobey> tumbleweed: and verify that dh_auto_install running last would mean that
<cjwatson> mitya57: I think that there is some odd corner-case bug that happens if you don't do that.
<tumbleweed> dobey: ok. I misunderstood. sorry
<cjwatson> dobey: Whichever one installs scripts last will win, yes.
<tumbleweed> I tend to do this without using debian/tmp, but just installing straight into debian/pythonX-foo
<dobey> cjwatson: and dh_auto_install currently will *always* be with python2, correct?
 * tumbleweed shuts up and stops confusing people
<mitya57> cjwatson: your rules have python3 at the end:
<mitya57> PY3 := $(filter-out $(PY3DEFAULT),$(PY3REQUESTED)) python3
<cjwatson> mitya57: I spent quite a while trying to get this right in germinate and settled on what I have, so I can't say I'd recommend changing that.
<cjwatson> mitya57: Yes.  But they filter out the default version (py3versions -d) from the output of py3versions -r, which is important.
<cjwatson> dobey: Yes.
<mitya57> cjwatson: ah, I'll just copy that line
<mitya57> should the same be done for $(PYTHON2)?
<tumbleweed> dh doees the same thing for python2
<cjwatson> In general you don't need to because debhelper already handles Python 2.
<cjwatson> If you need to list Python 2 for some reason (e.g. tests) then, yes, you need this.
<tumbleweed> it doesn't matter whether you run tests with python2.7 or python, thugh
<dobey> cjwatson: then for the purposes of at least Ubuntu, that developer.ubuntu.com page is also wrong in that respect, as it seems we'd want the general case to be having the scripts installed with python3 last.
<cjwatson> tumbleweed: No, but IIRC if you run them with python2.7 sometimes it can end up sticking that in #! lines and being hard to convince otherwise later.
<dobey> cjwatson: i guess perhaps fixing your other complaint to follow the example you linked may also fix that, so long as the dh_auto_install and dh_auto_build are moved to be the first in the list
<cjwatson> dobey: Depends on the audience.  A lot of the people reading developer.ubuntu.com will be developing for 12.04.
<tumbleweed> cjwatson: yaeh. checking the substituted depends is always a good idea
<dobey> cjwatson: then perhaps even further clarification is needed on that page, for this. :)
<cjwatson> /usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm:setup_py is the implementation of this in debhelper.
<cjwatson> dobey: Perhaps.  Other pages are probably better at explaining how to handle Python 3 ...
<dobey> perhaps. i just noticed it when i saw the page, so thought i'd mention it.
<dobey> anyway, thanks :)
<dobey> need to go to lunch and an appointment now though
<mterry> infinity, you have a couple small changes queued up in unity's packaging branch.  I'm assuming they are OK for release?
<xnox> mvo: did you see debtagshw python3 port bug/patch? did you have time to review it or not yet?
<smoser> slangasek, ping.
<infinity> mterry: Those changes were me bringing the branch in line with the archive, I believe.
<infinity> mterry: (ie: if you build from the branch and then debdiff with the archive, you'll find they're not "changes" at all)
<mterry> infinity, ah..  OK, thanks
<cjwatson> Oh, I remember what the problem that caused there to be a splash screen on server was.  The live-build refactoring has made it difficult to install the kernel without Recommends ...
<mvo> xnox: I saw it but didn't really review it yet, sorry, I put it on my list for monday, ok?
<xnox> mvo: ok.
<jamespage> cjwatson, is that something that is fixable?
<cjwatson> Or maybe this was always a problem and it just didn't matter for desktop.
<cjwatson> jamespage: It's all software, it's fixable
<cjwatson> I just need to think very hard :-)
<cjwatson> Probably broken by the move to squashfs-base, then, thinking about it.
<jamespage> cjwatson, I think the oversized minimal-virtual problem is probably caused by that as well - bug 1028453
<ubottu> Launchpad bug 1028453 in ubuntu-meta (Ubuntu) "Quantal Ubuntu Server minimal install oversized" [High,Confirmed] https://launchpad.net/bugs/1028453
<cjwatson> You think?  It doesn't cause that much of a size increase.
<cjwatson> Well, it means you unnecessarily get kernel heads.
<cjwatson> *headers
<cjwatson> Ah, wrong kernel might make a difference, sure
<cjwatson> Mind if I take that bug?
<jamespage> cjwatson, please do
<jamespage> the automated testing validates 1) kernel == virtual 2) no ubuntu-standard and 3) the kernel module size is below 40M
<jamespage> http://testcases.qa.ubuntu.com/Install/ServerMinimalVirtualInstall
<cjwatson> I think perhaps the solution is to build with --linux-packages none and then install the (correct) kernel packages later in a hook or something.
<jamespage> cjwatson, that might work better I think
<cjwatson> Oh, you need kernel == virtual, hm
<cjwatson> live-installer doesn't have kernel installation support right now
<cjwatson> I guess that's fixable too
<jamespage> cjwatson, yeah - but in todays kernel world its all the same base kernel right? we just drop some default modules for minimal-virtual
 * jamespage wonders at his over-simplification of the world sometimes....
<Daviey> jamespage / cjwatson: Server without kernel headers sucks.
<Daviey> please keep them.
<Daviey> dkms often did the wrong thing.
<jamespage> Daviey: dkms always does the wrong thing with virtual
<jamespage> I had pain with this for the mininet/openvswitch work I did this cycle
<jamespage> Daviey, should we not really be maintaining the status quo for minimal-virtual and deciding what we should do with it at UDS for next release :-)
<cjwatson> jamespage: It may be but it's a hell of a lot easier to have live-installer install the right one rather than to try to remove bits
<cjwatson> jamespage: the status quo is wrong in ways other than minimal-virtual
<cjwatson> What did minimal-virtual do wrt kernel headers in precise?  That's a more interesting status quo
<jamespage> cjwatson, I don't believe it installed any kernel headers
 * jamespage looks at the preseed
<Daviey> yes, that is correct
<Daviey> Oh, wait.. precise.. don;t know.. pre-precise.. it did not.
<Daviey> dkms used to look for linux-headers-server.. but dkms installed -generic headers... symlinks all wrong. :)
<cjwatson> Well, base-installer can install kernel headers or not, controlled by a preseeded question
<cjwatson> So it's trivial to do either if live-installer calls the right function
<jamespage> "d-i	base-installer/kernel/headers	boolean false"
<cjwatson> Exactly
<slangasek> smoser: hey there
<smoser> so lets just say that i was kind of stuck... what options do i have for massaging/forcing virtual-filesystems event to occur before mounted / ?
<cjwatson> I'm fine with dropping that preseed if you guys think it works out better
<cjwatson> Not wild about waiting for UDS if it's wrong
<jamespage> for referehnce http://paste.ubuntu.com/1191181/
<jamespage> utlemming, do we install headers by default in the cloud images?
<jamespage> I could check but feeling lazy
<smoser> slangasek, i seem to be hitting the bad path for me consistently in our "ephemeral images" (which do iscsi overlay root).
<utlemming> jameaspage: yup
<slangasek> smoser: joy
<smoser> i'm not certain that I *wasnt* hitting it before. it might have just happened to have been not so painful due to broken /etc/resolv.conf link in the imgaes.
<smoser> joy of joys is that this is precise where i really need to fix it.
<jamespage> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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
<slangasek> smoser: we can have a look at the necessary mountall changes next week, but definitely no sooner; and this is such a major semantic change that it would need to cook for a bit before going to SRU
<jamespage> cjwatson, I would +1 installing headers just to make it consistent with the cloud-images
<cjwatson> Righto
 * jamespage puts them in the same class for some reason...
<smoser> slangasek, i agree to that.
<smoser> but, lets say i was *really* stuck
<jamespage> thanks for that utlemming
<Bluefoxicy> man somebody needs to fix printing.
<Bluefoxicy> Print from chrome:  single sided
<Bluefoxicy> print from Evince:  duplex.
<Bluefoxicy> Cannot find an option anywhere.
<smoser> although un-maintainable... how might i go about figuring out which things i need my initramfs to mount before executing init.
<jamespage> smoser, FYI see above for conversation re minimal-virtual install - cjwatson took the bug
<smoser> i know of /lib/init/fstab, but how do i determine which of these are "virtual" and which can be ignored (ie, my system has no 'spu' mount).
<slangasek> smoser: parse /lib/init/fstab; for each filesystem there that has a filesystem of 'none', look if there are any overrides in /etc/fstab and incorporate them, then mount the filesystem
<Bluefoxicy> oh for christ's sake
<smoser> jamespage, right. i saw, and happily lurked. thanks.
<Bluefoxicy> what moron removed the option to actually select a printer driver when adding a printer?
<smoser> slangasek, how about "spu" ?
<Bluefoxicy> It just adds it as "generic PCL6 printer"
<slangasek> smoser: those are marked 'optional' in the mount options
<smoser> what does optional mean?
<smoser> try and if no fs support just go on with life ?
<slangasek> smoser: so if the mount point doesn't exist, or the point exists but the mount fails, mountall ignores; but in your case you should ignore *all* failures and just get on with it
<smoser> slangasek, thank you.
<smoser> can you think of a better idea than this?
<slangasek> smoser: well, I'm worried about whether this is even guaranteed to solve your problem
<smoser> well, i think it will.
<slangasek> smoser: basically, mountall *has* to emit virtual-filesystems before it emits mounted MOUNTPOINT=/
<smoser> because if mountall finds alll virtual-filesystems mounted, and work to do on /
<slangasek> and while getting the virtual filesystems mounted from the initramfs helps with this, I don't think the order is guaranteed
<slangasek> smoser: it's probably deterministic in practice, so I'd say test it and see
<slangasek> but there's a chance the deterministic order is still not the order you want :P
<smoser> right.
<smoser> start on starting mountall .... emit virtual-filesystems
<smoser> :)
<smoser> yuck.
<smoser> thanks for your help, slangasek and i'd appreciate and chan offer some help with a less hackish fix.
<slangasek> smoser: heh, well, you could do the emit virtual-filesystems from the cloud-init-nonet job instead
<smoser> right.
<smoser> after knowing that the initramfs fixd it
<smoser> that would work too
<slangasek> and that would replace the need for calling 'start networking', and be slightly less hackish
<slangasek> the next step after that would be to have one of the cloud-init jobs *do* the mounting, instead of doing it in the initramfs
<slangasek> which gives a tighter guarantee you're not emitting the signal incorrectly
<smoser> well, i could just not emit blindly
<smoser> do you think thats worth pursuing ?
<smoser> over the initramfs solution?
<slangasek> I think it's better to do it in-line in your upstart job, yeah
<slangasek> that way there's 0 risk of initramfs skew breaking things on you
<smoser> and how to avoid emitting if already emitted ?
<slangasek> shouldn't matter
<smoser> i guess a job that starts on it
<smoser> and marks.
<smoser> but ok. that can be sorted out.
<smoser> thanks slangasek
<slangasek> in practice, a double emit of v-f will cause a couple of spurious double-runs of jobs, but that's it
<smoser> but it shouldn't be too hard to determine
<smoser> oh..
<smoser> bu tyoure saying that even if all that stuff was already mounted the event might not have been emitted.
<cjwatson> Daviey: So of course fixing minimal-virtual is going to make the installation a bit slower again, because I'll have to pull standard and server out of the squashfs and have them installed from .debs
<smoser> ok. i'll go play now.
<slangasek> smoser: because mountall might process / before one or more of the virtual filesystems and thus deadlock the virtual-filesystems event, yeah
<cjwatson> Daviey: It'll still be quicker than precise, and I suspect (but haven't checked) that standard and server make up a relatively small percentage of the time taken; but thought it was worth mentioning
<smoser> cjwatson, Daviey do we have *any* data on how much faster our squashfs install is?
<cjwatson> I did some ad-hoc experimentation at the time
<cjwatson> I forget the results :-)
<cjwatson> It was maybe a minute or two faster in my VM?
<smoser> i think percentage improvement would be more useful than "1 minute"
<cjwatson> I think it was on the order of 5 -> 3 minutes for base system install, or something like that.  May be wrong.  Memory unreliable.
<cjwatson> Yeah I know, but I don't have details
<cjwatson> Would be easy enough for somebody to try
<smoser> yeah, just trying to know how slow your vm install was. cause 1 minute out of 120 isn't much.
<smoser> it would.
<smoser> i was just wondering if someone already did.
<smoser> anyway, thanks, cjwatson
<cjwatson> Maybe more like 10/15 minutes for the full VM install end to end.  Something like that.
<cjwatson> Real hardware's more interesting for this anyway.
<Daviey> cjwatson: FWIW, i'm not sure how much i care about minimal atm
<Daviey> Can we discuss this Monday?
<xnox> what is /etc/init.d/hplip ?
<cjwatson> Daviey: *shrug* I'm probably going to make at least some of these changes anyway because they're clear regressions from precise, particularly the business about grub-pc being in the squashfs
<xnox> or more precise what was hplip and what has it become?
<cjwatson> Daviey: I'd rather get to a non-regressed state and then we can discuss what you do and don't care about from there
<Daviey> cjwatson: ok, thanks
<stgraber> ev: hey, a friend of mine just started hitting bug 991481 on 12.04, any idea what the problem might be?
<ubottu> Launchpad bug 991481 in whoopsie-daisy (Ubuntu) "Constant dns traffic for daisy.ubuntu.com" [Undecided,Confirmed] https://launchpad.net/bugs/991481
<smoser> anyone know why i have more than one udevd running on a system?
<smoser> seems like i have about 3 "normally"
<lamont> so I have some questions
<lamont> 1) while it's funny, I'd just as soon not clutter up the panel with all of the proc and pts and shmmem filesystems mounted under the various build chroots... can that be configured?
<lamont> (quantal beta)
<lamont> 2) wtf have I and resolvconf and dnsmasq done to my system such that it fails to resolve hostnames?
<slangasek> lamont: I presume what you have done is failed to fix the bug I filed against bind9 asking for it to properly dis-integrate from resolveconf on upgrade ;)
<lamont> slangasek: that could well be
<lamont> slangasek: execpt that my /etc/default/bind9 has RESOLVCONF=no
<slangasek> ah
<slangasek> lamont: so you are running bind9, but also have dnsmasq?
<lamont> so... what have done:  dnsmasq.conf has listen=127.0.0.1, bind_interface (or so)
<lamont> network mangler believes that it owns the devices
<smoser> slangasek, so why do i not have /run/user mounted?
<slangasek> smoser: have you rebooted since upgrading mountall?
<smoser> ah. no then.
<slangasek> smoser: I suppose I could make mountall do a run from the postinst or something to get it mounted
<lamont> and then resolvconf redirects us off to 127.0.0.1, and well, there is not happiness
<smoser> that was newly added. that makes sense. i was just testing my "what to mount" code, and it thought it should mount that.
<slangasek> smoser: right :)
<slangasek> lamont: so dnsmasq is misbehaving?  Is it running, does it have sensible config?
<slangasek> (cat /var/run/nm-dns-dnsmasq.conf)
<lamont> slangasek: I believe that it is actually bind misbehaving due to listen-on-v6 { any; }; and thereby hijacking dnsmasq's love
<slangasek> ah
<lamont> the file /var/run/nm-dns-dnsmasq.conf is empty
<slangasek> mine too
<slangasek> and I think that's a bug
<lamont> grep ^listen /etc/dnsmasq.conf; lsof -ni :53 | grep dnsmasq.*127
<lamont> listen-address=127.0.0.1
<lamont> dnsmasq 3276          nobody    4u  IPv4  15900      0t0  UDP 127.0.1.1:domain
<lamont> dnsmasq 3276          nobody    5u  IPv4  15901      0t0  TCP 127.0.1.1:domain (LISTEN)
<lamont> help me understand why 127.0.1.1 is so much better than WHAT IT WAS TOLD TO DO
<slangasek> /var/run/nm-dns-dnsmasq.conf is supposed to be the config that lists dnsmasq's forwarders
<slangasek> lamont: oh, er, which dnsmasq.conf did you put this in?  Because NM configures its own instance
<lamont>  /etc/dnsmasq.conf
<slangasek> the system dnsmasq.conf is used for something else (or rather, for nothing, in the stock config)
<slangasek> lamont: see network-manager changelog, 0.9.6.0-0ubuntu4
<lamont> slangasek: this is all prompted by the simple need to be able to have BIND run, while still somehow not throwing out everything that distro has done to help the world be better by providing everyone with dnsmasq so that they don't need a local resolver
<slangasek> the 127.0.1.1 is there *specifically* to avoid conflicts with other DNS servers...
<slangasek> cyphermox: ^^ maybe you and lamont want to talk :)
<smoser> slangasek, and what about /tmp ?
<smoser> oh. type is 'none'. so that just means "skip" ?
<slangasek> smoser: oh yes - the 'none' in the <type> field means "ignore this unless you find it defined in /etc/fstab"
<smoser> ah.
<smoser> k
<lamont> slangasek: the launcher thingy on the left side of my screen... any thoughts on (a) getting rid of all the proc and such filesystems mounted in the chroots, or (b) wtf the package is and the thingy is, so that I can file a bug?
<slangasek> lamont: udisks2
<cyphermox> lamont: what's the full command line for that process 3276? it should have been started by NM
<lamont> t
<lamont> s
<lamont> ta, even
<slangasek> lamont: I haven't seen this behavior myself - the only wrong disk I get shown there is one of my NFS mounts that's mounted at boot time (chosen, AFAICS, at random from the set of NFS mounts)
<lamont> grep -c ^proc /proc/mounts
<lamont> 6
<lamont> interestingly, I only get 3 of tem
<lamont> them
<lamont> cyphermox: it was
<lamont> OTOH, resolvconf then happily tells resolv.conf that we should query 127.0.0.1
<cyphermox> if dnsmasq is configured and running, yeah
<cyphermox> I mean, as started by the init script
<lamont> Sep  7 13:04:22 rover3 dnsmasq[2245]: using nameserver 127.0.0.1#53
<lamont> otoh, there is no listner
<lamont> this is after "service dnsmasq restart"
<cyphermox> lamont: so dnsmasq has to be writing something to syslog saying it can't start
<lifeless> cjwatson: that machine is still on precise; if I can install just grub2 from the ppa and give it a spin, sure.
<smoser> slangasek, do you know why i commonly have more than one "udevd --daemon" running?
<lamont> dnsmasq   9239  0.0  0.0  31064   960 ?        S    13:08   0:00 /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -r /var/run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new
<smoser> it appeared that multiple 'virtual-filesystem' events will cause more of these, so i wondered if more than one would be bad. turns out i'm already running more than one.
<lamont> and no udp sockets open
<cyphermox> lamont: ok. is listen-address the only thing set in your dnsmasq.conf?
<cyphermox> because bind-dynamic would do this kind of thing I think; just wait until it's able to start and claim a port
<lamont> grep -ve ^# -e ^$ /etc/dnsmasq.conf
<lamont> listen-address=127.0.0.1
<lamont> bind-interfaces
<cyphermox> oh wait
<cyphermox> /etc/dnsmasq.d/NetworkManager
<cyphermox> drop except-interface
<cyphermox> I really need to remove that one from the config file
<lamont> oh hey look.  something on 127.0.0.1
<lamont> and resolution
<lamont> cyphermox: is this a bug I should file?
<cyphermox> lamont: the issue is the default dnsmasq setup needs that except-interface, otherwise it tries to bind on all interfaces IIRC
<cyphermox> yeah, file a bug against network-manager, I'll set this up again and try to see if there is a saner setting to keep
<lamont> cyphermox: so are you telling me that the desktop install now has the very issue that I ran into as a bind developer?  and we solved it in a totally wrong way?
<cyphermox> what issue|
<cyphermox> the big issue here is that dnsmasq has a setting where it just binds to 0.0.0.0:53 by default when 'dnsmasq' (not -base) is installed, so there is just no way to start any other instance of dnsmasq
<cyphermox> and what we're trying to make sure is that if you want to run dnsmasq on your system you can, and we don't break that default setup at least
<slangasek> smoser: udev spawns worker threads
<lifeless> cjwatson: its not impossible that I'll upgrade it to quantal v. soon, but it needs the proprietary ati drivers, and it needs to work, so I get rather protective of its availability.
<smoser> but if i just run another one 'sudo udevd --daemon' it will stick around also
<slangasek> smoser: sure, but it's the udev upstart job that does the locking
<slangasek> so when you start it manually you're bypassing the standard mechanism
<smoser> i dont see locking in /etc/init/udev.conf
<slangasek> smoser: the job *is* the lock
<slangasek> if the job is running, a second isn't started
<smoser> ah.
<smoser> k.
<ev> stgraber: blame gnetworkmonitor
<SpamapS> or canada
<slangasek> SpamapS: essentially the same thing, gnetworkmonitor *is* Canadian after all
 * SpamapS should have known by all the use of 'eh' in the man page.
<lamont> who understands unity3d window title bar decorations?
<xnox> lamont: isn't it plain compiz?
<lamont> xnox: could be...
<xnox> hence changing gtk theme makes no difference to it.....
<lamont> I'm trying to undo something I did to that configuration back in natty time
 * xnox giggles
<lamont> and ccsm isn't helping me
<xnox> lamont: unity --reset ?
<lamont> is there a way to see what it will undo before I do that?
<xnox> lamont: apt-get source unity ?
<lamont> heh
<lamont> remind me how to have focus-follows-mouse instead of click-to-focus/
<xnox> lamont: impossible
<xnox> lamont: due to global menus
<xnox> lamont: i guess we do have HUD now.... but still impossible
<lamont> xnox: then if unity --reset is going to turn that off, then I definitely don't want to run that command
<infinity> Global menus can be disabled.
<lamont> infinity: and worked around
<infinity> Which is a bit of a prereq for FFM.
<jbicha> unity --reset doesn't work in quantal by the way
<lamont> infinity: nah... dragging the window to the top-panel when you care, is enough
<lamont> mostly, I just use the keyboard shortcuts for menus
<lamont> jbicha: NICE
<lamont> jbicha: is there a bug filed for that?
<xnox> lamont: keyboard shortcuts vs hud?
<jbicha> lamont: not exactly a bug but https://code.launchpad.net/~didrocks/unity/unity-reset-removal/+merge/123112
<lamont> jbicha: interesting
<smoser> slangasek: http://paste.ubuntu.com/1191536/
<ScottK> lamont: I guess you're safe from unity --reset turning anything off.
<lamont> ScottK: HAHA
<YokoZar> Is archive skew still a thing in Quantal?  I'm wondering if it could be responsible for https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/1016294  (ie, unequal i386/amd64 libraries)
<ubottu> Launchpad bug 1016294 in ia32-libs (Ubuntu) "ia32-libs-multiarch but it is not installable " [Undecided,Confirmed]
<infinity> YokoZar: It can still happen, yeah, most library uploads don't go through proposed yet.
<xnox> anybody knows a good book about dbus......
<xnox> ?
<ogasawara> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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:
<slangasek> YokoZar: if you're talking about bug #1016294 that you just commented on, no, libnspr4 hasn't had an upload since December 2011.
<ubottu> Launchpad bug 1016294 in ia32-libs (Ubuntu) "ia32-libs-multiarch but it is not installable " [Undecided,Confirmed] https://launchpad.net/bugs/1016294
<slangasek> YokoZar: at this point, the incidence of actual archive skew is so low that reports of ia32-libs uninstallability are almost always due to users having broken local libraries installed, and these reports are generally not worth pursuing
<YokoZar> slangasek: ahh fair enough.  Do we plan on phasing out the ia32-libs-multiarch metapackage in general?
<slangasek> YokoZar: at some point, yeah; I'm not in a hurry
<slangasek> we should probably wait until Debian has a multiarch release before really pushing aggressively for it
<YokoZar> reasonable
<cjwatson> lifeless: not sure what shlibdeps will be like; it might only be necessary to create a quantal chroot, bind-mount /dev /proc /sys, upgrade grub-pc et al from PPA, and run the grub-probe command you quoted in the bug
<lifeless> cjwatson: anyhow, drop me a whinge when its ready.
<lifeless> cjwatson: if you feel kind, toss a build at /precise in the ppa just in case it works
<cjwatson> mm, there's *probably* no reason it wouldn't
<cjwatson> about to upgrade it on my laptop, let's see
<cjwatson> Looks plausible in kvm -snapshot
<tjaalton> 4Ã¢
<tjaalton> wha
#ubuntu-devel 2012-09-08
<smoser> slangasek, around ?
<smoser> http://paste.ubuntu.com/1191848/
<smoser> so it seems like 2 issues. a.) network is already up, so i think ifup decides it doesn't need to bring the network up, and b.) mountall doesn't like me doing mounts for it.
<slangasek> smoser: how do you mean, "network is already up"?
<smoser> iscsi root.
<smoser> it came up in the initramfs
<slangasek> smoser: right; ifupdown doesn't consider that "up"
<smoser> hm..
<slangasek> to ifupdown, it's only up if ifup has been called
<smoser> i'd have thought.
<slangasek> which is not to say that the network already being up can't be causing problems for ifupdown
<slangasek> or maybe iscsi even injects state?
<smoser> injects state?
<smoser> hm..
<slangasek> smoser: yes, as in, perhaps the open-iscsi initramfs script scribbles something in /run to tell ifupdown to under no circumstances bounce the interface
<smoser> i dont think so.
<smoser> but clearly it cannot bounce the interface.
<smoser> but i dont know what i thought was wrong. about mountallnot liking me
<slangasek> smoser: dunno... there's some noise about filesystems already mounted, but coincidentally these are all optional mounts
<slangasek> smoser: looks like mountall itself succeeds, it's just the network not happening
<smoser> right.
<smoser> it was the "busy" stuff that i was confused by.
<smoser> i'll look foranything iscsi might be doing to protect
<smoser> or maybe ifupdown somehow just "knows"that it has non-local filesystems
<smoser> although it appears to have tricked mountal
<slangasek> smoser: should I be seeing full upstart logging here?  there's nothing after 37.584470, at which point udev has not actually succeeded in starting and therefore ifupdown is not being triggered
<slangasek> smoser: upstart-udev-bridge is 'start on starting udev'; it never completes
<slangasek> at least, not that's shown in this log
<smoser> well, it still hasnt then (looking at that log now)
<slangasek> smoser: what's 'status upstart-udev-bridge' show?
<smoser> hm.. start/running
<slangasek> ok
<slangasek> so maybe the log output went somewhere else
<slangasek> (in which case... we probably need to see that log output, wherever it is, to get the whole picture)
<smoser> yeah.
<smoser> i have had thoughts that i was not getting all of output
<smoser>  /var/log/syslog: http://paste.ubuntu.com/1191875/ /var/log/kern.log: http://paste.ubuntu.com/1191876/
<xnox> anything interesting in /var/log/upstart/* ?
<xnox> cause that's where it's going by default....
<smoser> $ ls -l /var/log/upstart -d
<smoser>  ls: cannot access /var/log/upstart: No such file or directory
<slangasek> smoser: um?  where'd you put that directory then?  It's shipped by the upstart package
<smoser> well... i changed the timeout waiting for static-networking-up back to 120 seconds (i had put it to 10) in cloud-init-nonet.conf
<smoser>  http://paste.ubuntu.com/1191899/
<smoser> well, i didn't put that directory anywaere.
<smoser> suck.
<smoser> so this is definitely a bug. some cleaning out of images. in the build process kills that.
<smoser> so i'll open a bug on that.
<smoser> i changed that timeout back to 120 seconds
<smoser> and http://paste.ubuntu.com/1191889/ is the result
<smoser> its more obvious that there something is still blocking, waiting for that.
<smoser> probably for mounted / to finish
<slangasek> smoser: so http://paste.ubuntu.com/1191875/ shows a correct udev-based bring-up of the networking
<slangasek> but the timing is a bit odd
 * slangasek looks at the latest
<slangasek> smoser: hah; udevtrigger waits to find out if you're in a container
<slangasek> smoser: /etc/init/container-detect.conf has an explicit check for mounted MOUNTPOINT=/run instead of virtual-filesystems
<slangasek> smoser: try twiddling it to use virtual-filesystems instead
<smoser> bah.
<slangasek> smoser: that seems like a change we can easily make in the distro - if it works
<smoser> well, it might be by design.
<smoser> in that it can run earlier than virtual-filesystems (much earlier)
<slangasek> nah
<smoser> altougho i guess nothing (as we see) is gonna guarantee that anyway.
<slangasek> I mean, it is, but there's nothing in the design that requires the rest of mountall to wait for the container answer
<slangasek> and changing the container-detect job is better than making your workaround job double-emit the mounted event
<smoser> so.. https://bugs.launchpad.net/ubuntu/+bug/1047707 is to cover /var/log/upstart in the images.
<ubottu> Launchpad bug 1047707 in Ubuntu "/var/log/upstart deleted from cloud images" [High,Triaged]
<smoser> well i had my work around in place there.
<smoser> and i think its required to get to the point.
<infinity> smoser: I assume that's a symptom of a larger "purging stuff willy-nilly" bug?
<infinity> smoser: Unless you were explicitly removing that one directory for some reason...
<smoser> yeah, it is.
<slangasek> smoser: yes, and your workaround does NOT emit the 'mounted' event, it emits virtual-filesystems
<smoser> no. its like rm -Rf /var/log/*
<smoser> right.
<infinity> smoser: Gah.
<slangasek> which we should bring container-detect into alignment with
<smoser> right.
<smoser> one thing that i'm running into
<smoser> the cloud-init-nonet job has 'output console'
<smoser> but its output is *not* getting to console
<smoser> where console=/dev/ttyS0 (per that command line).
<smoser> i had to explicitly | tee /dev/ttyS0 to get it to the console.
<smoser> i'll try the change on container and boot
<smoser> slangasek, that seems to fix the proble.
 * slangasek nods
<smoser> well, with the hack-emit-virtual-filesystems.
<slangasek> it certainly should have been the last thing left that could be a problem :)
<smoser> so i can get where i need to go now, i think.
<smoser> so you want a bug against upstart for container-detect?
<slangasek> smoser: can you file a bug on upstart about container-detect and /run vs. virtual-filesystems?
<slangasek> yes please :)
<smoser> i'll open one, but i'd appreciate if you fill in some better debug and justfication.
<smoser> so that some time from now when i'm trying to trace steps i'll have some info
<slangasek> smoser: ack
<smoser> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1047712
<ubottu> Launchpad bug 1047712 in upstart (Ubuntu) "container-detect.conf should be 'start on virtual-filesystems'" [Undecided,New]
<smoser> slangasek, what woudl you think about trying to make mountall happier by running my virtual-filesystems-emitter on 'starting mountall'
<smoser> (in addition to cloud-init-nonet. it should just prep the system so mountall doesn't htink it should have to mount those filesystems)
<smoser> slangasek, well. one more piece of my puzzle (i'm stillnot getting resolv.confworked out).
<smoser> but /etc/init/iscsi-network-interface.conf is a bit of info
<smoser> http://paste.ubuntu.com/1191973/
<slangasek> smoser: 'start on starting mountall' should be fine for that, yeah
<slangasek> smoser: right, that's kinda what I was expecting to see from iscsi
<slangasek> and it's skipping the ifupdown hooks, which is a problem
<slangasek> though from the comment, it seems that may have been deliberate
<smoser> slangasek, yeah. i'm poking around.
<smoser> i'm in initramfs now.
<smoser> was hoping i could get it to store off the dns server responses
<smoser> from the dhcp request.
<smoser> they get printed. and "configure_networking" pretends that "Ip-Config tries to create this file and when it succeds" (/run/net-"${DEVICE}".conf)
<smoser> but it sure doesn't look like it does to me. i'm in an initramfs and dont see any such stuff getting created.
<smoser> shoot.
<smoser> it loo like our initramfs is busted in that respect
<smoser> it writes /tmp/net-eth0.conf
<smoser> at least in precise
<slangasek> so, where does ipconfig come from? busybox?
<smoser> klibc
<smoser> http://paste.ubuntu.com/1191999/
<slangasek> smoser: fixed in quantal; seems klibc-utils and initramfs-tools were out of sync on this in precise
<slangasek> smoser: sounds like that should be cherry-picked from klibc-utils
<smoser> ah. so the klibc-utils updated to /run
<slangasek> klibc 2.0-2, in Debian
<slangasek> yes
<smoser> i'm opneing a bug for that.
<smoser> easiest thing might be to just update to lok in 2 places
<slangasek> no, just update klibc to use /run
<slangasek> that's the right place for it to be
<slangasek> and nothing relies on the current behavior in precise
<smoser> slangasek, are you sure this is "fix-released" ?
<smoser> https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1047722
<ubottu> Launchpad bug 1047722 in klibc (Ubuntu) "configure_networking net-DEVICE.conf in /run, but ipconfig writes in /tmp" [Undecided,New]
<slangasek> smoser: I've checked the source in quantal, it's definitely writing to /run onw
<slangasek> now
<smoser> k.
<smoser> so i thin i shoudl be able to get that information from the dhcp response (dns info)
<smoser> and store it somewhere
<smoser> and then replay it to resolvconf
<slangasek> in fact, so long as you're getting it written to /run, I believe the initramfs should be mount -omove'ing that for you
<smoser> yeah, i wondered about that. so i dont have to store it even.
<slangasek> yep
<slangasek> you do have to make sure you're not mounting something else over /run ;)
<smoser> i think i'm gonna close this laptop now.
<smoser> you've been very helpful, slangasek
<smoser> thanks.
<slangasek> y/w
<slangasek> have a good evening
<smoser> evening for 8 more minutes here
<smoser> then am
<smoser> later.
<slangasek> looking at the dictionaries-common code makes me very angry
<malkauns> can someone point me to how i can create animated progressbars in gtk-3?
<Daviey> jtaylor: thanks for doing asterisk
<jtaylor> np but it needs doing for precise
<jtaylor> unfortunately it are ~8 CVEs and the simple diff are 10000 lines ...
<jtaylor> I have no time for that and no idea how to test anything
<Daviey> jtaylor: Well, if you are able to prepare an update.. I'm happy to test it?
<jtaylor> thanks, I'll come back to you if an update gets prepared
<Daviey> super!
<penguin42> doko: Which gcc package version were you using for bug 1019725 ?
<ubottu> Launchpad bug 1019725 in gcc-4.6 (Ubuntu) "tiny STL code sample segfaults cc1plus" [Medium,Triaged] https://launchpad.net/bugs/1019725
<pcarrier> is it just me, or is canonical trying to get rid of the gnome ecosystem and quantal a step toward more and more components in qt?
<ScottK> Any particular examples in mind?
<alkisg> I'm trying ubuntu-defaults-image, and it's working ok except that the generated .iso doesn't have the following files:
<alkisg> autorun.inf boot dists install pics pool preseed README.diskdefines ubuntu wubi.exe
<alkisg> ...can I do something to include those as well?
<phaidros> is there any reason that 12.04 LTS comes without CONFIG_CIFS_ACL kernel setting ?!
<penguin42> jamespage: Thanks for fixing the iPXE
<jamespage> penguin42, np
<penguin42> jamespage: What's your setup like; I'm running two kvm vm's one with tgt, and I've got two different clients; one disk less, and the other with disk - the diskless install doesn't seem to have setup the inittab properly yet (from last weeks iso)
<jamespage> penguin42, I run tgt on the KVM host alongside libvirt and I use diskless kvm vms with a scripted ipxe setup todo automated iscsi root installs for testing
<jamespage> penguin42, its a bit hacky but it works - https://code.launchpad.net/~james-page/+junk/iscsi-testing
<penguin42> jamespage: Have you had any problem with boot order issues on tgt? I seem to need to restart tgt after server boot for it to pick the disk up
<jamespage> penguin42, I'd not noticed anything like that - but my test cases don't normally persist between boots :-)
<jamespage> I don't make the tgt configuration persistent
<jamespage> penguin42, BTW have you tried 12.04 against a quantal tgt target? I'm wondering whether I need to SRU that fix to 12.04 as well
<penguin42> jamespage: No I haven't; I haven't got a 12.04 host to try
<penguin42> (I guess I could go nuts and go nested kvm...)
<jamespage> penguin42, thats my prob as well
<jamespage> I probably will try that; I have access to a cloud which supports it
<penguin42> jamespage: I've done nested kvm before - it's surprisingly easy; other than getting the default netmask right, it just works if you stack 12.04's
<penguin42> jamespage: I suspect the other thing the people running iscsi in the real world would want to do automatically in the installer is get multipath going
<jamespage> penguin42, I have lots of experience with multipath in fibre channel based SAN's - but zip with iscsi
<penguin42> jamespage: I don't know much about it - my server setup does have two net interfaces and I've bound it to both 'portals' - and in the non-root version I've got I have it log in once on each interface and see both instances as separate discs in /proc/scsi/scsi so I assume multipath would sort it out into one device
<penguin42> jamespage: I think like FC there is a lot of 'magic' knowledge of timeouts and stuff with particular vendors
<penguin42> jamespage: The only other commonality is that multipath is renowned as a pain
<penguin42> jamespage: Bug 1047998 is my problem with the server install on iscsi root
<ubottu> Launchpad bug 1047998 in debian-installer (Ubuntu) "iscsi root: iscsi not started in initramfs" [Undecided,New] https://launchpad.net/bugs/1047998
<penguin42> jamespage: and bug 1048008 for tgt needing a restart
<ubottu> Launchpad bug 1048008 in tgt (Ubuntu) "tgt needs restart to find LUN" [Undecided,New] https://launchpad.net/bugs/1048008
<pcarrier> ScottK: ubuntu-sso-client-qt, ubuntuone-control-panel-qt, apparently libaccounts
#ubuntu-devel 2012-09-09
<ScottK> pcarrier: The Ubuntu stuff changed in precise.  I think because it has to work on many platforms so it's much easier in Qt since it's more portable.
<ScottK> Since Unity-2D (which was done in t Qt/QML) got killed off this cycle, I think it's less so in quantal than precise.
<alkisg> alkisg: I'm trying ubuntu-defaults-image, and it's working ok except that the generated .iso doesn't have the following files:
<alkisg> alkisg: autorun.inf boot dists install pics pool preseed README.diskdefines ubuntu wubi.exe
<alkisg> ...can I do something to include those as well?
<slangasek> smoser: could you try the latest version of lp:mountall?
<slangasek> smoser: (make that lp:ubuntu/mountall)
<Andy80> hi!
<Andy80> a very noob question... (forgive me but I just woke up :P ) If I previously pushed code here lp:~andreagrandi/ubuntu/quantal/libdbg/typo-fix if I work on another PC all I've to do is: bzr branch lp:~andreagrandi/ubuntu/quantal/libdbg/typo-fix to get the code back?
<Andy80> thanks
<iulian> Andy80: Yes.
<Andy80> iulian: thanks
<Andy80> if I've already a merge proposal pending and I'm just committing a requested change, I don't need to do "bzr lp-propose", right? I see that the previous merge proposal was automatically modified https://code.launchpad.net/~andreagrandi/ubuntu/quantal/libdbg/typo-fix/+merge/121227
<Andy80> anyway... I'm trying to follow the instructions here https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative but when I execute "bzr bd --builder=pdebuild" I get this errors: http://pastebin.com/ytYZxThh
<mitya57> Andy80: the branch looks ok, but I think you should remove the duplicate changelog entry and set target to UNRELEASED instead of precise
<Andy80> mitya57: oh right
<Andy80> mitya57: I know how to remove the duplicate, but I don't know how/where to set "UNRELEASED"
<mitya57> just change "precise" to "UNRELEASED" in the first line
<Andy80> mitya57: oh you mean "libdbg (1.2-2ubuntu4) precise; urgency=low" ----> "libdbg (1.2-2ubuntu4) UNRELEASED; urgency=low" ?
<mitya57> Yes. I don't have rights to merge it, just noting
<Andy80> ok, I remove the duplicate, change that line and push it again
<wendar> jtaylor: ping?
<jtaylor> wendar: yes?
<wendar> I saw you did the quantal asterisk release for the CVEs yesterday
<wendar> are you working on an SRU for precise too?
<wendar> the actual code changes are pretty small
<jtaylor> I don' plan on working it myself, but I'm happy to sponsor a patch
<wendar> ok, I started working on it then figured I should make sure I wasn't duplicating effort
<wendar> will finish it off
<wendar> thanks!
<jtaylor> great, asterisk is in dire need of someone caring about it
<Debolaz> How would I link to my homepage/blog from my launchpad profile?
<lifeless> Just type the link in your description
<cjwatson> lifeless: https://launchpad.net/~cjwatson/+archive/grub has precise and quantal packages for your delectation
<cjwatson> lifeless: I'd still suggest building a chroot and trying the grub-probe command directly, as I probably won't support the precise branch of that terribly well
<cjwatson> Or I guess you could downgrade straight afterwards but I think that may require some slight fiddling (e.g. removing /boot/grub/i386-pc/)
<lifeless> cjwatson: what was the bug you wanted me to reproduce again?
<cjwatson> lifeless: bug 803658
<ubottu> Launchpad bug 803658 in grub2 (Ubuntu) "grub-install /dev/mapper/isw_$UUID_$NAME0 failing with ICH10R raid 1+0" [High,Fix released] https://launchpad.net/bugs/803658
<cjwatson> Conveniently you left a comment on that bug that quotes the failing grub-probe command :-)
<lifeless> okies, lets see what I can see
 * lifeless wonders why he has i386 sqlite installed
<lifeless> cjwatson: lol - versioned conflict with apport ;)
 * lifeless removes apport to test the bug
<lifeless> cjwatson: 'cannot find a GRUB drive ...
<cjwatson> lifeless: hmm :-(
<lifeless> cjwatson: I think its fine, it was for other partitions
<lifeless> cjwatson: commented in the bug
<cjwatson> oh, er, we probably shouldn't use that bug :)
<cjwatson> let's see
<lifeless> Hah.
<lifeless> Well, package is installed. I'm happy to be remote hands for you.
<cjwatson> hmm, I suspect this is a bug in around the area I changed
<cjwatson> it's failing to understand that the device is partitionable
<lifeless> I've thoroughly paged the code out in the intervening time period.
<lifeless> Let me know if I need to reverse that :)
<cjwatson> yeah, well, it's changed around anyway
<cjwatson> so I don't need remote hands for now, but will need to think a bit about how this is meant to work
<lifeless> It would be nice if the kernel provided an abstract API :)
<lifeless> or something.
<cjwatson> That would only help to a minor extent.  Most of this is code that needs to work at boot time too.
<cjwatson> i.e. this is probably an indication that the installed GRUB will be unable to locate partitions at boot.
<lifeless> Ah.
<cjwatson> GRUB really does have to understand this all by itself.
<lifeless> So, hmm, that worries me a little :)
<cjwatson> Yeah, I'd downgrade if I were you.
<cjwatson> apt-get install grub-common/precise grub2-common/precise grub-pc-bin/precise grub-pc/precise
<cjwatson> rm -r /boot/grub/i386-pc
<cjwatson> though before you do
<cjwatson> sudo /usr/sbin/grub-probe -vv --device-map=/boot/grub/device.map --target=drive --device /dev/mapper/isw_bichcdfhcg_ARRAY0p1
<cjwatson> and shove the output in that bug I guess; might save me setting up a matching test environment :)
<lifeless> on the bug
<lifeless> cjwatson: not precise-updates?
<cjwatson> oh yeah, that
<lifeless> cjwatson: /boot/grub/i386-pc doesn't exist after the downgrade, NFI why.
<lifeless> cjwatson: let me know when you want me to take it for another spin.
<cjwatson> ok.  blink, odd output.
<cjwatson> guess I'll see if I can convince kvm to set this up
<cjwatson> if I can remember the insane runes
<cjwatson> thanks for the attempt anyhow
#ubuntu-devel 2013-09-02
<micahg> dh_python3 seems to creating a depends on python3-pyflakes in Ubuntu only which is messing up the build of python-flake8, I'm not sure where to file this bug now that we have dh-python as a separate source or if that's even the cause
<micahg> hrm, Debian is affected as well, so it's not Ubuntu specific
<pitti> Good morning
<ScottK> micahg: Please try it again with this weekend's dh-python upload and see if it's fixed.
<dholbach> good morning
<darkxst> anyone able to sponsor bug 1219148 for me
<darkxst> ?
<ubottu> bug 1219148 in gnome-settings-daemon (Ubuntu) "Fix gdm -> login transition" [Undecided,New] https://launchpad.net/bugs/1219148
<darkxst> 1212408
<darkxst> that should have been bug 1212408
<ubottu> bug 1212408 in gdm (Ubuntu) "lightdm/gdm needs to set $XDG_CURRENT_DESKTOP" [Undecided,Confirmed] https://launchpad.net/bugs/1212408
<darkxst> Also 1189309
<darkxst> bug 1189309
<ubottu> bug 1189309 in libappindicator "nm-applet crashed with SIGSEGV in gtk_status_icon_set_visible()" [High,Confirmed] https://launchpad.net/bugs/1189309
<brendand> hey - i can see my package build has put the files into debian/tmp, but they aren't getting installed when i install the .deb file that is created
<brendand> so for example in the build environment i see debian/tmp/usr/bin/my-app
<brendand> and in the .install file i have
<brendand> usr/bin/my-app
<brendand> so i should get /usr/bin/my-app installed (shouldn't i?)
<Laney> brendand: export DH_VERBOSE=1 in debian/rules then rebuild and you'll be able to see what dh_install is doing
<brendand> Laney, thanks for the tip
<lool> ev: hey, would you mind pointing me at the docs on how to connect errors.u.c reports with LP bugs?
<lool> ev: the libgpod-common one is the one I'd like to connect to LP #1212546
<ubottu> Error: Launchpad bug 1212546 could not be found
<ev> lool: this one? https://errors.ubuntu.com/problem/28836a9ab5fd3bac86aa699f4c2be0a7d52b61cf
<ev> lool: just make sure you're logged in, then hit the Create link for the relevant problem on this page: https://errors.ubuntu.com/?package=libgpod-common&period=year
<lool> ev: yes this one
<lool> ev: ah I was looking for a login, but it was hidden by my browser's search box!
<ev> :D
<lool> ev: ah so I can't link to an existing one?  ok, marked the new one as a dup -- it will still be able to track status updates?
<Sp4rKy> W 36
<ev> lool: correct - you cannot yet link to an existing one. Marking as the dup is the right approach, but lp:daisy doesn't seem to have the smarts for that yet. Please feel free to file a bug: http://launchpad.net/errors/+filebug
<ev> smarts to follow the bug to its parent when dup'ed, that is
<lool> ev: LP #1219706 -- thanks!
<ubottu> Launchpad bug 1219706 in Errors "Follow state of bugs marked as duplicates" [Undecided,New] https://launchpad.net/bugs/1219706
<ev> thanks!
<ritz> tjaalton ping, wrt https://bugs.launchpad.net/ubuntu/+source/libxrandr/+bug/985202
<ubottu> Launchpad bug 985202 in libxrandr (Ubuntu Precise) "libx11 causes kwin to crash on login (over NX protocol)" [High,Fix released]
<tjaalton> ritz: ok, needs reopened?
<tjaalton> uh, what's using .cache/friends/avatars?
<tjaalton> I have 45k files there, 1.7GB
<ritz> tjaalton yes
<ritz> libfolks/empathy ?
<ritz> the patch needs to be updated to the "correct" fix
<seb128> tjaalton, friends is using that dir, I though Ken said the new version was supposed to manage those better though
<tjaalton> seb128: ok, newest entries there seem to be a couple of weeks old. I had raring before that
<tjaalton> so, friends on raring is still busted I guess
<seb128> likely
<pitti> wgrant, StevenK: we might have discussed this already, but I forgot: how much effort would bug 1201485 be on the LP side? duplicating the whole import logic in langpack-o-matic would be a lot of effort, and also rather brittle I guess
<ubottu> bug 1201485 in langpack-o-matic "Need to import translations for the unity daily builds" [Undecided,Triaged] https://launchpad.net/bugs/1201485
<tjaalton> ritz: right, I can pull the upstream commit directly with less effort, if that's ok
<ritz> tjaalton perfectly fine :) thank you
<seb128> wgrant, StevenK, pitti: our current translations situation is getting really suboptimal, all stuff under daily release (which is most of unity) don't get updated translations due to that
<pitti> wgrant, StevenK: i. e. those translation tarballs would need to be fed to translations as if they were an actual ubuntu upload; or the tarballs need to be copied along with the package on PPA copy
<cjwatson> I think that's probably not that hard now.  In fact I vaguely remember us talking about it at the releng sprint
<cjwatson> We have mechanisms to copy custom uploads in general, so it's just a matter of whether there are any translations-specific gotchas
<cjwatson> It might be necessary to factor PackageUploadCustom.publishRosettaTranslations out to archivepublisher so that it can fit into the scheme expected by the custom upload copier, perhaps
<ekarlso->  https://launchpad.net/~endre-karlson/+archive/libra/+sourcepub/3458679/+listing-archive-extra < anyone know why this only does i386 ?
<wgrant> pitti, seb128: As cjwatson says, it's probably not terribly hard now.
<cjwatson> ekarlso-: Because it's an Architecture: all package.
<cjwatson> ekarlso-: They only need to build on one architecture (i386), but are published to all architectures.
<cjwatson> ekarlso-: Also, your versioning of that package is rude.  You shouldn't reuse the Debian namespace
<cjwatson> Append something to the version rather than bumping it to -2 ...
<cjwatson> Though, wait, was this package not based on the gearman package in Debian?  (If not, why not?)
<sil2100> gusch: hi!
<cjwatson> From the version number I assumed that it was a rebuild of the version in Debian.
<ekarlso-> cjwatson: I think it's due to a not upstream yet support of ssl
<sil2100> gusch: the gallery-app failing-AP-tests merge still has problems it seems: https://code.launchpad.net/~schwann/gallery-app/gallery-atest-toolbar-opened/+merge/183195
<cjwatson> ekarlso-: Bumping the upstream version doesn't require throwing away all the Debian history.
<ekarlso-> cjwatson: again, I didn't do that
<sil2100> gusch: while this failure is still blocking the apps stack from releasing ;)
<ekarlso-> I just bootstrapped the package from a source tar
<cjwatson> ekarlso-: OK, but you did bump it from -1 to -2
<ekarlso-> cjwatson: because I haven't done much packaging before :)
<ekarlso-> but noted for the next bump
<cjwatson> Right, which is why I'm explaining that there are conventions for versions to reduce confusion ...
<ekarlso-> :)
<ekarlso-> optimally I wouldn't do packaging at all to avoid this
<cjwatson> In fact it's even more confusing.  Debian's gearman package comes from a gearmand source package
<gusch> sil2100: the problem is, that the fix for the share component seems to not have landed there
<cjwatson> So it looks as though Matthew Tai entirely repackaged it from scratch
<ekarlso-> hmmms ok ? :p
<cjwatson> Ah well, people do strange things
<ekarlso-> ;p
<ekarlso-> cjwatson: the geamrna stuff is only temp until the changes we need go into trunk
<sil2100> gusch: so we need also some other fix for this one to work? In which branch?
<cjwatson> Anyway, your i386 build will have been published to all architectures; if you want to check, look in the dists/ subdir of your published PPA for some other architecture
<gusch> sil2100: https://code.launchpad.net/~ken-vandine/ubuntu-ui-extras/friends0.2/+merge/182895
<sil2100> gusch: so, this is causing the fails-to-merge? I actually thought that it should be ok if that's merged in, hm
<dpm> cking, morning! On bug 1199073 do you have any suggestions on how to reduce the overhead?
<ubottu> bug 1199073 in Ubuntu Clock App "clock app on galaxy nexus generates ~2500 context switches a second" [High,Triaged] https://launchpad.net/bugs/1199073
<sil2100> Since the upstream merger should use dialy-build PPA
<cking> dpm, i guess only via analysing it via tools like strace to see what system calls are being used to figure out why it is so busy
<cking> dpm, I've got no knowledge of how this app works or any qml know-how, so I have no immediate idea why
<dpm> ok, thanks cking
<gusch> sil2100: it seems the fix is not yet in the saucy package - but it's quite weired, as it only fails for mako ...
<sil2100> gusch: and even if not, that change is already released into release
<gusch> sil2100: can you check if the mako setup has an issue?
<sil2100> gusch: it should be, it got released on the 29th - I'll try checking that
<gusch> I'm trying to use libupstart-app-launch
<gusch> but the library does not contain any symbols
<gusch> it seems dh_strip removes them during pakage build
<gusch> but I don't see a resaon why this could happen
<gusch> does anyone have an idea?
<seb128> gusch, hey, what do you call "symbols"? debug symbols?
<gusch> seb128: I mean by what "nm" reports for the library
<gusch> seb128: result is, that I can't link to that library
<seb128> gusch, on what arch?
<seb128> $ nm -D /usr/lib/i386-linux-gnu/libupstart-app-launch.so.1.0.0 | grep " T upstart"
<seb128> 00002500 T upstart_app_launch_get_primary_pid
<seb128> 00002450 T upstart_app_launch_list_running_apps
<seb128> 00002390 T upstart_app_launch_observer_add_app_start
<seb128> ...
<seb128> gusch, ^ that's what I get on saucy (i386)
<gusch> seb128: for amd64 saucy: nm: /usr/lib/x86_64-linux-gnu/libupstart-app-launch.so.1.0.0: no symbols
<seb128> weird
<seb128> dpkg - l | grep libupstart-app-launch1
<gusch> seb128: oh - I get the symbols when using "-D"
<gusch> seb128: but why am I not able to link to the library?
<seb128> gusch, can you copy the exact error/build log?
<seb128> gusch, or share a vcs with your code?
<gusch> seb128: lp:~schwann/content-hub/content-start-exporter
<seb128> gusch, there is no libupstart code in there?
<seb128> gusch, can you share the code that fails to build?
<gusch> seb128: grrr - fogot to commit before ...
<gusch> seb128: pushed - sorry for that
<seb128> gusch, no worry, I got it, trying to build
<seb128> gusch, the issue is that you don't have the libupstart build flags
<gusch> seb128: argh
<seb128> gusch, the check is in the sourcedir but that doesn't seem included in that CMakeLists.txt of that subdir
<gusch> seb128: I used it to get the library, but not for the build flags
<gusch> seb128: thx - I'd never had guessed that
<seb128> gusch, yw
<gusch> seb128: somehow I still don't get it to link
<seb128> gusch, can you push what you did?
<gusch> seb128: pushed
<seb128> gusch, in that same file you changed did you try to add to
<seb128> include_directories(
<seb128>   ${CMAKE_SOURCE_DIR}
<seb128> gusch, it only includes src/ atm
<mardy> seb128: hi! About the shotwell update, do you know if someone has a branch with the updated debian/ stuff (apart from the online accounts parts)?
<seb128> gusch, but the check is in the main dir
<seb128> mardy, I do
<seb128> mardy, let me push that
<mardy> seb128: thanks!
<seb128> gusch, the issue is that this subdir doesn't include the main config so it doesn't have the variable for the stuff that are checked in there
<gusch> seb128: no difference
<seb128> gusch, I don't know much about cmake, but the issue is clearly that the UPSTART check you do in the main file isn't carried over to the subdir
<seb128> gusch, try maybe moving that check line to the subdir CMakeFile?
<gusch> seb128: MESSAGE (${UPSTART_LAUNCH_LDFLAGS}) prints "-lupstart-app-launch-lglib-2.0"
<mardy> seb128: please ping me once you have pushed your branch
<gusch> seb128: so it's carried over (using _LDFLAGS or _LIBRARIES is not much of a difference)
<seb128> gusch, did you typo that or is that really the value? you miss a space between the flags
<seb128> mardy, I've a diff for the debian dir there http://people.canonical.com/~seb128/shotwell.diff
<seb128> mardy, does that work for you or do you want a vcs rather?
<mardy> seb128: I think it should be OK
<gusch> seb128: no typo, but cmake sets it correctly in the link.txt
<seb128> mardy, great; let me know if you need something else
<seb128> gusch, let me have a look here
<mardy> seb128: I always forget how to do it; was there a tutorial online?
<seb128> mardy, how to do what?
<mardy> seb128: to update the patch; I think I was using "bzr bd-do", but I cannot remember the steps
<seb128> mardy, well, you can do
<seb128> - comment from the debian/patches/series
<seb128> - bzr bd-do
<seb128> - renable it in the serie
<seb128> - quilt push -f
<seb128> - resolve conflicts/update
<seb128> - quilt refresh
<seb128> - ctrl-D
<seb128> mardy, but just updating the diff is fine, use whatever method you prefer, if you do that over upstream git that works for me
<mardy> seb128: excellent, thanks! I think I was following the steps you wrote now, last time, so I'll stick to that
<ogra_> pitti, hey ... i would like to get rid of http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/99-remove-documentation.chroot from the ubuntu touch buildss, i remember you implemented something like that in a clean way, but forgot how to achieve it
<ogra_> (and google isnt very informative or my skills are failing me today)
<pitti> ogra_: you mean https://wiki.ubuntu.com/ReducingDiskFootprint#Drop_unnecessary_files ?
 * ogra_ hugs pitti 
<pitti> ogra_: *hug back*, kein Problem :)
<ogra_> :)
<pitti> ogra_: got a meeting with ev now, can explain details afterwards if necessary
<ogra_> the wiki is pretty clear, implementing it at the right place of the build will be the tricky part :0
<ogra_> :)
<ogra_> pitti, hmm, that doesnt adjust the /var/lib/dpkg/info/*.md5sum files i suspect ?
<seb128> gusch, yeah, I don't know about that build issue, it's probably an issue with the order of arguments/libs in the linker command but I can't figure out which one
<gusch> seb128: thx for checking
<JackYu> hi, any one know what's the new name of apt.progress? it seems that it was changed in these days.
<xnox> ogra_: no need generally, why shoud it? or do you thing that will be a saving as well?
<ogra_> xnox, heh, no ...
<JackYu> apt.progress from python 2.7...
<seb128> gusch, hum
<seb128> gusch, doing
<seb128> extern "C" {
<seb128> #include <libupstart-app-launch-1/upstart-app-launch.h>
<seb128> }
<xnox> ogra_: i use localepurge, which uses same mechanics (dpkg include/exclude flags) and yes md5sums is "pristine" (which may or may not be complete, and have extra files listed)
<ogra_> xnox, i'm trying to set up an md5sum check to check the installed files before and after tests ...
<seb128> gusch, works
<seb128> gusch, in app_manager.cpp
<gusch> seb128: you are right - I should have thought of that ... thx
<ogra_> xnox, so i was planning to do something like:  cat /var/lib/dpkg/info/*.md5sums  >tmp/md5sum.log &&  md5sum -c /tmp/all.md5sums >/tmp/md5sum.log
<xnox> ogra_: $ debsums $pkgname, since it's all dpkg settings, it just works to verify as well.
<ogra_> would that omit deleted files ?
<ogra_> debsums would require me to iterate over all packages
<xnox> ogra_: yeap, or simply run $ debsums, to do alll =)
<ogra_> that would be very slow i guess
<seb128> gusch, yw, I should have tried that earlier, I was focussed on the linker side ...
<ogra_> root@ubuntu-phablet:/# time md5sum -c /tmp/all.md5sums >/tmp/md5sum.log 2>&1
<ogra_> real	0m7.853s
<ogra_> thats quite acceptable :)
<xnox> ogra_: you don't have to. you can do $ debsums pkga pkgb
<ogra_> root@ubuntu-phablet:/# tail -2 /tmp/md5sum.log
<ogra_> md5sum: WARNING: 3870 listed files could not be read
<ogra_> md5sum: WARNING: 133 computed checksums did NOT matc
<JackYu> seb128,  hi, do you know what's the new name of apt.progress in Python 2.7?
<ogra_> thats my problem  ...
<seb128> JackYu, hey, I've no idea, maybe pitti or cjwatson can help you though
<ogra_> (4003 files from /usr/share/doc get deleted during build)
<xnox> ogra_: well debsums on my install, reports all OK and exit 0, despite having translation files removed the same way as in that wiki page.
<cjwatson> I'm not aware of apt.progress having been renamed.
<cjwatson> Perhaps you could state your actual original problem.
<JackYu> seb128, thanks.
<xnox> ogra_: use debsums ;-) it's awesome and supports all of that.
<ogra_> well, can i use "debvsums *" ?
<ogra_> :)
<ogra_> -v
<xnox> yes.
<cjwatson> JackYu: ^-
<xnox> just "$ debsums" iterates across all installed packages.
<JackYu> cjwatson, hi, we use apt.progress in youker-assistant.
<ogra_> oh, cool
<ogra_> lets see how slow that is :)
<JackYu> cjwatson, but it dosen't work now.
<xnox> it's perl.... =) and supports options, e.g. it can list missing stuff if you want etc....
<cjwatson> You use specific things from the package apt.progress.
<cjwatson> apt.progress still exists, but the specific classes you're using need to be adjusted.
<JackYu> cjwatson, we use InstallProgress, TextFetchProgress from apt.progress
<cjwatson> Yes, those have been obsolete for several years.  It's not about Python 2.7, it's about the new python-apt interface that came in somewhere around Lucid.
<pitti> ev: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<JackYu> cjwatson, ok, thanks. I will check soon.
<cjwatson> JackYu: You probably want something roughly along the lines of http://paste.ubuntu.com/6055145/
<JackYu> cjwatson, wow, correct, thanks:)
<pitti> ogra_: md5sums> hm, I thought I did that
<pitti> ogra_: but it's been a while
<ogra_> pitti, well, the second code definitely doesnt ... (thats what we use now)
<ogra_> (on the wikipage that is)
<pitti> ogra_: ah no, it doesn't adjust md5sum files
<ogra_> if the first one does, that would help
<pitti> ogra_: what is first and second here? --path-exclude and live-build?
<ogra_> there are two ways of removing the docs in the wikipage ...
<ogra_> livecd-rootfs currently uses the second during ubuntu touch build
<ogra_> (talking about https://wiki.ubuntu.com/ReducingDiskFootprint#Drop_unnecessary_files)
<pitti> ogra_: they need to be applied together, though
<ogra_> but that leaves us with inconsistent md5 files
<ogra_> ah
<ogra_> hmm
<ogra_> i dont think the first one is ...
 * ogra_ checks the code
<pitti> ogra_: --path-exclude (dpkg) for installing/upgrades packages, and the live-build adjustment to clean up the files from bootstrapping before your dpkg conf file gets installed (if you care about those)
<pitti> ogra_: but yes, they both leave the md5sums file untouched
<pitti> that just didn't come up back then
<Peace-> can someone help me to understand thsi error ?  [60238.145947] mmc0: error -110 whilst initialising SD card
<tjaalton> nfs mounts don't seem to get mounted on boot on saucy
<tjaalton> doing manually what mountall-net.conf doesn't seem to fix things
<ekarlso-> cjwatson: what's the best practice when re-building a package that is upstream and has the same version ?
<cjwatson> ekarlso-: dch -R
<ekarlso-> I mean, so my package will get prioritized over the upstream one
<ekarlso-> change the version nr to a higher version ?
<cjwatson> dch -R will do the right thing
<cjwatson> Assuming it's a no-change rebuild
<cjwatson> If you're making source changes, then dch -i
<cjwatson> Actually, if this is for a PPA
<cjwatson> ekarlso-: https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage
<cjwatson> That has specific advice which is more detailed than I want to reproduce in IRC :)
<mitya57> ScottK: Do you have anything against syncing new dh-python from Debian? The changes are our forwarded tests, couple of minor pybuild changes and bugfixes.
<ScottK> mitya57: I think it needs an FFe as I don't think it's all bugfix.  In principal, I think we want it, but it ought to go through the process.
<pitti> jibel: hm, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html has enough fodder for replicating this RUNNING bug again -- we have zero running tests right now, and pygobject is being held back by umpteen RUNNING ones
<pitti> jibel: (we are in freeze anyway, so it's not urgent at all)
<mitya57> ScottK: filed as bug 1219900 (will subscribe -release when the linked build is done)
<ubottu> bug 1219900 in dh-python (Ubuntu) "[FFe] Sync dh-python 1.20130901-1 from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1219900
<ScottK> Great.
<pitti> jibel: I just re-run the update-manager test, as that ran with 0.191 and 0.193 fixes the pep8 errors
<pitti> wrt. to syncing, did anyone else notice that LP seems to take awfully long these days to import new packages from sid? it used to take about an hour after Debian's mirror pulse, now it takes about a day
<xnox> the timings did change. and it has been <= 6h since appearing on the uk debian mirror so far as I could spot.
<xnox> which is consistent with 4 daily dinstalls.
<cjwatson> pitti: The machine that runs the imports is currently down
<cjwatson> It apparently needs physical intervention
<pitti> cjwatson: ah, thanks
<ScottK> mitya57: See #d-python.  We want to wait for another upload today.
<mitya57> OK.
<cjwatson> pitti: https://rt.admin.canonical.com/Ticket/Display.html?id=64293
<cjwatson> (Sorry, internal only)
<ekarlso-> canÃ¦t I pin to a version like this? python-gearman (==2.0.2-2libra1)
<ekarlso-> cjwatson: ?
<cjwatson> ekarlso-: just one "=" - see the policy manual
<ekarlso-> cjwatson: but can I only pin to a version numerically ?
<ekarlso-> or can I add stuff like libra1 ?
<cjwatson> If you want a range, use something like "python-gearman (>= 2.0.2-2), python-gearman (<< 2.0.2-3)"
<cjwatson> You can use anything that's a valid version number in there (again, *please* see the Debian policy manual for this), but you should only use exactly-equals dependencies for things within the same source package as otherwise you have to keep remembering to change them
#ubuntu-devel 2013-09-03
<pitti> Good morning
<dholbach> good morning
<dholbach> xnox, pgraner, happy birthday! :)
<xnox> \o/
<xnox> Quarter of a Century.... "In Time" clocks start ticking
<infinity> xnox: I'm sure pgraner will be happy to hear you whining about your age. :P
<smb> Age... don't talk to me about age...
<smb> xnox, So Happy Birthday as well
<smb> In other general news: am I the only one that got the feeling that bootspeed in Saucy is not a happy camper?
 * xnox just upgraded to my first SSD ever, so for it all flies.
<xnox> smb: http://reports.qa.ubuntu.com/bootspeed/arch/amd64/#acer-veriton-02    mostly up & not down.
<smb> xnox, Seems to match my wonderful experience of 15s dark screen with a mouse pointer after login screen
<smb> xnox, and thats with a SSD
<xnox> hmm... i also wonder what that dark screen is.
<jibel> and according to bootchart it's an amd64 only regression
<xnox> (for me it's shorter but still there)
<smb> xnox, Feel like just the decorators not running
<pitti> hey xnox, good morning! happy birthday!
<smb> jibel, mine is i386
<geser> xnox: grats, how many bugs do you have to fix to earn some additional time? or did you inherit enough time? :)
<pitti> does anyone have a wireless keyboard and/or mouse? (bluetooth)
<xnox> pitti: does an android app count? =)
<smb> xnox, jibel, fwiw a bootchart of mine would be on chinstrap
<pitti> xnox: well, as long as upower --dump shows that devices' battery and it's in /sys/class/power_supply
<pitti> xnox: but it might be a bit atypical
 * hyperair has a bluetooth mouse
<pitti> hyperair: could you have a look at my last comment in bug 1153488? that's a command whose output I'd like to get
<ubottu> bug 1153488 in upower (Ubuntu) "System reads bluetooth input devices as a Battery" [Low,Triaged] https://launchpad.net/bugs/1153488
<hyperair> i don't recall ever seeing power_supply information for my mouse though..
<hyperair> (and the mouse is at home)
<hyperair> wait ~8 hours or so and i'll get to it
<pitti> hyperair: splendid, thanks
<xnox> pitti: no luck here, upower doesn't see it.
<hyperair> i've got one of the HID+ unifying adapter mouse/keyboard pairs on me right now though, and i don't see anything in power_supply besides AC and BAT0
<pitti> hyperair: ah, do you see them in "upower --dump"?
<hyperair> ope
<hyperair> nope*
<pitti> ah right, that's the Logitech stuff, not Bluetooth
<hyperair> yeah that's right
<hyperair> the bluetooth mouse is also logitech, but i've never seen it listed in upower's output before
<pitti> hm, bug 1066208 and its dupes suggest that it's not uncommon
<ubottu> bug 1066208 in indicator-power (Ubuntu Quantal) "power indicator shows a mouse battery as a laptop battery" [High,In progress] https://launchpad.net/bugs/1066208
<hyperair> might be for specific mice that actually do report their battery levels
<hyperair> i see a mention of apple magic mouse there
<hyperair> could it be just that mouse?
<pitti> https://launchpadlibrarian.net/120326665/UPowerDump.txt has "Eclipse Touch Mouse"
<hyperair> heh haven't even heard of that mouse before
<pitti> hyperair: and bug 1086746 has "Logitech diNovo Edge", so it  seems there are more
<ubottu> bug 1066208 in indicator-power (Ubuntu Quantal) "duplicate for #1086746 power indicator shows a mouse battery as a laptop battery" [High,In progress] https://launchpad.net/bugs/1066208
<darkxst> pitti, oh I wonder, maybe https://bugzilla.gnome.org/show_bug.cgi?id=707331 is similar?
<ubottu> Gnome bug 707331 in system-status "wireless mouse in user menu always "estimating"" [Normal,Unconfirmed]
<pitti> darkxst: could be; check upower --dump?
<darkxst> pitti, http://paste.ubuntu.com/6058085/
<pitti> darkxst: ah nice, could you attach the output of "grep -r . /sys/class/power_supply/*hid*" to bug 1153488 ?
<ubottu> bug 1153488 in upower (Ubuntu) "System reads bluetooth input devices as a Battery" [Low,Triaged] https://launchpad.net/bugs/1153488
<darkxst> pitti, its not bluetooth
<darkxst> its a unifying one
<pitti> darkxst: ah, that again; ok, thanks
<hyperair> hmm interesting
<darkxst> pitti, yeh, well atleast peter's branch fixed the other problem ;)
<ev> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: Open, FF | 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: ev
<pkern> ev: Could you pilot https://bugs.launchpad.net/bugs/1214385 please? ;)
<ubottu> Launchpad bug 1214385 in isc-dhcp (Ubuntu Precise) "Stateless DHCPv6 not working in precise" [Undecided,New]
<ev> sure can
<darkxst> Hey ev, any chance you can look at Bug 1219188
<ubottu> bug 1219188 in gnome-shell (Ubuntu) "Add support for separate background on lock screen" [Undecided,In progress] https://launchpad.net/bugs/1219188
<darkxst> ev, and super trivial patch on Bug 1189309
<ubottu> bug 1189309 in libappindicator "nm-applet crashed with SIGSEGV in gtk_status_icon_set_visible()" [High,Confirmed] https://launchpad.net/bugs/1189309
<ev> darkxst: sure, can do
<ev> pkern: bug 1214385 is in the queue for -proposed
<ubottu> bug 1214385 in isc-dhcp (Ubuntu Precise) "Stateless DHCPv6 not working in precise" [Undecided,New] https://launchpad.net/bugs/1214385
<mardy> seb128: hi! I need a little help with quilt :-)
<seb128> mardy, hey, sure! (funny I was just thinking about pinging you to ask how the patch update is going ;-)
<mardy> seb128: "quilt diff" shows all my changes, but with "quilt refresh" the patch doesn't get updated with all of them
<xnox> ev: given that touch is read-only, one can check if system-image-development (rw) mode was enabled. If not, collect & report run-away processes.
<seb128> mardy, did you modify new files (e.g that were not in the patch before), if you do you need to quilt add the files before changing them
<xnox> ev: i like when e.g. pulseaudio goes crazy and starts to eat 12% of CPU, yet killing it "fixes" the problem the respawned instance is back to using peanuts.
<mardy> seb128: no, it's a file that was already in the patch
<seb128> mardy, weird
<seb128> mardy, where are you looking to the patch?
<seb128> mardy, quilt refresh updates the version in build-area/source/debian/patches, that's copied over to your vcs when you end the bzr bd-do (if it exit without error)
<ev> xnox: mind following up to the email with that, just so we're all talking in the same place? :)
<ev> it's a good point
<mardy> seb128: mmm... I wonder, maybe it doesn't work because I copied all the build-area directory into another place? (so that I wouldn't lose it with an accidental Ctrl+D)
<seb128> mardy, well, quilt refresh should update it whever you are
<seb128> mardy, what does "quilt top" says?
<seb128> mardy, is that the patch you are working on?
<mardy> seb128: yes, "06_uoa.patch"
<seb128> mardy, and that patch doesn't get update on quilt refresh? (is the timestamp of the .patch changing?)
<mardy> seb128: nope, the timestamp doesn't change, and "quilt refresh" says: "Patch 06_uoa.patch is unchanged"
<seb128> mardy, does it does the same if you edit a file listed in that .patch?
<pkern> ev: Thank you!
<ev> darkxst: what's your full email address? The debdiff for the nm-applet fix just has "darkness@arapiles2"
<darkxst> ev, oh that is because I made that on my notebook.. normally use tim@feathertop.org for patches
<ev> darkxst: cool, thanks!
<mardy> seb128: werid, it says "refreshed", but the timestamp does not change
<mardy> seb128: ah! It's modifying the patch in the original build-area directory!
<mardy> seb128: so, it looks like quilt internally stores the absolute path of the patch
<seb128> mardy, oh, could be, I never tried to do copies arounds like that
<seb128> mardy, that would explain it ;-)
<mardy> seb128: anyway, it looks like that patch is complete; I'll push my branch soon
<seb128> mardy, excellent, thanks!
<mardy> seb128: pushed: https://code.launchpad.net/~mardy/shotwell/update-0.15.0pr1
<mardy> seb128: will you take it over, or is there something left for me to do?
<ogra_> hmpf ... so i merged two binary packages into the same source ... one is Arch armhf, the other is Arch all ... uploading this package it seems the Arch all build is never even attempted
<ogra_> http://paste.ubuntu.com/6058571/ is debian/control ... https://launchpad.net/ubuntu/+source/initramfs-tools-ubuntu-touch/0.42 is the package on LP
<cjwatson> ogra_: https://bugs.launchpad.net/launchpad/+bug/1063188
<ubottu> Launchpad bug 1063188 in Launchpad itself "Launchpad doesn't try to build the "all" packages if i386 isn't in the Architecure field" [Low,Triaged]
<cjwatson> ogra_: You could just make it artificially Architecture: any as a workaround, if the Architecture: armhf package can't be made any
<ogra_> yeah, that armhf there is pretty valid, we dont want to roll armhf initrds on x86
<ogra_> but it just strikes me that i indeed also need different targets in debian/rules for that
<seb128> mardy, \o/, I'm taking over from there, thanks!
<lool> mdeslaur: Hey!  would you think you could handle merging of latest sbuild?
<cjwatson> It has a LOT of cross-building fixes.
<lool> mdeslaur: jodh and you are last uploaders, but jodh is currently on leave; we need some cross-build fixes that went into the latest Debian version
<mdeslaur> lool, cjwatson: sure, I'll merge it
<lool> mdeslaur: awesome; happy to test the cross-building once you're done!   :-)
<cjwatson> mdeslaur: Thanks
<davmor2> Guys can I just check with the removal of gksudo is the correct way to trigger a graphical sudo event to use pkexec /path/to/app ?  thanks
<smb> xnox, Just to let you know, I filed bug 1220252 about what we talked this morning
<ubottu> bug 1220252 in compiz (Ubuntu) "[Saucy] 15s delay between login and desktop appearing" [Undecided,New] https://launchpad.net/bugs/1220252
<davmor2> smb: oh I'll go confirm that I thought that was just my hybrid gfx that was causing that but maybe not if others are suffering :)
<smb> davmor2, I believe there are others too :)
<chiluk> slangasek, thanks for the curl upload last week on https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1179781 can I get some love for the apt debdiffs?
<ubottu> Launchpad bug 1179781 in apt (Ubuntu Raring) "If-Modfied-Since undhandled case causes apt lists corruption with https repositories" [Medium,Triaged]
<mdeslaur> lool: new sbuild should be available now, fyi
<dholbach> pitti, bdmurray: I just had a usb-creator crash and I was directed to https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1218178 which was closed as invalid because of outdated libraries - shall I just go ahead and run ubuntu-bug on the crash file=
<dholbach> ?
<ubottu> Error: malone bug 1218178 not found
<lool> mdeslaur: \o/  thanks
<mdeslaur> np
<dholbach> pitti, bdmurray: nevermind, bug filed :)
<slangasek> chiluk: so I was hoping infinity might be interested enough in that bug to sponsor the SRUs, but I guess not :)  I'll see what I can do for you today
<tkamppeter> Has there anything been changed with the uplod to Saucy? Since yesterday my packages which I uploaded to saucy-proposed and got successfully built by the buildds did not get passed over to saucy release.
<chiluk> thanks slangasek
<cjwatson> tkamppeter: Your packages are probably blocked for beta-1 preparation
<tkamppeter> cjwatson, this mail did not rech me.
<cjwatson> Laney: ^-
<hallyn_> stgraber: so i'm still getting "iproute:amd64 is not available, but is referred to by another package." on armhf container creation.  should that have been fixed by your isc-dhcp-client update?
<stgraber> hallyn_: it should have...
<Laney> tkamppeter: It's on the release schedule; will be removed tomorrow
<stgraber> hallyn_: it was still reference by lxc-ubuntu... fixing that upstream now.
<cjwatson> tkamppeter: Also http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html tells you who/where to contact
<tkamppeter> cjwatson, sorry, I was used to these e-mails.
<Laney> It's all a bit new with these dynamic blocks and stuff
<Laney> I think we'll make it more lightweight in future
<stgraber> hallyn_: http://paste.ubuntu.com/6059238/ looks good to you?
 * hallyn_ looking
<hallyn_> stgraber: well I wouldn't say "good" - i hate to think how hacks like that can accumulate, but it's cleaner than anything i've thought of :)  thanks
 * hallyn_ tries it out
<hallyn_> stgraber: worked!  pls add my acked-by, thanks
<stgraber> hallyn_: pushed
<knocte> Cimi: ping
<cjwatson> LoganCloud: I hope you're prepared to deal with any GHC ABI changes resulting from your GHC sync.  We were deliberately holding off on that one
<Laney> oh dear
<arges> hallyn_: hi
<hallyn_> arges: hi
<arges> hallyn_: i'm taking a look at bug 1100843... not sure if you got anywhere with it.
<ubottu> bug 1100843 in qemu-kvm (Ubuntu) "Live Migration Causes Performance Issues" [High,Triaged] https://launchpad.net/bugs/1100843
<arges> My plan was to test precise w/ an older kernel since it doesn't seem to be reproduced on Lucid.
<arges> But I wasn't sure if there was anything else going on before I embark
<hallyn_> arges: no i've not gotten anywhere with it
<hallyn_> that is, i've never reproduced
<arges> hallyn_: ok i'll take a look at it then. thanks
<barry> lool: it seems impossible to update any blueprint work items today
<ev> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: Open, FF | 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:
<sarnold> slangasek: hello :) Do you 'own' the UbuntuHashes webpage? It came up in bug 1219589 that "ubuntu-docs" isn't the best place to assign bug reports for that page, do you have a recommendation for a better package?  https://help.ubuntu.com/community/UbuntuHashes  https://bugs.launchpad.net/bugs/1219589
<ubottu> Launchpad bug 1219589 in ubuntu-docs (Ubuntu) "ubuntu-12.04.3-desktop-amd64.iso md5sum missing from https://help.ubuntu.com/community/UbuntuHashes" [Undecided,Confirmed]
#ubuntu-devel 2013-09-04
<pitti> Good morning
<tvoss_> pitti, ping
<pitti> hey tvoss_
<dholbach> good morning
<darkxst> slangasek, you are patch piloting today?
<Laney> I doubt
<Laney> he'll be around for several hours yet
<darkxst> Laney, oh right, I still cant work out all the timezones ;)
<Laney> I just type "Time in XXX" into google :P
<xnox> I have a few locations in my datetime indicator: a couple across usa, utc, a couple in europe and beijing. =) and steve is west coast.
<xnox> What is the standard location: http://ports.ubuntu.com/ubuntu-ports/ or http://ports.ubuntu.com/ ? they seemed to be the same...?
<cjwatson> d-i prefers the former
<xnox> ok, thanks.
<hyperair> pitti: hid-generic 0005:045E:0762.0019: input,hidraw3: BLUETOOTH HID v0.13 Keyboard [Microsoft Bluetooth Mobile Keyboard 6000 <-- this keyboard has nothing in /sys/class/power_supply/ and nothing in upower --dump
<pitti> hyperair: ah, too bad; thanks anyway! I got three responses for the sysfs dump now, should be enough to construct a test case
<hyperair> :)
<hyperair> okay good
<doko> kees, hardening defaults ping
<pitti> FourDollars: hey, still here?
<pitti> FourDollars: I'm afraid I need some more data for bug 1153488, I followed up there with a question
<ubottu> bug 1153488 in upower (Ubuntu) "Treats bluetooth input device batteries as system power supply" [Low,Triaged] https://launchpad.net/bugs/1153488
<FourDollars> pitti: ack
<pitti> FourDollars: I only became aware that you determine mouse vs. keyboard from the "bluetooth" parent device, and the dumps didn't include those
<FourDollars> pitti: Yes.
<FourDollars> I will collect the data for you. Wait a minute.
<pitti> FourDollars: no hurry; thanks!
<Ampelbein> Hmm: "internal compiler error: Segmentation fault" on armhf and powerpc in the same source file. But not on amd64/i386. Who to contact to get this investigated?
<xnox> Ampelbein: usually you should have pre-processed source file available and together with it you can file a bug against e.g. gcc-4.8
<xnox> Ampelbein: without pre-processed source file there is little to get investigated. Do you have it?
<Ampelbein> xnox: But I have neither armhf and powerpc.
<xnox> Ampelbein: so where did you get the failure?
<Ampelbein> xnox: This happens on the build-servers (https://launchpad.net/ubuntu/+source/mrpt/1:1.0.2-1/)
<Ampelbein> So I would need someone (from canonical?) to copy the preprocessed source out of the build-chroot?
<xnox> Ampelbein: it's gone and destroyed.
<Ampelbein> Hmm, ok.
<xnox> Ampelbein: same is happening in debian https://buildd.debian.org/status/package.php?p=mrpt thus a FTBFS bug can be filed there as well. And on debian there are porters / porter boxes that a few people have access to to re-run builds.
<FourDollars> pitti: There is no output from `grep -r . /sys/class/power_supply /sys/class/bluetooth`. Change it to `grep -r . /sys/class/power_supply/*hci* /sys/class/bluetooth/*hci*`?
<Ampelbein> xnox: Ok, will file a bug in Debian, thank you.
<knocte> Cimi: ping
<pitti> FourDollars: hm, should be necessary
<pitti> FourDollars: are you running saucy?
<pitti> FourDollars: in that case, it might be easiest and best to install umockdev and do "umockdev-record --all > /tmp/out.txt" and attach that
<FourDollars> pitti: no. I run Ubuntu 12.04.
<pitti> FourDollars: this will provide a complete dump of all devices
<pitti> FourDollars: ah, ok
<pitti> FourDollars: ah, perhaps this:
<pitti> grep -r . /sys/class/power_supply/* /sys/class/bluetooth/*
<FourDollars> ok
<FourDollars> pitti: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/1153488/comments/23
<ubottu> Launchpad bug 1153488 in upower (Ubuntu) "Treats bluetooth input device batteries as system power supply" [Low,Triaged]
<pitti> FourDollars: splendid, thank you!
<FourDollars> pitti: no problem. :)
<slangasek> darkxst_: yes, what's up?
<JoshStrobl> fwd from #ubuntu-quality:  Would this be the right place to go if I wanted to propose a particular application be removed from USC?
<tedg> ev, Reading your mail about high CPU usage services.
<tedg> ev, Seems to me that we could make it opt-in.  Then "bringing it to the desktop" would be a service by service thing.
<tedg> ev, Perhaps by adding a stanza to the upstart job config?
<tedg> ev, Something similar to the respawn limits
<ev> tedg: so the whitelist approach was discussed but the worry was that we wouldn't catch things like the ueventd bug
<ev> because we couldn't anticipate them going proper mental
<tedg> ev, The whitelist would be "everything on phone" where the set is smaller, no?  I mean we could grep for it and generate bugs.
<ev> tedg: hm? I mean in the general sense, going with a whitelist approach on the desktop means that we'll miss whatever we don't anticipate spinning out of control
<ev> unless I misunderstand what you're suggesting?
<tedg> ev, Sure, on the desktop.  But I think that it's an unbounded problem to watch everything.  You don't want to kill my SETI@Home.
<pitti> or totem or the flash plugin, etc. (this has already been discussed via mail)
 * tedg has a prime refactorting botnet.  No reason.
<pitti> tedg: hah, recovered your lost secret GPG key yet? :-)
<ev> true, so whitelist rather than blacklist might be best
<ev> tedg: would you mind following up to the ML post with this? :)
<tedg> ev, Heh, sure.
<pitti> would "everything that provides a D-BUS service" be a good first bite into teh whitelist?
<tedg> pitti, No, but I have kees' so we're good, mine isn't as useful.
<tedg> pitti, +1
<tedg> Perhaps we could detect the case and generate a recoverable error for folks not in the whitelist.
<hallyn_> jamespage: hey, are you around still?
<jamespage> hallyn_, yes
<hallyn_> jamespage: was wondernig if you'd had any thoughts on the likewise-open bug situation
<jamespage> hallyn_, I've not look at it hard yet
<jamespage> but I reckons there are a load of bugs that can be duped up
<jamespage> I'm assuming that ubuntu-server was not a bug subscriber until recently right?
<hallyn_> jamespage: ok.  I will probably take an overly broad brush and do that, and beg the reporters' forgiveness if I err.
<hallyn_> that's my assumption too :)
<hallyn_> all the old bug will drown out new, valid ones, so i'd like to just mark them invalid actually
<hallyn_> and ask the reporters to respond and re-set to new if they still have the problem
<pitti> hallyn_: you could set them to "incomplete" with "does this still happen in saucy?" and let them time out
<jamespage> pitti, alot of them look like dist-upgrades to lucid
<jamespage> so I'd rather not do that
<pitti> not for those where this quetsion obviously doesn't make sense, of course :)
<hallyn_> jamespage: so if a dist-upgrade to lucid failed on likewise-open, is it fair to assume that the reporter must've gotten past it by now?
<hallyn_> i.e. mark invalid and ask to re-open?
<hallyn_> any which were not dis-tupgrades, set to incomplete?
<jamespage> sounds reasonable
 * jamespage worries about the state of likewise-open in distro
<jamespage> it does not get much love anymore
<hallyn_> pitti: thanks for the suggestion, will do that for a bunch
<hallyn_> jamespage: yeah i've considered spending a day to try it out so i can be better able to look over it
<hallyn_> wasn't kirkland at one point our resident expert? :)
<jamespage> maybe - I'm not sure
<jamespage> I'm not 100% clear why its in the supported seed
<hallyn_> i just .. have *never* used it.
<hallyn_> yeah
<hallyn_> Daviey: ^ do you know how that showed up?
<kirkland> hallyn_: jamespage: likewise?  I think that was dendrobates' doing
<kirkland> hallyn_: jamespage: I think dendrobates, soren, or ttx might remember
 * jamespage is slightly embarresed he had to lookup who dendrobates whas
<jamespage> (sorry)
<kirkland> jamespage: heh :-)
<hallyn_> kirkland: i meant it showing up in server supported seed
<kirkland> jamespage: hallyn_: yeah, looking at likewise-open's debian/changelog, it was dendrobates (Rick Clark) that packaged it originally;  I think he pushed the MIR as well
<Sweetshark> no seb128 today?
<kirkland> hallyn_: https://bugs.launchpad.net/ubuntu/+source/likewise-open/+bug/201537
<ubottu> Launchpad bug 201537 in likewise-open (Ubuntu) "MIR for likewise-open" [High,Fix released]
<kirkland> hallyn_: oh, that one is zul's :-)
<jamespage> oh zul... deary me
<ttx> kirkland: at those times, integration with AD was seen as a key feature
<zul> what did i do now?
<ttx> and likewise-open was basically the component that was supposed to allow us doing it
<ttx> so it was more of a product management thing
<kirkland> ttx: :-)
<kirkland> ttx: so let's blame nijaba, then :-)
<jamespage> I can see the context - thanks for clearing that up ttx
<ttx> always blame nijaba
<kirkland> ttx: howdy, btw!
<ttx> howdy!
<dendrobates> jamespage: lol
<jamespage> dendrobates, sorry :-)
<dendrobates> no worries
 * kees looks forward to tedg's impersonation of him
 * tedg does his best kees: "Oh, look, I've got a goatee and all my IP traffic is coming from Siberia"  ;-)
 * tedg probably shouldn't quit his day-job
<kees> tedg: hehe, A++ would be impersonated again
#ubuntu-devel 2013-09-05
<kees> infinity: why are there hosts on the internet with unresolvable names?
 * slangasek looks at kees blankly
 * sarnold hands kees a soapbox
 * sarnold grabs some popcorn
<kees> slangasek: I'm following this eglibc bug, and I'm just trying to understand the parameters of the problem.
<slangasek> hah
<kees> it sounds like there are "legit" hosts that have a leading (or trailing) "-" character in their name. glibc (correctly?) follows RFC and refuses to look those up.
<slangasek> so "unresolvable names" meaning "my hostname does not map to an IP"?
<slangasek> fun
<kees> like "cdn-9-.amazon.com" or something, let me find the bug. I've been reading comments out of order and in email.
<kees> 144431
<kees> example was "-kol.deviantart.com"
<kees> bind has no problem with it.
<kees> I'd learn towards supporting this, if bind supports it.
<slangasek> kees: there are different RFCs for "this is a legal DNS name" vs. "this is a legal hostname".
<slangasek> indeed, all SRV records are built around this fact
<kees> slangasek: I haven't looked into that yet. I just got as far as making the simple observation that my bind server was involved in a successful query of this seemingly "illegal" name with no problem.
<kees> (which is certainly UNtrue for hosts that have "_"s in their name, bind refuses to resolve those)
<slangasek> ah, does it?
<slangasek> I wonder why bind is picking and choosing :P
<kees> that's my memory -- I haven't retested that recently, though.
<kees> I'm mostly looking at it from a practical point of view: there are actual hosts doing this, and bind supports it, so why "filter" these results.
<kees> I haven't checked other OS resolvers, though.
<slangasek> so you think we should ignore the RFC?
<kees> possibly, yes. If glibc is the only thing ignoring this aspect of the RFC, it doesn't seem sensible to retain that interpretation. it puts Ubuntu at a disadvantage for no good reason.
<slangasek> s/ignoring/respecting/, you mean?
<kees> yeah
<Gsport> www.google.pt/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CD8QFjAB&url=http%3A%2F%2Fwww.computerworld.com%2F&ei=2NEnUvXwOoiRhQeSj4GoCw&usg=AFQjCNGWIgkWtnvRRqA8PHdgccurO6diMA&bvm=bv.51773540,d.ZG4
<Gsport> apply
<infinity> kees: Are you trolling me?
<kees> infinity: no, I'm serious. I'm trying to evaluate this from a practical perspective.
<kees> infinity: if the majority of internet infrastructure DNS accepts a non-RFC name, and only glibc-based OSes can't resolve it, it seems silly to wave the RFC as the reason.
<kees> we've had plenty of things like this in the past (congestion control!), so it seems the same, except that a leading/trailing "-" is extremely rare.
<kees> but BIND seems to have no problem with it. I haven't tested OSX or Windows, but it might be worth doing.
<infinity> kees: The claim in the bug is that OS/X and Windows resolve it (which would make sense, or I couldn't see deviantart's admins not noticing).  Maybe I'm just being pedantic, but the argument that "if there's a host with that name on the internets, you must resolve it" is complete BS.
<infinity> kees: Cause I can make BIND give you an A record for a whole lot of very-non-RFC-compliant names.
<infinity> kees: Still, deviantart and tumblr are run by nerds, just like us.  The correct solution seems to be to ask them to be RFC-compliant, not to say "well, they screwed up, so we'd better toss the standard out the window".
<infinity> kees: I can see the argument for "sure, we'll let this specific case slide", but what happens when it's another, and another?  Maybe the Windows resolver doesn't filter particularly sanely at all, and lets you try to resolve any old string (probably not, but maybe?), which would let people keep slippery sloping this mistake into madness.
<pitti> Good morning
<chiluk> infinity slangasek you still up/around ?
<chiluk> got a bunch of e-mails about the apt upload "  We were unable to import the file because of errors in its format:
<chiluk> No header found in this pofile"  any thoughts ?
<chiluk> it looks like it built fine though.
<infinity> chiluk: Don't worry about it.
<chiluk> that's what I was leaning towards.
<infinity> chiluk: Known bug.  Not your problem.
<chiluk> infinity thanks, I was really getting tired of that bug.
<dholbach> good morning
<dpm> cjwatson, dholbach, I'm not sure if I'm supposed to be able to do that, but I was trying to unpack a click package to modify a file and repackage it again. Here's what I got: http://pastebin.ubuntu.com/6065919/ - is this a bug in click build, or should I do it differently/not at all?
<cjwatson> dpm: can you give me a URL for that package so that I can investigate?
<cjwatson> dpm: oh actually never mind
<cjwatson> dpm: you shouldn't do it like that :-)
<dpm> thought so :)
<cjwatson> dpm: because click build moves manifest.json off to a different place when it builds, but it needs manifest.json
<dpm> aha
<cjwatson> dpm: you could probably do it with "dpkg-deb -R com.ubuntu.developer.davidplanella.qreator_0.1_all.click qreator-click && mv qreator-click/DEBIAN/manifest qreator-click/manifest.json && rm -rf qreator-click/DEBIAN && click build qreator-click" or something like that, but that might have other oddities and I don't recommend this workflow
<dpm> cjwatson, so I guess that means I shouldn't unpack and repackage click packages and I should simply do 'click build' on the original source tree?
<cjwatson> dpm: yes
<dpm> ok, thanks
<Laney> ev: I got a work item to ask you about your plans for finishing the Diagnostics panel in system-settings
<Laney> well, that one was easy
<ev> Laney: lol, hi
<Laney> hello :P
<ev> finishing how? It should largely be operation, save viewing existing reports which doesn't seem to flip over to the browser
<Laney> ev: https://wiki.ubuntu.com/ErrorTracker#Client_design the extra things on the design there
<Laney> Unless they are all not in scope
<ev> Laney: we're not yet monitoring system information (metrics) or the location of wifi access points
<ev> not sure who would be responsible for the latter one
<Laney> yeah I thought that one might be a bit speculative
<Laney> fair enough
<xnox> Laney: any idea why system-settings is using qmake and not cmake? have you seen a cmake based qml extensions?
<Laney> It is because it was
<Laney> and I don't know what the second question means
<xnox> (which actually use cmake to build, not merely providing cmake module for others to use cmake to find/link against the extension)
<Laney> oh I see, hmm, no
<Laney> but I haven't really looked at build systems for random qml things
<xnox> ok.
<Laney> try asking Mirv
<Laney> and for a less-facetious answer - mardy wrote the initial implementation and that used qmake
<Laney> we just carried that on
<xnox> sure.
<Laney> I think we wouldn't mind if it were ported, but nobody is going to prioritise that right now
<Laney> if a conversion turned up and was feature-equal then we'd take that
<xnox> Laney: right, there are some notices that cmake is the standard for our projects.
<Laney> so I heard
 * Laney whispers (autotools)
<ev> ugh, autotools
<Laney> hahaha
<Laney> never fails
<ev> :D
<darkxst> ev, what happened with bug 1219188?
<ubottu> bug 1219188 in gnome-shell (Ubuntu) "Add support for separate background on lock screen" [Undecided,In progress] https://launchpad.net/bugs/1219188
<darkxst> we really need atleast the gnome-shell patch in asap, no the blocks are lifted ;(
<ev> darkxst: apologies - I ran out of time during my patch pilot session. It'll need to be picked up by whomever is next at bat. I'd volunteer my time but the rest of the week has me completely committed to other work.
<darkxst> ev, ok. but really the settings changes were supposed to come last ;(
<ev> ah right, the bug made no mention of that
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: Open, FF | 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: xnox
<ChrisTownsend> xnox: ping
<xnox> ChrisTownsend: hola! =)
<ChrisTownsend> xnox: Hi, I was wondering if you had time during your pilot session to (re)review https://code.launchpad.net/~townsend/ubuntu/saucy/nautilus-share/fix-lp1214534/+merge/181160?
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: Open, FF | 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: xnox, sconklin
 * dholbach hugs sconklin and xnox
<ChickenCutlass> pitti, are you around?
<ogra_> pitti, are there any known issues with the hwdb stuff of systemd ?
<ogra_> ChickenCutlass  has a werid socket error in his syslog and some device issues
<pitti> ChickenCutlass: hello
<pitti> ogra_: no, not to me
<ChickenCutlass> pitti, I just upgraded my system and can no longer use adb
<ChickenCutlass> pitti, I get this error in dmesg
<pitti> ogra_: well, except for some keymap regressions, I have a fix for that queued, but not uploaded yet (freeze)
<ChickenCutlass> pitti, [   19.202700] systemd-udevd[3565]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' 'socket:@/org/freedesktop/hal/udev_event': No such file or directory
<pitti> ChickenCutlass: apt-get purge hal :)
<ChickenCutlass> pitti, ok
<pitti> it should have died years ago, too bad we still have it in the archive
<ogra_> why do we btw ?
<pitti> (together with the remaining handful of rdepends)
<ogra_> i thought you ripped all deps out in raring
<ChickenCutlass> pitti, I assume I need to reboot
<pitti> ChickenCutlass: no, not really; also, that error is quite harmless
<ChickenCutlass> pitti, hmm ok I thought it might be related to not being able to use adb
<pitti> ogra_: I killed all main rdeps in oneiric or so, and every release drops a few more universe through Debian
<ChickenCutlass> pitti, it was just working then upgraded -- now not
<pitti> ChickenCutlass: hm, works fine here; what does it complain about?
<ogra_> ChickenCutlass, that might just be a bug in the udev rules
<pitti> ChickenCutlass: did you reboot after dist-upgrade?
<ChickenCutlass> pitti, device not found
<ogra_> we need to revisit them one day
<pitti> the rule works fine here, I get a proper ACL
<ogra_> ChickenCutlass, adb kill-server && sudo adb start-server
<ogra_> then try again
<ChickenCutlass> ogra_, tried all that
<pitti> I don't need sudo here (but it's good for debugging anyway)
<pitti> ChickenCutlass: did you reboot after dist-upgrade?
<ogra_> oh, and it didnt work ?
<ChickenCutlass> pitti, yes
<ChickenCutlass> ogra_, let me try a new USB cabel
<pitti> ChickenCutlass: do you see the device in lsusb?
<ogra_> yeah, if that dosnt work, blame the kernel
<pitti> ChickenCutlass: and does the device think it's connected?
<ChickenCutlass> pitti, ogra_ lol -- was the cable
<ChickenCutlass> sorry
<ogra_> heh
<ogra_> good
<pitti> ChickenCutlass: ah, sad for the broken cable
<ogra_> saves us an upload
 * ChickenCutlass throws out this cable
<pitti> ChickenCutlass: it did have a positive side, you got rid of a zombie daemon on your system :)
<ChickenCutlass> lol
<pitti> ogra_: oh, and another reason was that when I annouced the intent to kill hal here like half a year ago, two people shouted "noo!"
<pitti> because allegedly you'll need it for watching DRMed videos on youtube, or something such
<pitti> that sounds very weird to me, and I really doubt that it even works, but I didn't hear an update for that
<pitti> mdeslaur: ^ was that you?
<ogra_> pitti, pfft, then i could have kept usb-imagewriter in the archive ... evil people, you shouldnt listen to them
<pitti> ogra_: well, hald is definitively broken in saucy, so that's fine :)
<ogra_> haha
<mdeslaur> pitti: adobe flash uses hal to extract device serial numbers to play drmed content, such as amazon videos
<mdeslaur> pitti: yes, that would have been me
<pitti> mdeslaur: ah, ok; well, that would not work any more now anyway
<mdeslaur> pitti: I believe chrisccoulson knows the exact details
<pitti> mdeslaur: that probably wants a simple shim which just provides that D-BUS API, but not everything else?
<chrisccoulson> pitti, mdeslaur, yeah, i wrote one ages ago
<chrisccoulson> but i never really did anything with it
<chrisccoulson> and priorities changed :)(
<pitti> strings /usr/lib/flashplugin-installer/libflashplayer.so | grep hal
<pitti> â nothing of interest here
<pitti> and no hits for "Hal"
<mdeslaur> pitti: did you xor it with "adobeencryption"? /joke
<pitti> and it's not linked to libhal1 either
<chrisccoulson> pitti, yeah, it downloads the drm module at runtime :)
<chrisccoulson> i've already got a shim that works for it
<pitti> mdeslaur: rot26 is a lot safer!
<chrisccoulson> i'll dig it off my old laptop
<mdeslaur> chrisccoulson: https://code.launchpad.net/~chrisccoulson/+junk/flash-hal-helper
<chrisccoulson> mdeslaur, oh, yeah, that looks like it
<chrisccoulson> not sure if it's up-to-date though
<pitti> hal rdepends: wmbattery, moovida-plugins-good, dell-recovery
<pitti> that's not too bad
<pitti> I love edubuntu-live, which has a Conflicts: hal :)
<mdeslaur> lol
<pitti> libhal1 rdeps: xmbc-bin, libthunar-vfs-1-2 (ought to be obsolete), libsynce0 (unmaintained), librapi2, libhd16
<pitti> seems only "squeeze" still uses the old thunar bits, and it's not seeded for xubuntu, so it can probably go, too
<pitti> who does xubuntu these days?
<smartboyhw> pitti, I think the Xubuntu people is going to be unhappy with that:P
<pitti> why?
<smartboyhw> (I mean, the "who does Xubuntu these days?")
<smartboyhw> pitti, because Xubuntu is increasingly popular:P
<pitti> smartboyhw: sorry, does that sound rude? certainly unintended
<pitti> smartboyhw: yes, I know (I have worked on it myself for half a year)
<smartboyhw> pitti, just weird:P
<pitti> smartboyhw: but I'm interested in talking to the Xubuntu devs before I kill anything
<Laney> he was asking who the main developers were
<smartboyhw> pitti, ah
<smartboyhw> micahg, ochosi, jjfrv8
<smartboyhw> knome
<cjwatson> smartboyhw: "who uses Xubuntu these days?" might have justified that response, but not what pitti actually said
<smartboyhw> cjwatson, I would thought it should have been "Who's working on Xubuntu these days?"
<smartboyhw> Does can mean a lot:p
<Laney> assume good faith :-)
<cjwatson> "does" would not mean "uses" in my book
<cjwatson> too active
<smartboyhw> cjwatson, rather, it is wrongly used here that shouldn't even appear in any book:P
<pitti> anyway, I indeed meant "develops" here
<cjwatson> from this native English speaker, it isn't wrong
<smartboyhw> pitti, most of the Xubuntu developers are not here
<smartboyhw> So, better if you go back into #xubuntu-devel
<pitti> smartboyhw: ack, thanks
 * pitti files bug 1221254 to track
<ubottu> bug 1221254 in thunar-vfs (Ubuntu) "kill hal for good!" [Undecided,New] https://launchpad.net/bugs/1221254
 * pitti goes to un-hal-ify some bits, like libsynce
<asac> plars: seems the .1 test run nears its end
<asac> ogra_: did we do manual smoke on .1 yet for mako/maguro?
<asac> popey: have you tried .1? we want to push that most likely
<ogra_> not me
<asac> kk
<ogra_> probably also -> touch
<asac> ogra_: so unless we have a patch for security
<asac> nevermind
<ogra_> well, we have a patch, it was supposed to work
<plars> asac: on touch_ro, they still have a ways to go
<Laney> xnox: hah, we just got a branch to convert it to cmake
<xnox> Laney: speak of the devil, excellent! Then I can steal that for my little experiment !
<Laney> it's not complete yet
<ockham> could someone do an SRU for this?
<ockham> https://bugs.launchpad.net/ubuntu/+source/popularity-contest/+bug/858697
<ubottu> Launchpad bug 858697 in popularity-contest (Ubuntu Precise) "daily cron script complains about packages not being installed" [Medium,Triaged]
<ockham> has been fixed in debian and newer ubuntus already, but not in precise
<smoser> curious. what is the date string at
<smoser> http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-i386/
<smoser> i'm guessing thats installer version or something ?
<stgraber> smoser: debian-installer source package version number
<smoser> stgraber, thanks.
<kirkland> I'm on Ubuntu 13.10, I installed python-daemon, but its libraries aren't available to me in python3 ... is this a packaging bug, or a bug or feature request in the library itself?
<cjwatson> python-foo => Python 2
<cjwatson> python3-foo => Python 3
<cjwatson> If the upstream code supports Python 3 at all, it's a packaging bug for not building a python3-daemon package; if not, it's an upstream bug/feature-req
<kirkland> cjwatson: and if python3-daemon doesn't exist in the archive, does python-daemon's source need to be updated to build that binary package too, or does it need to be created new, from scratch?
<kirkland> cjwatson: I see
<cjwatson> Depends
<cjwatson> Most upstreams go for supporting both out of the same code base, either directly via bilingual code, or by way of 2to3
<cjwatson> A few upstreams release separate source packages for Python 3
<cjwatson> There isn't a single answer that suits everyone
<cjwatson> (My own preference is bilingual code)
* skaet changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | 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: xnox, sconklin
<xnox> yeap, and bilingual code is relatively easy to write for python. 2.7 & 3.x is easy, but it's even possible to do 2.3 => 3.3 compatible code.
<cjwatson> 2.3 sounds like an exercise in pain
<xnox> cjwatson: i did that for apparmor I think, was fun =)
<cjwatson> (also an exercise in futility, given how few users it must have these days)
<xnox> it would be sad to regress support in apparmor though, just to gain 3.x which at the time probably had less usage than 2.4
<cjwatson> for 2.3 the thing I remember is that we made 2.4 the default in Ubuntu 5.04
<xnox> oh =) yeah old.
<xnox> way before my time.
<slangasek> awe: did you get an answer to your concern about packaging changes needed for ofono to report to whoopsie?
<awe> no
<slangasek> awe: I think that previously we weren't getting reports because ofonod on Touch was coming from a ppa; but now that that's resolved I'm not aware of any packaging issues that are outstanding
<slangasek> ev: ^^ ?
<slangasek> awe: however, we're not actually getting useful errors.u.c data from Touch because we're still blocked at the moment on getting armhf cross-retracers wired up
<ev> we should still get reports regardless of whether or not a package comes from a PPA
<ev> (armhf cross-retracers for errors.ubuntu.com: https://rt.admin.canonical.com//Ticket/Display.html?id=58019 )
<slangasek> ev: ah, right; we do get the reports, but we can't appropriately bucket them without dbgsyms
<ev> the "is this thing in the Ubuntu archive" check is only run for Launchpad bug reports
 * ev nods
<ev> though I'm keen to hear exactly what awe was seeing
<ev> perhaps there's a bug here
<awe> slangasek, so if the -dbg package is screwed up, that would prevent them from showing up, right?
<slangasek> well, I suspect a case of Chinese whispers
<slangasek> rather than an actual bug
 * awe call me confused
<ev> ah right
<slangasek> awe: errors retracers use dbgsym, which are autogenerated on the autobuilders; there may be bugs there, but any -dbg package listed in debian/control should be irrelevant
<awe> ok
<jdstrand> slangasek, bdmurray: any idea why bug #1197049 is not showing up under ubuntu-sdk-bugs on http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-s-tracking-bug-tasks.html? the apparmor-easyprof-ubuntu one shows up under ubuntu-security-bugs, but the qtbase-opensource-src is not showing up under ubuntu-sdk-bugs
<ubottu> bug 1197049 in apparmor-easyprof-ubuntu (Ubuntu Saucy) "SDK applications sometimes create /var/tmp/etilqs_* files" [Undecided,Triaged] https://launchpad.net/bugs/1197049
<awe> slangasek, thanks for the answer re: 13.10 by the way!  ;)-
<jdstrand> slangasek, bdmurray: pmcgowan subscribed ubuntu-sdk-bugs to qtbase-opensource-src it looks like (listed in the 'May also be notified' area of the bug
<slangasek> jdstrand: good question; I defer to bdmurray
<slangasek> jdstrand: I do notice it's listed twice under ubuntu-security-bugs, so maybe there's a bug making the qtbase-opensource-src task be misattributed
<bdmurray> jdstrand: looking into it
<bdmurray> infinity / slangasek: could one of you have a look at bug 1220898? it looks to me like it may be an issue with base-installer
<ubottu> bug 1220898 in ubuntu-release-upgrader (Ubuntu) "generic kernel gets installed in ubuntustudio upgrade." [Undecided,New] https://launchpad.net/bugs/1220898
<infinity> bdmurray: base-installer?  u-r-u reuses d-i components for this?
<slangasek> apparently so
<bdmurray> infinity: yes
<infinity> Ugh.  Sure does.
<infinity> Well, this isn't an "issue" with base-installer, per se, so much as it is that base-installer has never had this logic.
<slangasek> rather seems to me that it shouldn't, though
<infinity> Why does u-r-u try to be so clever about replacing kernels?
<infinity> We offer clean transitional packages for upgrade paths when we mangle kernel flavours, I can't see why the release-upgrader should second-guess any of this.
<slangasek> infinity: originally due to bug #353534 / bug #441629
<ubottu> bug 353534 in update-manager (Ubuntu Karmic) "dapper->hardy->intrepid upgrade path leaves user with unmaintained kernel" [High,Fix released] https://launchpad.net/bugs/353534
<ubottu> bug 441629 in update-manager (Ubuntu Karmic) "Karmic server upgrade loses kernel metapackages" [High,Fix released] https://launchpad.net/bugs/441629
<infinity> slangasek: From the code comments, I'm assuming this is all because the CDs didn't ship the transitional packages.
<infinity> slangasek: Seems like that would have been the saner fix.
<infinity> (And we can certainly make sure the 13.10/14.04 CDs have the -pae transitional packages)
<slangasek> no, the original rationale was "the metapackage you had installed still exists but is no longer the thing we want you to be using"
<infinity> Anyhow, we could *also* make base-installer list lowlatency as a valid kernel, which would fix this with minimal fuss in the short term.
<slangasek> I'd rather see this code culled instead
<slangasek> because it seems like the use case it was added for was a one-time thing back in 2008, we ought to get rid of the code instead of kicking the can down the road
<infinity> slangasek: The old bugs looked a lot like the transitional packages were poorly done back then.  Talk of things being removed that shouldn't be, etc.
<infinity> slangasek: We do still have an outstanding transition here (pae -> generic in 14.04), but it should also be done correctly this time.  Things shouldn't magically disappear.
<slangasek> infinity: per the bug description, -386 was *not* a transitional package, but a "deprecated" flavor that we wanted users to move off of
<infinity> slangasek: Yeah, a tiny bit different this time.
<slangasek> because the meaning of the package hadn't changed, but we wanted to get users moved to a better kernel for their hardware... pae->generic is the opposite
<infinity> (Though, we have a similar thing with generic (nonpae) -> generic (pae), and this time we handle it with a preinst check, I think.  We could have done what with 386 -> generic too)
<slangasek> anyway
<slangasek> cull the code
<infinity> I'm all for the culling.
<bdmurray> So just remove the kernel checks from ubuntu-release-upgrader altogether correct?
<infinity> Bonus points if you can find the original commits to sort out what to revert.
<infinity> But basically that, yes.
<infinity> I think there is (or used to be) logic that tries to make sure you have "linux-$flavour" installed, matching the running kernel.  That's probably a sane thing to do.
<slangasek> so following this thread, I think we want to cut out the dapper/hardy upgrade quirks in DistUpgrade/DistUpgradeQuirks.py too, since they also depend on the base-installer kernel detection
<slangasek> and should never be hit on upgrade to saucy
<slangasek> infinity, cjwatson, bdmurray: ^^ objections?
<infinity> +1 to removing ancient quirks.
<slangasek> """ this function works around quirks in the breezy->dapper upgrade """
<slangasek> mmmhmm :)
<bdmurray> seems like a good idea to me
<slangasek> bdmurray: lp:~vorlon/ubuntu-release-upgrader/lp.1220898 pushed, raising an MP now.  (Haven't actually tested it yet)
<lool> is there a good sample package for building multiple flavors of a package with dh?
<lool> (multiple configure runs, make install etc.)
<lool> well I guess I can just hook into override_dh_auto_configure: override_dh_auto_build: etc.
<Laney> Both packages I know that do this use CDBS
<Laney> glib2.0 gtk+3.0
<Laney> Not exactly simple examples though
<slangasek> lool: hmmmm.  I remember doing something like that recently but don't remember now which package it was
<slangasek> I wonder if it was android-tools
<slangasek> well... possibly it was, but I guess that's not a great example :)
<slangasek> bdmurray, infinity: ok, have actually tried building u-r-u now and it fails the test suite for me due to testing some functions that have gone away. :)  I've pushed one more commit but still have another failing test that I'm trying to figure out now
<lool> slangasek: ok, thanks
<slangasek> anyway, yeah, I don't know of a way to do it without overriding the dh_auto_* commands
<lool> slangasek: (funnily enough, I did quite some work to cleanup the android-tools patching to get in sync with Debian)
<slangasek> :)
<slangasek> lool: so this is frequent enough of a request that I think we need to extend dh to support multiflavor builds natively
<slangasek> wishlist bug?
 * lool checks if there's one
<slangasek> bdmurray, infinity: ah, the remaining test suite failure is a pre-existing failure, score
<slangasek> build-area/ubuntu-release-upgrader-0.201/tests/test_quirks.py", line 153, in testFglrx
<slangasek>     self.assertTrue(q._supportInModaliases("fglrx", mock_lspci_good))
<slangasek> nose.proxy.AssertionError: False is not true
<slangasek> bdmurray, infinity: oho, the remaining build failure is because the test suite requires you to have restricted enabled in your build environment, what a silly thing.  Ok, test suite passes now.
<infinity> slangasek: If dh(1) supported multiflavour builds in a clean way, I bet I could switch glibc.   Could take a few months, but I bet it could be done. :P
<slangasek> infinity: this is very tempting :)
<infinity> There'd be a sick sense of accomplishment in reducing glibc's thousands of lines of debian/* to a few lines of debian/rules.
<lool> slangasek: actually fairly clean!  http://paste.ubuntu.com/6067962/
<slangasek> yep
<lool> (I could have avoided the repetition, but seems more readable this way)
<slangasek> what's $(CONFIGURE_FLAGS)?
<lool> slangasek: CONFIGURE_FLAGS := --with-liboil --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
<lool> maybe I can drop the libdir nowadays
<slangasek> ok - presumably that line will make it back into the final debian/rules, though :)
<lool> slangasek: yeah, it's just an extract
<lool> there was an irrelevant dh_install snippet too
<infinity> lool: BTW.  France is bacon?
<infinity> lool: http://i.imgur.com/xFO11dk.png
<slangasek> that's *sir* france is bacon to you
<mbiebl> lool: i'm basically doing exactly the same in one of my packages where I build a deb and udeb flavour
<mbiebl> would be nice to avoid the boiler plate, but it's good enough for now
<lool> infinity: I know another one with a John O'Bacon!
<slangasek> infinity: I find that all the funnier for understanding the reference before reading the story :)
<infinity> slangasek: Plot twist: You're the original reddit commentor?
<slangasek> that would be a good plot twist
<mbiebl> slangasek: I think what would help also if packages which are part of a transition are auto-rejected
<mbiebl> so maintainers who do not follow/care
<mbiebl> can not disturb ongoing transitions
<slangasek> mbiebl: what transitions are you talking about?  (is this a response to my ubuntu-release post?)
<mbiebl> slangasek: oops, sorry
<mbiebl> entirely wrong channel
<slangasek> heh :)
<mbiebl> (was talking to jcristau...)
<slangasek> wow, that's quite the name hash collision :)
<mbiebl> hehe
<mbiebl> slangasek: I'm currently discussing with jcristau on #debian-gnome that the current way of planning and executing transitions is a bit sucky
<mbiebl> (to say the least)
<mbiebl> especially for software like GNOME, where lot's of transitions are intertwined
<mbiebl> so doing them bit by bit requires lots of backporting work to make that possible
<mbiebl> and somehow, I switched focus in one of my last replies :-)
<mbiebl> slangasek: how you managed to be the receiver of that message, I can't explain
<darkxst> xnox, hey can you take a look at Bug 1219188
<ubottu> bug 1219188 in gnome-shell (Ubuntu) "Add support for separate background on lock screen" [Undecided,In progress] https://launchpad.net/bugs/1219188
<Spee_Der> Can I get help with gpredict here please ?
<bdmurray> Sweetshark: I'm looking at the libreoffice in the raring proposed queue and noticed there are some patches not in the series file and a patch in the series file not in the diff
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | 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: xnox
<bdmurray> charles: do you have any information on what a crash from bug 1122596 might look like?
<ubottu> bug 1122596 in libappindicator (Ubuntu Precise) "Race condition in app_indicator_init() causes application crash" [High,Fix committed] https://launchpad.net/bugs/1122596
<bdmurray> charles: we'd like to be able to confirm it isn't happening anymore so we can release the precise sru
 * charles looks
<charles> hm, disappointing that there's not a stacktrace on the ticket
<charles> bdmurray: it would show up as dereferencing a NULL pointer, the self->priv field
<bdmurray> charles: would the crash be filed about some other package though?
<charles> bdmurray, likely candidates for where this would happen would be
<charles> app-indicator.c, bus_creation(), NULL dereference on app->priv->connection
<charles> and much less likely, in app-indicator.c, theme_changed_cb(), in "if (priv->dbus_registration != 0)"
<charles> wrt showing up in a different package... hmm
<charles> bdmurray, I guess it's possible. If so, the stacktrace would show the levels app_indicator_init() -> bus_creation() -> crash
<charles> bdmurray: if you're trying to eliminate candidate tickets -- if those aren't in the stacktrace, it's not #1122596
<charles> bdmurray: is this helpful? I'm not sure that I'm answering the right question :-)
<bdmurray> charles: a bit thanks
<cjwatson> lool: I do multiple configure passes with grub2 though it isn't exactly simple
<cjwatson> FWIW
<cjwatson> lool: though maybe openssh is a better example; it's certainly closer to what you ended up with
<sarnold> bdmurray: how shall I ask for an enhancement to the text of one of your bugbots? I want this text to include the relevant release, "The verification of this Stable Release Update has completed successfully and the package has now been released to -updates."... see e.g. https://bugs.launchpad.net/maas/+bug/1171418 comments #8 and #9 -- it took me a while to figure out that the verification had been only been done once, not multipl
<ubottu> Launchpad bug 1171418 in maas (Ubuntu Quantal) "MAAS fails to power up machines when trying to install nodes" [High,New]
<cjwatson> sarnold: that's in lp:ubuntu-archive-tools, you can propose a merge
<sarnold> cjwatson: thanks
#ubuntu-devel 2013-09-06
<sarnold> cjwatson: hey, I think I proposed a merge request :) please let me know if I got that right. thanks!
<Noskcaj> How can i apply to be a MOTU if i cannot attend either 1500 or 1900 UTC meetings?
<Noskcaj> Also, can someone re-run the buildd for language-pack-mg  on i386?
<StevenK> Noskcaj: Retried
<slangasek> Noskcaj: I would expect such things could be handled via the mailing list instead if need be
<Noskcaj> slangasek: ok, thanks
<Noskcaj> Then is there anyonewho can add a testimonial to https://wiki.ubuntu.com/Noskcaj#MOTU ?
<slangasek> Noskcaj: typically you want to hound people who have sponsored uploads for you :)
<Noskcaj> slangasek: i will, just thought i would make a generic post first
<pitti> Good morning
<Caribou> ScottK: ping
<smartboyhw> Ubuntu SRU team: Can you please move https://launchpad.net/ubuntu/+source/ibus-cangjie/0.0.1~git20130325-0ubuntu1.1 to raring-updates? All of the bugs has been tested
<smartboyhw> And verified
<dholbach> good morning
<tjaalton> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | 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: tjaalton, xnox
 * dholbach hugs tjaalton
<tjaalton> dholbach: will be a short shift though ;)
<tjaalton> or :/
<xnox> darkxst: gnome-shell is really outside of my area
<xnox>  / comfort zone
<tjaalton> Sweetshark: need a sponsor for bug 1204449?
<ubottu> bug 1204449 in libreoffice (Ubuntu Raring) "[SRU] LibreOffice 4.0.4 for Ubuntu 13.04 (raring)" [Undecided,New] https://launchpad.net/bugs/1204449
<Caribou> ScottK: still around ?
<Sweetshark> tjaalton: https://launchpad.net/ubuntu/raring/+queue?queue_state=1 <- its already in the queue
<xnox> tjaalton: are you syncing packages at the moment, without closing bugs? =) or I am stopping with somebody else?
<xnox> hm looks like you also are stumbling on things that are sponsored but not marked as such.
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | 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: tjaalton
<tjaalton> xnox: oh I can close those too
<tjaalton> and yes syncing stuff that are accepted/bugfix releases
<Laney> tjaalton: syncpackage has a flag for that
<tjaalton> Laney: right, forgot that it exists
<xnox> tjaalton: -s to specify who you are sponsoring for and -b NNNNNNN with the bug number.
<tjaalton> next time :)
<Caribou> is there a 'clean' way to reorder quilt patches, other than editing the series file ?
<Noskcaj> Can whoever maintains http://qa.ubuntuwire.org/ftbfs/ add a category that shows the debian version and/or if the package built in debian? That would make finding the cause so much easier
<jpds> Noskcaj: Use the sauce.
<jpds> Noskcaj: https://code.launchpad.net/ubuntuwire
<Noskcaj> jpds, thanks. I have no ability with any coding languages though
<jpds> Noskcaj: Then, you could file a bug, or ask wgrant nicely.
<Noskcaj> do both of those things
<Laney> Or take the chance to gain the ability
<Noskcaj> *i'll do
<Noskcaj> Laney, It's not that easy
<Laney> Surely not, things often aren't
<Noskcaj> wgrant, bug 1221640
<ubottu> bug 1221640 in FTBFS Report "Add a debian status column" [Undecided,New] https://launchpad.net/bugs/1221640
<tjaalton> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | 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:
<xnox> happyaron: kylin wallpapers are accepted into the archive, you may want to adjust your seeds to install the main wallpaper package by default.
<happyaron> xnox: thanks, I have a question, where is the configration of sepcifying default wall paper?
<dholbach> seb128, Mirv: qtcreator built on armhf, currently uploading: https://launchpad.net/ubuntu/+source/qtcreator/2.7.1-0ubuntu10/+build/4938521
<seb128> dholbach, good
<dholbach> seb128, will qtcreator-dev on armhf land in binNEW too?
<seb128> dholbach, qtcreator-dev is arch all, it's only going to build on i386
<dholbach> ah, awesome
<seb128> dholbach, which is why I NEWed it before the armhf build was done
 * dholbach hugs seb128
<dholbach> magnifique
 * seb128 hugs dholbach back
<Mirv> dholbach: yep, trying the lp:qtcreator-plugin-ubuntu merge request again so that jenkins would accept it
<xnox> happyaron: it's a gsettings key, which you usually override in your settings package. Or something like that.
<happyaron> xnox: I see.
 * Sweetshark is happy we have two-factor auth, so that i have to get a snooped token via text message together with a password, so that I can open a hijacked MITM-SSL-connection. Except that the text message doesnt arrive.
 * Sweetshark waits
<dholbach> seb128, I uploaded qtcreator-plugin-ubuntu and it built - should it move out of proposed now?
<seb128> dholbach, the binary as already existing in the archive so there is no NEW blocking
<seb128> was*
<dholbach> seb128, I just wasn't sure if qtcreator-plugin-ubuntu and qtcreator would move out of proposed because of its dependencies
<Laney> keep an eye on update_excuses
<Laney> I expect the missing ppc build will cause a problem though
<Laney> Hmm, but it's all -> any
<seb128> dholbach, Laney:
<seb128> out of date on i386: qtcreator-plugin-ubuntu-common, qtcreator-plugin-ubuntu-cordova-common (from 0.1-0ubuntu3)
<seb128> out of date on armhf: qtcreator-plugin-ubuntu-common, qtcreator-plugin-ubuntu-cordova-common (from 0.1-0ubuntu3)
<seb128> out of date on powerpc: qtcreator-plugin-ubuntu-common, qtcreator-plugin-ubuntu-cordova-common (from 0.1-0ubuntu3)
<seb128> should that binary be removed from the archive?
<dholbach> Mirv, ^
<stgraber> no, it just means that last time britney ran the new packages weren't published yet to proposed
<Laney> It's still built
<stgraber> I'd expect the i386 and armhf entries to disappear in the next run
<Laney> wait for the next run when they will be published
<stgraber> then you'll only be stuck because of missing powerpc
<Laney> I'm not sure what will happen with ppc, we'll see
<seb128> ok
<stgraber> Laney: I remember we used to ignore those but I'm not sure whether that was reverted or not
<Mirv> dholbach: looks good to me now, just upgraded all the qtcreator* from proposed
<Laney> stgraber: looks like it worked
<ev> xnox: what's the state of the emulator? Is that something you're still working on?
<xnox> ev: yes. but not usable yet.
<xnox> ev: what are you after?
<ev> a working emulator for autopilot testing
<ev> xnox: any rough estimates on how far away it is?
<xnox> not sure, no.
<xnox> ev: you should be able to run autopilot/qml apps on the desktop... no?
<ev> xnox: I *suspect* this testing is done on the phone because it needs to make phone calls and that sort of thing
<ev> though I guess an emulator wouldn't entirely help there :)
<xnox> ev: not sure emulator would be able to make phone calls.
<ev> it was just an example. Use of the camera would be another, which I believe you mentioned the emulator does support?
<xnox> sim card status is exposed and one sees "3G internet" which is just bridged to the host machines internet.
<xnox> yeah, camera should be possible. we'll still want testing on the devices though. As they seem to randomly regress =/
 * ev nods
<seb128> does anyone know a way to put a pbuilder env "offline" easily?
<seb128> trying to reproduce a test issue than might happen only when internet is not available, but I don't want to go offline while those stuff are running
<seb128> (if not I guess I'm just going to run that at my eod when I don't need the computer anymore)
<cjwatson> I don't have a recipe but it ought to be possible with lxc-clone -s NETWORK (or even just unshare -n) and then setting up networking that just lets you talk to the relevant mirror(s) and nothing else
<cjwatson> would be nice to have that as a canned script to make it easier to reproduce bugs
<seb128> cjwatson, ok, thanks for the suggestion (and indded, that would be nice)
<seb128> stgraber, hey, upstart question for you ... how is the env (the one you get from "initctl list-env") populated?
<seb128> stgraber, trying to figure out  why XDG_CURRENT_DESKTOP is not in there, it's supposed to be set by lightdm since http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/revision/1753
<cjwatson> or maybe arkose can do this
<cjwatson> some variant of arkose -n filtered?
<stgraber> seb128: anything that's in the environment by the time upstart is spawned gets int there
<seb128> stgraber, hum, I wonder if that lightdm commit is buggy then
<stgraber> seb128: so anything that's set by the time Xsession is done running all the hooks
<stgraber> seb128: you could try patching /etc/X11/Xsession.d/99x11-common_start to call "env > /tmp/debug" to confirm, but that should match upstart's environment
<seb128> stgraber, indeed, it's not in the env at this point of time
<sdgsdgsdgsdgdsgs> is anyone working on sni-qt any more? or will that even be a problem when unity is rewritten?
<seb128> mterry, hey!
<seb128> mterry, quick lightdm question for you
<seb128> mterry, bug #1212408 ... at what time of login is that variable supposed to be set?
<ubottu> bug 1212408 in lightdm (Ubuntu) "lightdm/gdm needs to set $XDG_CURRENT_DESKTOP" [Medium,Fix released] https://launchpad.net/bugs/1212408
<mterry> seb128, before launching the session
<seb128> mterry, /etc/X11/Xsession.d/99x11-common_start doesn't have it
<seb128> mterry, which means upstart user session (initctl get-env) doesn't has it
<seb128> mterry, I tried adding a env > /tmp/debug in there and starting an ubuntu session, it's not defined
<mterry> seb128, the lightdm session file has X-LightDM-DesktopName?
<seb128> mterry, $ grep X-LightDM-DesktopName /usr/share/xsessions/ubuntu.desktop
<seb128> X-LightDM-DesktopName=Unity
<seb128> mterry, that's current saucy
<seb128> mterry, is "initctl get-env" listing XDG_CURRENT_DESKTOP for you?
<mterry> initctl: No such variable: XDG_CURRENT_DESKTOP
<seb128> :/
<seb128> mterry, should I reopen the lightdm bug or open a new one?
<mterry> am looking at lightdm code, hold on
<seb128> mterry, thanks
<ScottK> mitya57: Any idea when we'll be ready to land Qt 5.1.1?
<mterry> seb128, we set the variables using pam_setenv during login
<mterry> seb128, does user's session init wipe variables?
<seb128> mterry, what is weird is that other variables like GDMSESSION are set
<mterry> seb128, oh interesting...
<seb128> mterry, no, it doesn't
<mterry> I didn't check that yet
<seb128> mterry, and as said an "env > /tmp/debug" in /etc/X11/Xsession.d/99x11-common_start doesn't list it
<seb128> mterry, http://paste.ubuntu.com/6070819/
<seb128> mterry, it has stuff like XDG_VTNR that comes from lightdm I think
<seb128> no GDMSESSION in that env call though, weird
<seb128> initctl get-env GDMSESSION works
<mterry> seb128, sure, file a bug with lightdm
<seb128> mterry, ok, and thanks for taking the time to have a look ;-)
<mterry> seb128, np.  Code looks right in lightdm, but sure seems like the problem lies there
<smoser> does this mke any sense to anyone
<smoser> https://bugs.launchpad.net/bugs/1220918
<ubottu> Launchpad bug 1220918 in linux (Ubuntu) "networking does not come up in cloud image on hyper-v" [High,Incomplete]
<smoser> jdstrand, or mdeslaur maybe (app armor related). why would dhclient fail like that ?
<seb128> mterry, https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1221803
<ubottu> Launchpad bug 1221803 in lightdm (Ubuntu) "XDG_CURRENT_DESKTOP not correctly set?" [High,New]
<mdeslaur> smoser: how is the network interface started? with the usual stuff in /etc/networking?
<mdeslaur> uh, /etc/network
<smoser> mdeslaur, yes.
<smoser> it doesn't make any sense to me. this is just a cloud image as far as i understand it.
<mitya57> ScottK: I think blockers are listed at https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qt5.1
<bdmurray> sarnold: can you elaborate on the trouble you had when looking at bug 1171418?
<ubottu> bug 1171418 in maas (Ubuntu Quantal) "MAAS fails to power up machines when trying to install nodes" [High,New] https://launchpad.net/bugs/1171418
<mdeslaur> jdstrand: have you ever seen dhclient require cap_admin? see smoser's bug 1220918...
<ubottu> bug 1220918 in linux (Ubuntu) "networking does not come up in cloud image on hyper-v" [High,Incomplete] https://launchpad.net/bugs/1220918
<mdeslaur> jdstrand: sorry, I meant net_admin
<jdstrand> mdeslaur: no I haven't. upstream seems to have made a number of changes recently that are causing new denials
<ScottK> mitya57: Of those, #1215414 is fixed in Debian and while I don't like the fact that #1157213 isn't done yet, I don't see it as a blocker.  #1214374  also seems sufficiently resolved to move forward.   #1217338  seems like low enough priority not to block.  That leaves only #1217702.  I'm worried the longer we wait, the more likely we'll end up with surprises that are hard to fix in the time available.
<ScottK> I'd suggest going ahead.
<mdeslaur> jdstrand: any objection to me adding net_admin to the dhcp profile?
<mitya57> ScottK: I share your opinion, but it would be better to say that to Mirv or seb128.
<ScottK> OK.  We'll see what they say.
<seb128> ScottK, mitya57: say about what?
<ScottK> seb128: See a few lines up about proceeding with Qt 5.1.1.
<mitya57> seb128: (I'm assuming you'll be sponsoring that again)
<seb128> lool, asac, pmcgowan: ^ do you know if we are happy with Qt 5.1.1 enough to land it (e.g did we validate it doesn't create issues on the touch image)?
<pmcgowan> seb128, no not yet
<pmcgowan> seb128, there is a test and fix plan
<seb128> ScottK, mitya57: from that list it seems like that the OSK bug should be resolved before upload, not sure then if the touch guys validated the update enough to process with it
<lool> seb128: I know nothing about it
<ScottK> Do we have a schedule?
<seb128> pmcgowan, any eta?
<seb128> pmcgowan, ScottK and mitya57 are concerned it's getting late in the cycle
<pmcgowan> today we have an image that will go through full smoke testing
<pmcgowan> thre are a known set of issues being worked with tag qt5.1
<asac> seb128: i cant cope with qt 5.1.1 today
<ScottK> pmcgowan: Right, I just looked at the list and of those, #1217702 seems like the only one that has the potential to be a real blocker.
<seb128> pmcgowan, right, https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qt5.1 ... that was just discussed
<asac> pmcgowan: do you send the image through our automation? or manual smoke testing?
<asac> i assume manual
<seb128> asac, next week?
<pmcgowan> asac, its happening today
<pmcgowan> fginther and plars are managing that
<pmcgowan> timo and rsalveti have done manual testing
<asac> pmcgowan: the testing is happening today?
<pmcgowan> yes
<asac> ok
<asac> pmcgowan: but you dont plan to push this in today, do you :)?
<pmcgowan> no
<rsalveti> ideally we would move to qt5.1 already next week
<asac> ok
<asac> yeanh
<rsalveti> but we're currently testing to make sure we have all the bugs in place
<asac> i am happy to take that after we have unity/mir landed
<asac> right after
<pmcgowan> ScottK, and seb128 yes plan is to try next week
<asac> or before if that is further delayed
<rsalveti> would next week be fine?
<ScottK> Next week is fine.
<ScottK> I'm just worried if it gets delayed too long.
<pmcgowan> we share the concern
<rsalveti> great
<jdstrand> mdeslaur: seems like it is busted without it. it would be nice to know what it is trying to do, but reading the capabilities man page, I'm kinda surprised it hasn't needed it in the past
<jdstrand> Perform various network-related operations: * interface configuration;
<jdstrand> uh, that is clearly within dhclient's bailiwick I would think :)
<pitti> remove-package -m 'deprecated years ago, broken in saucy, no remaining reverse depends, LP #1221254' hal
<ubottu> Launchpad bug 1221254 in xbmc (Debian) "kill hal for good!" [Unknown,New] https://launchpad.net/bugs/1221254
<pitti> WHAT A DAY!
<Laney> !!!
<pitti> and it only took us like 5 years
 * ogra_ hugs pitti 
<ogra_> congrats !!!
<mdeslaur> pitti: congrats! \o/
<Peace-> anyone here ? i have a problem i was reporting a bug , a guy asked me to upgrade the kernel so i downloaded and installed sucessfully the kernel , but i have seen possibile missing firmware radeon
<Peace-> so i have rebooted after i did sudo update-grub2
<Peace-> and it doesn't show the new kernel
<Peace-> btw sudo update-grub2 says that has detected 3-11 kernel
 * pitti hugs back ogra ;)
<mdeslaur> smoser: I just uploaded a new dhcp package to saucy, let me know if that solves it
<smoser> mdeslaur, i would have thought the world would hav failed if dhclient was busted.
<mdeslaur> smoser: me too :) I'm not quite sure why it's busted in that particular scenario, perhaps because it's not NM setting up the interface
<smoser> well, that image runs elsewhere fine.
 * mdeslaur shrugs
<sarnold> bdmurray: I believe the maas team took comment number 8 in bug 1171418 as indication that they had finished the SRU verification tasks needed for that bug -- yes, comment number nine spells out clearly that it wasn't done for precise, but comment number eight could have been more explicit about that
<ubottu> bug 1171418 in maas (Ubuntu Quantal) "MAAS fails to power up machines when trying to install nodes" [High,New] https://launchpad.net/bugs/1171418
<bdmurray> sarnold: at the point in time comment #8 was made there was no more verification required because they had only uploaded a fix to one release, so techincally the verification was all done, although more work was required.
<mdeslaur> bdmurray, barry: can someone verify/mark as verified bug 1058884 please, so I can eventually publish some security updates?
<ubottu> bug 1058884 in python3.3 (Ubuntu Raring) "Race condition in py_compile corrupts pyc files" [High,Fix committed] https://launchpad.net/bugs/1058884
<barry> mdeslaur: won't be me today.  too busy
<mdeslaur> barry: wait, canonical isn't making you work weekends?
<mdeslaur> hrm
<mdeslaur> :)
<barry> mdeslaur: i'll slot it in from 3am-4am tonight, for sure! <wink>
<bdmurray> slangasek: we were talking about the verification of bug 1058884 the other day
<ubottu> bug 1058884 in python3.3 (Ubuntu Raring) "Race condition in py_compile corrupts pyc files" [High,Fix committed] https://launchpad.net/bugs/1058884
<barry> (which still technically isn't "me today" :)
<mdeslaur> barry: hehe :)
<sarnold> bdmurray: Sure, the information is there in the bug report to figure out what happened and why it made sense :) I just know that I've been confused several times in the past and needed to put in the time to discover the steps that were taken. I'd like there to be less time spent figuring things out. :)
<slangasek> bdmurray: 1058884> yes... did you have much luck gathering data from errors on this?
<bdmurray> slangasek: its a bit challenging without the database access but in comment #32 I talk about how I didn't find any instances of EOF crashes with packages from -proposed
<bdmurray> I'm looking into where package install failures end up
<bdmurray> I just sent one to errors but haven't been able to find it yet
<slangasek> hmm, ok
<slangasek> bdmurray: so it sounds like there's pressure to get a security update out; how long do you think it will take to get the answers you need out of errors?
<slangasek> three basic options: 1) delay the security update until we know, 2) let the security update jump the queue, 3) push the SRU through with the risk that it'll have to be rolled back due to regressions (and the security update as well)
<bdmurray> slangasek: looking for package install failures was because of bug 1198439 and that is the harder thing to query for right now. I'm satisified with the work I did looking for other EOF errors and the new version.
<ubottu> bug 1198439 in python2.7 (Ubuntu) "package python2.7-minimal 2.7.4-2ubuntu3.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Incomplete] https://launchpad.net/bugs/1198439
<slangasek> bdmurray: so are you happy to go ahead with publishing?
<slangasek> cjwatson: so with lp:~vorlon/ubuntu/saucy/grub2/uefi-sb-netboot, I've managed to get all the way to a grub menu via shim->grub over netboot... but the grub.cfg is still a bit of a mess, I wonder if you can tell me what I'm doing wrong there
<Hammerhead2011-S> can one of you recommend a group that can talk to me about the network scripts in 13.04 my interfaces are coming up but the routes are not being added to my table
<Hammerhead2011-S> this is not a general discussion question, the machines table in question is a VM running on 12.04 in virtualbox
<slangasek> Hammerhead2011-S: you can ask, but that sounds like a support question, not a development question
<Hammerhead2011-S> Thanks, was just hoping that I could get a push in the right direction. was not going to ask here just looking for a group that was NOT going to recommend that I check the "/etc/network/interfaces" file :-)
<slangasek> erm, you're defining your routes somewhere other than /etc/network/interfaces?
<Hammerhead2011-S> going to try upstart, didn't see that one, longshot but we will see.
<Hammerhead2011-S> oh no, they are there, just not being entered into the route table at startup
<Hammerhead2011-S> Seems to be some issue with Virtualbox and Cisco UCS and Ubuntu
<slangasek> well, post-up scripts work fine in Ubuntu via /etc/network/interfaces
<slangasek> if your routes aren't in your table when you look, maybe something else is removing them
<slangasek> bdmurray: lp:~vorlon/ubuntu-release-upgrader/lp.1220898> I'm happy for you to take the machete to a bit more of the code as you merge it :)
<bdmurray> slangasek: maybe not as phased-updates won't help here since the crashes were never filed about python2 or python3 packages themselves
<Hammerhead2011-S> slang any hints as to what would be removing them? My guess is that the are not being entered. Any thoughts on debugging kernel actions? The kernel.log has nothing about any troubles with interfaces or routes.
<slangasek> bdmurray: ok, so how do we get to the point where we're confident to publish?
<slangasek> Hammerhead2011-S: well, you could start something in early boot that uses netlink to monitor changes to the routing table; I don't know of anything offhand that does netlink debugging though
<bdmurray> slangasek: I think waiting for more people to be running saucy and continuing to watch for new instances until October(?) is the more conservative approach
<slangasek> bdmurray: so I'm worried that even in that case, because these are backported patches, it may not be a good measure
<slangasek> there may not be a way to get more info than we already have except for publishing
<slangasek> Hammerhead2011-S: this is almost but not quite what you're looking for. http://bitsup.blogspot.com/2008/04/monitoring-ip-changes-with-netlink.html
<bdmurray> slangasek: well I could whip something up to watch the exisiting buckets in errors for the version that would be in -updates, but what would we do if we found the new version?
<slangasek> bdmurray: to me, that seems less likely than that there's a regression that wouldn't show in that bucket at all
<slangasek> e.g., that tentatively-tagged regression we had
<slangasek> bdmurray: so I think at this point, we should pull the SRUs and let mdeslaur get on with his security update, until we can figure out a better regression testing plan
<MDesigner> hey guys. who can I talk to about donating a new startup sound for Ubuntu 14.10 LTS?
<Noskcaj> MDesigner, 14.04 is the LTS
<MDesigner> sorry, my mistake
<MDesigner> so who do I talk to about contributing a new startup sound?
<Laney> MDesigner: There's a "unity-design" team on Launchpad with a mailing list; that's the best place I can think of ATM
<Laney> and thanks for offering your time/skills
<MDesigner> you bet!
<MDesigner> happy to contribute somehow. I love Ubuntu. :)
#ubuntu-devel 2013-09-07
<slangasek> bregma: so I see there's a libgrip package in the raring-proposed queue that's been synced from https://launchpad.net/~ubuntu-unity/+archive/sru-staging ... our SRU process is not equipped to handle such things.  Do you have someone who can do a sourceful upload instead of a sync?
<bregma> slangasek, I can take care of that
<bregma> that change must have been languishing for the last 4 months, i never noticed
<sergiusens> slangasek: xnox with a move to cross compilation, that means we are most likely going to move dh_auto_test unit tests to autopackage tests?
<smartboyhw> Laney, you don't mind me updating Rhythmbox to 3.0?
 * smartboyhw will file a FFe for this;)
<jbicha> smartboyhw: see bug 1220972 and https://bugzilla.gnome.org/707527
<ubottu> Gnome bug 707527 in Plugins (other) "zeitgeist: More python3 porting" [Normal,Unconfirmed]
<ubottu> bug 1220972 in rhythmbox (Ubuntu) "Upgrade rhythmbox to 3.0" [Wishlist,Confirmed] https://launchpad.net/bugs/1220972
<smartboyhw> ubottu, ooh:)
<smartboyhw> jbicha, ooh
<smartboyhw> jbicha, so, it's impossible to touch on it since it wouldn't work?
<jbicha> I wouldn't say that but it needs work to make sure all the python plugins work; that needs to be done eventually anyway
<smartboyhw> jbicha, OK
<jbicha> otherwise backporting fixes from 3.0 to saucy would be helpful
<smartboyhw> jbicha, that will be quite a lot of backporting-.-
<infinity> RAOF: "axserver-xorg-video-ati", you say? :)
<infinity> RAOF: (From the changelog for xserver-xorg-video-ati)
<infinity> RAOF: http://launchpadlibrarian.net/149219505/xserver-xorg-video-ati_1%3A7.2.0-0ubuntu5_1%3A7.2.0-0ubuntu6.diff.gz <-- Looks like you lost an argument with vi. ;)
<Laney> jbicha: did you notice that your blender sync ftbfsed?
<Laney> also owncloud-client but I'm looking into that one
<jbicha> Laney: thanks for looking at owncloud-client since it looked a bit tricky to fix
<Laney> I think it's just arch/indep fail
<jbicha> yes but I wasn't sure the correct way to fix that
<jbicha> for blender, see http://irclogs.ubuntu.com/2013/08/25/%23ubuntu-motu.html and continuing to 08/26
<Laney> mmm
<cjwatson> sergiusens: There's no reason to *move* them, since they're useful for native builds.  You might wish to run them from autopkgtest *as well*
<jbicha> I'm not going to be able to fix blender as I have too much else going on right now
<cjwatson> sergiusens: It'll be a long time before official package builds stop being natively-built, if ever
<cjwatson> sergiusens: As far as I'm aware, current work on cross-building is mainly with the aim of making developer-system iteration easier and quicker
<sergiusens> cjwatson: ack with the debian package building... what about click and CI. Should we aim for xcompile or native?
<cjwatson> sergiusens: well, native comes out in the wash no matter what generally, but we need to aim for making cross-compile work too
<jtaylor> can (ppa) packages depend on backports?  (e.g. via versioned depends)
<cjwatson> That's a lot of chromiums building in parallel.
<cjwatson> Glad I removed the restriction on PPAs :)
#ubuntu-devel 2013-09-08
<Noskcaj> roaksoax, kirkland: Does testdrive stuff warrant a recommendation for MOTU?
<Noskcaj> who else has sponsored stuff for me?
<Noskcaj> cjwatson, mfisch, slangasek: Can i have a comment on my MOTU wiki page? https://wiki.ubuntu.com/Noskcaj#MOTU
<Noskcaj> sorry for all the pings
<slangasek> Noskcaj: have I sponsored uploads of yours?  http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi doesn't show anything
<Noskcaj> slangasek, I thought so. Thanks for the link. i fornot about it
<Noskcaj> *forgot
<slangasek> yeah, I had to dig through wikis to find it :)
<Noskcaj> FYI: It's linked on ubuntuwire
<Noskcaj> so dholbach, micahg, mitya, Riddell and pitti are the ones i need Testimonials from
#ubuntu-devel 2014-09-01
<nvrpunk> Laney: evolution-ews breaks evolution entirely on a fresh install.  It just causes it to hang
<nvrpunk> in utopic
<nvrpunk> I would submit a bug report but the fact it hangs doesn't cause apport to do anything
<pitti> Good morning
<nvrpunk> morning
<dholbach> good morning
<sladen> guten morgen alle
<Saviq> Mirv, do you know if we have a custom backend for QNetworkAccessManager or are we using upstream directly?
<Saviq> Mirv, on another topic, any reason why Qt includes are installed in multiarch dirs?
<Mirv> Saviq: check the network usage with Wellark
<Saviq> Wellark, when around, do you know if we have something custom for backing QNetworkAccessManager, or are we using upstream direct?
<Mirv> Saviq: the includes were migrated to multiarch during 5.3.0 in Debian, and we followed. without that it was not possible to properly multi-arch dev packages (even though we did it anyway earlier)
<Mirv> if you diff between different archs, there are a small handful of differences if I recall correctly
<Saviq> Mirv, well, sure, I'm not saying -dev should be arch: all (they never are are they)
<Saviq> Mirv, just that I've never seen any includes to live in multi-arch dirs
<Saviq> but sure, you know what you're doing of course
<Saviq> was trying to get qmake to x-build over the weekend... that was one thing (qmake using incorrect include dir)
<Saviq> ln helped here, but then qmake couldn't find the qt modules :/
<Saviq> looks like mkspecs are not good enough to support multi-arch x-building yet
<Mirv> Saviq: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734677 has the background. our earlier multiarching came as part of arm64 work, but I knew it broke policies so I didn't try to put that to Debian
<ubottu> Debian bug 734677 in src:qtbase-opensource-src "src:qtbase-opensource-src: qt5 packages aren't multi-arch ready" [Wishlist,Fixed]
<Saviq> Mirv, thanks!
<Mirv> Saviq: yeah, x-build still doesn't seem trivial with Qt (qmake) :(
<Saviq> Mirv, indeed, right now it feels like we'd need cross-qmake- for every arch combination out there, really not good
<Mirv> Saviq: btw feel free to keep https://wiki.ubuntu.com/Touch/CrossCompile maintained nevertheless, especially with examples that would work right now on utopic.
<Mirv> I tried it last week when I was asked about it, and failed with everything I tried (either the chain of deps not multi-arch, or some other failure when compiling eg qtbase or qtdeclarative)
<Saviq> Mirv, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1353855
<ubottu> Launchpad bug 1353855 in unity8 (Ubuntu) "Explicit g++ 4.9 dependency breaks cross-building" [Undecided,New]
<Saviq> Mirv, no one seems to care really
<Mirv> Saviq: yeah I had the same with qtdecl that defined 4.8, but after fixing that and it started building, it failed very early anyhow
<Saviq> Mirv, what build system?
<Saviq> Mirv, with cmake and no 4.9 dep stuff's x-building fine for me?
<Saviq> Mirv, also that page seems to duplicate a lot of https://wiki.ubuntu.com/SimpleSbuild
<Mirv> Saviq: qtdeclarative, so qmake. I tried also camera-app (cmake) but that apparently had problematic dependencies.
<Saviq> Mirv, so yeah, qmake is just a no-no
<Saviq> Mirv, anything cmake (without an explicit 4.9 dep) should work
 * Saviq tries camera-app
<Mirv> Saviq: that /Touch/ page must be better since you're mentioned there :) but so it seems, I'll do some interlinking at least
<Saviq> Mirv, I ~wrote the SimpleSbuild one though :D
<Mirv> oh, that's a hard choice then :)
<Saviq> Mirv, camera-app seems to x-build just fine here, the only big problem I know of is the 4.9 dep, otherwise anything cmake should build
<Saviq> aaah wait
<Saviq> --host=armhf helps to actually x-build...
<Saviq> Mirv, camera-app's just missing :any for the python3 build-dep
<Saviq> or :native, but that's not supported everywhere yet
<Saviq> some other packaging tweaks needed apparently
<Saviq> ah, it's querying qmake...
<shadeslayer_> is anyone able to access Jenkins via the public interface?
<Mirv> Saviq: yes, I added the :any there, I think after that I didn't figure out the next step. would there be some other easier example package?
<Saviq> Mirv, it's querying qmake for QT_INSTALL_QML
<Saviq> Mirv, which can't work for x-building
<Saviq> simple fix, will have a branch in a mo
<Saviq> Mirv, https://code.launchpad.net/~saviq/camera-app/x-build/+merge/232878
<Mirv> Saviq: thanks, I'll try that
<Saviq> Mirv, there's more changes than necessary (the move from qt5/qml to camera-app, could very well use the original one, but it didn't make sense)
<Mirv> Saviq: nice to have a working example, now I can leave that sbuild config around and use every now and then
<Saviq> Mirv, cool
<pete-woods> I've just done a dist-upgrade on my utopic install, and I no-longer get to the lightdm login screen
<pete-woods> I just get to a TTY with errors very similar to the following: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756247
<ubottu> Debian bug 756247 in systemd-shim "Failed to start unit user@1000.service: Unknown unit: user@1000.service" [Normal,Open]
<pete-woods> (they are perhaps unrelated, as I don't usually check the terminal output on boot)
<pete-woods> Failed to start unit user@1000.service: Unknown unit: user@1000.service
<pete-woods> is pretty much the error
<shadeslayer_> dholbach: ping
<dholbach> shadeslayer_, pong
<shadeslayer_> dholbach: did anything happen wrt the Canonical legal thing wrt derivatives and stuff
<shadeslayer_> I haven't heard back about that in ages
<dholbach> shadeslayer_, is this about the changes discussed with the SFLC?
<pitti> smoser`: hey Scott, how are you?
<pitti> smoser`: so we tracked down a complete juju-local failure through an LXC template problem down to https://cloud-images.ubuntu.com/query/trusty/server/released-dl.current.txt not having a certificate that wget accepts
<pitti> smoser`: any idea about that?
<pitti> smoser`: for bug https://cloud-images.ubuntu.com/query/trusty/server/released-dl.current.txt
<pitti> erk; for bug 1363832
<ubottu> bug 1363832 in juju-core (Ubuntu) "[utopic] fails to build template container -- ubuntu-cloudimg-query fails" [Undecided,New] https://launchpad.net/bugs/1363832
<shadeslayer_> dholbach: yes
<pitti> smoser`: wgetting that works in trusty, but fails in utopic, apparently it got stricter?
<dholbach> shadeslayer_, thanks for the ping - I'll send a mail out to legal again and let you know as soon as I hear back
<shadeslayer_> dholbach: cheers
<dholbach> shadeslayer_, mail sent
<shadeslayer_> Thx
<pitti> smoser`: ok, followed up again with some more info
<shadeslayer_> does Canonical run a relay SMTP server for ubuntu btw?I wanted to write some scripts that sends out emails, and was wondering if there was a server I could utilize
<flexiondotorg> I've got a teeny tiny (but of real importance to me) merge proposal pending. Could someone take a look at it please? https://code.launchpad.net/~ubuntu-mate-dev/ubuntu/utopic/policykit-desktop-privileges/mate-fixes/+merge/230610
<flexiondotorg> Here is the corresponding bug report - https://code.launchpad.net/~ubuntu-mate-dev/ubuntu/utopic/policykit-desktop-privileges/mate-fixes/+merge/230610
<mitya57> flexiondotorg: I don't have rights to upload that, but why are you not using the Freedesktop standard interface for datetime?
<infinity> shadeslayer_: We only run an SMTP relay for Canonical employees (well, for people with accounts on our network, which is basically the same set), nothing wide open for Ubuntu.
<shadeslayer_> infinity: okie
<infinity> shadeslayer_: I suppose a starttls-authed relay that authenticated aainst SSO and only allowed ubuntu.com users to use it might not be a bad idea, but I'm not sure if it's ever been suggested an rejected, or just not really thought about at all.
<flexiondotorg> mitya57, I am using what is define by the MATE desktop.
<shadeslayer_> infinity: I see, do you reckon it would be a good idea to suggest it? I wanted to write scripts to email patch authors to add dep3 headers to their patches
<infinity> shadeslayer_: (More traditional in our old skool "we want to pretend the internet isn't changing" UNIX admin world to just send mail from our own servers, so perhaps none of us really thought of the need. :P)
<shadeslayer_> and I'd rather not run my own smtp server
<shadeslayer_> infinity: hehe
<mitya57> flexiondotorg: they should really adopt to 2014 realities ;)
<infinity> shadeslayer_: Couldn't hurt to file an RT on rt.ubuntu.com and ask if it's feasible and something Canonical IS would be willing to cobble together.
<shadeslayer_> ack
<infinity> shadeslayer_: The worst you can get is a "no", which is no worse than today.
<shadeslayer_> yeah
<flexiondotorg> mitya57, Well, that is happening. I'll raise that upstream but this is how is in MATE 1.8. I'll progress the change for MATE 1.10.
<saiarcot895> Hi all, is there any place to float a proposal to change a package? I'm considering making a change to the qt4-x11 package.
<ogra_> file a bug on launchpad and attach a patch
<ogra_> then developers can take a look
<saiarcot895> thanks, ogra_
<ScottK> saiarcot895: Also it should be discussed upstream unless it's just a change to the packaging.
<saiarcot895> ScottK: that might be a good idea, considering I'm planning a change to a typedef used in OpenGL ES cases
<ScottK> Definitely.
<apachelogger> stgraber: do you know of any issues with lxc-start-ephemeral and unprivileged containers? in particular the container seems to fail to start because of permission problems
<apachelogger> stgraber: http://paste.ubuntu.com/8208189/
<saiarcot895> If a package was present in precise and utopic but not in trusty, and the package was backported to trusty, would it still go in the trusty-backports section or the trusty section?
<mlankhorst> yes
<hallyn> wgrant: say, your t440s, does it have the 45W slim charging brick, or the 65W brick?
<hallyn> i'm wondering whether the 65W one is overpowring my mobo (once in awhile it shuts off when i plug it in, and won't turn back on for awhile)
<TJ-> hallyn: PSUs won't supply more power than the circuit draws; As long as the wattage of the PSU is sufficient for the maximum current draw of the system, any excess ability probably means the PSU will last longer since it doesn't operate so close to its maximum rating
<hallyn> TJ-: hm.  that's too bad.
<hallyn> i'd rather replace the brick than send the laptop in
<TJ-> hallyn: Does the power plug have a central 'data' pin?
<hallyn> it has a central pin
<TJ-> If it is anything like some infamous Dells, sometimes the very thin data wire in the power cable gets broken by repeated flexing. When that happens the PC can't get the power rating from the PSU. On some systems, that is enough for the firmware to decide to shutdown the PC entirely
<TJ-> hallyn: On the Dells, the more common issue was the power socket on the PC would flex slightly as the power connector was pushed home. Over time that caused a broken track on the PCB which broken the data link too... required a new power socket PCB or clever soldering :)
<hallyn> the first time it happened there was a smell of burning wire coming from near the 6cell batt, and it wouldn't start until the nxt morning
<hallyn> basically the more i let the batteries discharge the more likely it is to get finicky.
<TJ-> hallyn: That doesn't sound good! Replace the battery, it sounds like a cell has overheated
<hallyn> (it's only a few weeks old)
<hallyn> the battery wasn't what smelled, though,
<hallyn> hm, i forget which side it was on though
<hallyn> and i don't know offhand where the 3cell is
<hallyn> stil yeah, maybe it's the 6cell, as the last two times it started up fine whe ni pulled it out.
<hallyn> i'll have to experiment some more
<TJ-> hallyn: You've certainly got a relatively serious power issue there. Will the system start without a battery attached?
<hallyn> dunno - the 3 cell isn't (meant to be :) removable
<TJ-> if the charge controller detects problems it'll refuse to power the system, for safety
<Unit193> There's been an NMU for http://bugs.debian.org/759528, can that be sync'd?
<ubottu> Debian bug 759528 in autoconf-archive "autoconf-archive: fails to install with dpkg (>= 1.17.13)" [Serious,Fixed]
<hallyn> desrt|pdx: (if you're around) so systemd-shim currently listens to org.freedesktop.systemd1.Manager.  To make it listen to org.freedesktop.systemd1.Scope do I need to use a subtree, or is there a simpler way?
<hallyn> or is it supposed to be safe to call g_dbus_connection_register_object twice
#ubuntu-devel 2014-09-02
<wgrant> hallyn: I normally use the 45W one, but I sometimes use my old bigger T400 one without trouble.
<hallyn> wgrant: you've never had this charging trouble I'm talking about i take it?
<hallyn> I really don't wanna be laptop-less for 2 weeks as i send this one in... :(
<wgrant> hallyn: Nope :/
<wgrant> hallyn: Will it turn back on immediately if you unplug the external battery and disable the internal one, then replug?
<hallyn> how do i disable the internal one?
<hallyn> but, the last two times it did after i unplugged the external, but the first time it did not
<hallyn> so, want a few more experiments i guess
<wgrant> hallyn: There's a button on the bottom.
<hallyn> (the first time i was just really pissed off)
<hallyn> oh?
<wgrant> IIRC
<wgrant> Hm, I thought there was.
<wgrant> Oh, maybe it's not externally accessible, damn.
<wgrant> I was remembering the internal one.
<wgrant> But yeah, I've never had a problem like that.
<wgrant> The biggest issue I have is that it doesn't detect a hot-swapped external battery without a suspend/resume or unplug/replug cycle, and I think that's a Linux issue.
<hallyn> ok - thx
<desrt|pdx> hallyn: you can't do subtree listens for bus names -- you have to register each one separately
<hallyn> desrt|pdx: hm, did try that, didn't seem to get interface org.freedesktop.Scope method Abandon to register, but I'll keep going down that route then, thanks
<desrt|pdx> oh
<desrt|pdx> if you want new _interfaces_ then you need to make a new call to register_object
<desrt|pdx> and ya -- in that case, subtree may make sense depending on what you're up to
<hallyn> systemd-logind calls method Abandon on interface Scope to let us know we can remove the cgroup.  i just wanna listen to that so we can act on it
<desrt|pdx> you'll probably need to use a subtree
<desrt|pdx> because of the stateless thing
<hallyn> ok.  actually i guess i just got that to actually create me some cgroups.
<pitti> Good morning
<dholbach> good morning
<dholbach> seb128, does the desktop team still use the ~ubuntu-desktop branches?
<seb128> dholbach, yes, why?
<dholbach> seb128, ok, it was just a few I found of date
<seb128> of date?
<dholbach> out of date
<dholbach> sorry
<seb128> which ones?
<seb128> things is that some packages don't always have an Ubuntu delta, and we don't commit updates when packages got e.g back in sync with Debian
<dholbach> ah ok
<LocutusOfBorg1> Hi, what is needed to fix lp 1310049?
<ubottu> Launchpad bug 1310049 in lsdvd (Ubuntu) "Invalid Python Output in Trusty" [Undecided,Confirmed] https://launchpad.net/bugs/1310049
<LocutusOfBorg1> the patch is already there
<seb128> LocutusOfBorg1, subscribe ubuntu-sponsors to the bug?
<LocutusOfBorg1> yes, seb128 I had already done this, a few minutes ago, I was looking for the SRU documentation
<seb128> LocutusOfBorg1, https://wiki.ubuntu.com/StableReleaseUpdates
<LocutusOfBorg1> yes seb128  was looking at it ;)
<seb128> LocutusOfBorg1, looking at what?
<seb128> oh, the SRU documentation, I though you were asking for it
<mvo_> mardy: hi, just a quick heads-up, I uploaded a new accounts-qml-module with a trivial multi-arch releated change, the control file says direct uploads are ok, but if you prefer a branch instead just say so and I will create one
<xnox> desrt|pdx: hey, you are not totally hooked up for non-uploading DD status =) https://nm.debian.org/public/process/desrt
<xnox> I'm sure seb128 would be very happy about that =)
<seb128> desrt|pdx is going for dd?! ;-)
<xnox> seb128: yeap! non-uploading though =)
<xnox> seb128: although we might trick him into an uploading DD later on.
<seb128> is the process less crazy than for DD with upload? ;-)
<xnox> seb128: it's less crazy - one must pass the secret handshake test, licensing test, etc. But not e.g. how to use dput test.
<seb128> k
<seb128> no "rewrite your debian/rules in pure makefile without using the dh tools"? ;-)
<mlankhorst> hah
<mlankhorst> well DD is easy. :P
<mlankhorst> even uploading
<tjaalton> just takes time
<mardy> mvo_: if you create a branch, you would save me some time -- if you do have time yourself, that is :-)
<sil2100> dholbach: hey! I have a small request - could you move my this-month's patch pilot duty one week later? :)
<sil2100> dholbach: and if you want, you can put my name 2 times in the month if anything
<stgraber> apachelogger: is that on utopic?
<tseliot> pitti: hey, do you know why/how requesting suspend from logind could result in a timeout?
<tseliot> pitti: in 14.04
<apachelogger> stgraber: trusty
<stgraber> odd. I'm aware of some kernel issues with unprivileged overlayfs on utopic but not on trusty...
<stgraber> apachelogger: is that just a straight unprivileged lxc-start-ephemeral or are you doing nesting?
<apachelogger> stgraber: straight one, on AWS if that matters
<stgraber> apachelogger: ok, just to confirm it's a generic issue and nothing to do with your jenkins setup or its directories, can you try a simple (still unprivileged): lxc-create -t download -n test -- -d ubuntu -r trusty -a amd64 && lxc-start-ephemeral -o test
<mvo_> mardy: thanks,  I will make sure to create a branch for you
<apachelogger> stgraber: http://paste.ubuntu.com/8214763/
<apachelogger> stgraber: ah mind you, the container is utopic
<apachelogger> pft
<apachelogger> stgraber: I can't reproduce it anymore :S
<apachelogger> ah, actually
<apachelogger> stgraber: I since changed the entire home to the first subuid as I found no other way to make rw bind mounts work, so I guess that would have solved the permission problems
<apachelogger> stgraber: fails for new user http://paste.ubuntu.com/8214821/
<stgraber> apachelogger: does a simple "lxc-start -n test" work for that new user?
<apachelogger> stgraber: yep http://paste.ubuntu.com/8214858/
<pitti> tseliot: could be bug 1253456 or bug 1252121, I just never could reproduce it on a box that I could debug on
<ubottu> bug 1253456 in systemd-shim (Ubuntu) "Suspend takes >20 seconds" [Undecided,New] https://launchpad.net/bugs/1253456
<ubottu> bug 1252121 in systemd-shim (Ubuntu Trusty) "missing PrepareForSleep signal after resuming, causing networking to stay disabled" [High,Confirmed] https://launchpad.net/bugs/1252121
<tseliot> pitti: I can't reproduce it here either but an engineer can here: https://bugs.launchpad.net/fwts/+bug/1360195
<ubottu> Launchpad bug 1360195 in Firmware Test Suite "Can not finish suspend test" [Critical,New]
<tseliot> I don't know if it's the same issue though
<stgraber> apachelogger: hmm, sadly I'm in the middle of a move and my trusty dev box isn't quite back online yet...
<stgraber> it's a bit puzzling why it works for one user and not for the other though
<mvo_> xnox: could you please try http://paste.ubuntu.com/8215080/
<mvo_> xnox: ?
<mvo_> xnox: you can test using ./build/bin/apt-helper detect-proxy http://foo.bar
<apachelogger> stgraber: it works on the one user because I manually cheated my way to a working setup by changing the uid entirely -> http://paste.ubuntu.com/8215121/
<dholbach> sil2100, you can move it wherever you like
<dholbach> sil2100, it's just there as a reminder
<mlankhorst> stgraber: can someone from the release team ack mesa 10.3 or xorg-server 1.16?
<aerocarbine> join #teen
<apachelogger> stgraber: I am not sure how this is intended to work but from what I understand the ephemeral setup fails because it tries to create a folder (delta0) in a folder that is not owned by the mapped uid... e.g. in the jenkins example share/local/lxc/foo would be owned by uid=120 but the map only starts at 100000 which results in permission errors. I also observed the same thing with a snapshot clone and a bind mount (which is why I flipped the
<apachelogger> uid of the jenkins user), as long as the to-be-bound-dir doesn't have write permissions for uid100000 it quite simply won't be writable
<apachelogger> I do find that last bit weird though considering 100000 is a subuid of whatever uid the user has xD
<stgraber> apachelogger: ah, you shouldn't be needing that kind of trick at all, what you do need however is execute access for the mapped uid all the way to .local/share/lxc
<stgraber> apachelogger: which typically is as simple as "chmod +x /home/<user>"
<apachelogger> stgraber: mhh, I did the chmod on both accounts though :/
<stgraber> apachelogger: let me see if I can figure out how to start a canonistack instance so I can do a very quick test there
<pitti> wgrant: oh, a langpack! https://translations.launchpad.net/ubuntu-rtm/14.09/+language-packs
<pitti> wgrant: was this an one-off thing, or is that cron'ed now?
<wgrant> pitti: Oh, sorry, forgot to poke you about that. We should coordinate the cron schedule.
<wgrant> The import backlog completed over the weekend.
<pitti> wow, still 199 MB? I had expected it to be a lot smaller
<wgrant> It might make sense to disable langpack support for some of the templates.
<wgrant> I haven't looked to see where the major size is.
<pitti> wgrant: so, incidentally I just fixed langpack-o-matic to now fully get along with update tarballs (we need that for ubuntu anyway)
<pitti> so the requirement for "always need a full export" can be dropped
<wgrant> All templates for sources that we copied were copied.
<stgraber> apachelogger: got a trusty instance up, though it's freakishly slow, trying to get lxc running in there now :)
<pitti> wgrant: so from my side I'm not fussed about any particular time in teh week
<pitti> wgrant: so you can run it at the time that is best
<wgrant> pitti: Thursday for the export?
<pitti> wgrant: sounds good! then Friday for the build/upload
<wgrant> Yep
<smoser> adam_g`, i do have access to such logs.
<israel> Hi, I am wondering how to access files outside of a squashfs... I am building a Live CD without ubiquity.  Is there a way to link to files in the /live directory of the actual image to link to the LiveCD $HOME?
<israel> in Debian it is ln -s /lib/live/mount/medium/live/ but this directory structure does not exist in the image I am building... what is the equivalent?
<xnox> mvo_: building
<shadeslayer> israel: how are you building the ISO?
<israel> shadeslayer I made a script... I am using chroot, basically I followed https://help.ubuntu.com/community/LiveCDCustomizationFromScratch
<israel> But I am customizing it using an alternate installer called OBI, rather than Ubiquity as I am targetting machines with 128MB RAM using JWM and no display manager... just xinit in $HOME
<shadeslayer> uh, not entirely sure
<shadeslayer> israel: why do you want to do this linking btw?
<israel> I have a working image, however I need to access a tar.xz stored in image/live/tarballs
<Saviq> sergiusens, do you have a bug for ciborioum and system hint?
<israel> :) I was answering as you typed
<shadeslayer> israel: doesn't answer my question :)
<shadeslayer> why do you need to access a tar on the binary ISO
<shadeslayer> instead of having the tar inside the squashfs
<israel> OBI uses the tar to install an entire OS.  It is a tarball of an existing system
<israel> the entire device
<xnox> mvo_: git diff output doesn't tell me base commit id nor branch the diff is against =) hence, i was asking for "git format-patch" as that has metadata for me to find out what the diff is for. As is that fails to compile, failing to find proxy.h headers. Let me fudge it in to compile.
<xnox> and/or undo refactoring.
<shadeslayer> wait so
<israel> https://help.ubuntu.com/community/OBI
<shadeslayer> israel: your ISO will have squashfs of the system as well as a tar of the entire system
<shadeslayer> so basically doubling the size?
<israel> yes... but the image is around 600MB total with the tar
<mvo_> xnox: hm, give me some minutes, I shall have something with a proper git format and test then
<israel> shadeslayer is there a way to copy the squashfs to the HD as the OS? and run some post install scripts to change a few things? (like user and moving /root to /home/$USER
<shadeslayer> israel: well, the media will be mounted in /media/user/something/ , so mayeb you can patch OBI to look at that path?
<shadeslayer> israel: ubiquity :p
<israel> Ubiquity does not run in less than 384 MB  it locks the computer up... hence the need for OBI
<dholbach> didrocks, your blog is a bit busy, right? :)
<didrocks> dholbach: it seems it went popular, I'm rebooting it in a few :p
<shadeslayer> israel: right
 * shadeslayer would just use the text installer
<israel> hmmm... OBI is a one button installer... it is very easy for a novice... text installer is much more complicated than ubiquity, don't you think?
<shadeslayer> but ... who would have computers with 128 MB's of RAM :S
<shadeslayer> seems like a corner case
<xnox> mvo_: hm, also local build system seems to link against system libapt-pkg (and headers) instead of the just built ones....
<didrocks> dholbach: up again
<israel> shadeslayer people in poor economies who cannot afford a new computer, and cannot afford to stay with XP since it is unsupported
<dholbach> didrocks, thanks! :)
<shadeslayer> israel: but I doubt you can run much with 128 MB's of RAM
<shadeslayer> for LO is out of the picture, as is firefox, chrome
<shadeslayer> midori maybe, not sure how much RAM it takes
<mvo_> xnox: http://paste.ubuntu.com/8215517/ <- this should actually be much nicer, sorry that it took me so long
<israel> shadeslayer... I have a nice old 128MB device.  It runs just fine :)  The OS runs in about 60MB ram, so you can do A LOT  This isn't Gnome or even LXDE... ya know?
<Unit193> shadeslayer: w3m will work fine.  Also, yes, you can generally use the squashed system itself as the new system.  I did an install once without ubiquity, not bad.
<mvo_> xnox: against the debian/sid branch, you can test with apt-helper
<xnox> +++ b/apt-pkg/contrib/proxy.h
<xnox> +#include <apt-pkg/proxy.h>
<israel> Midori works fine, FF works albeit slowly and Abiword is always an alternative to LibreOffice
 * xnox is not sure how that works.
<shadeslayer> xnox: heh
<israel> Unit193 agreed, I use JWM though.  and without a display manager it eats up less ram
<shadeslayer> israel: so returning to my original question, why can't the tar.gz be included in the squashfs
<shadeslayer> would make your life easier?
<mvo_> xnox: jetlag
<israel> shadeslayer, I do not think this works...
<xnox> mvo_: =))))))))
<shadeslayer> israel: oh ? :S
 * xnox passes starbucks loyalty card to mvo_ 
<shadeslayer> ah, probably because the ISO mounted as ramfs
<shadeslayer> and that would be huge
<xnox> unless that will compile....
<mvo_> xnox: maybe I'm super jetlaged, but I don't see this include in http://paste.ubuntu.com/8215517/ - at least not in proxy.h :)
<israel> shadeslayer  as a side note, I figured it out... :)
<israel> ln -s /live/image/live/ /root/img
<israel> ln -s /live/image/live/tarballs /
<israel> Sometimes it just helps talking about it, eh?  Like partner programming :)
<mvo_> xnox: what do you think about adding a config for apt in libproxy-tools directly? so that when you install libproxy-tools apt will automatically use the "proxy" command? or do you think that is too suprising?
<xnox> mvo_: hm =) i just nuked the whole git repo tree with hard reset and clean, and I no longer have it either =)
<mvo_> xnox: *puhh* :) glad to hear
<shadeslayer> israel: cool :)
<mvo_> xnox: so the tea helped at least a bit
 * xnox is also jetlagged a bit =)
<israel> Thanks for being an ear to bounce ideas off of :)
<xnox> mvo_: depends for which distro. In Debian, i think i need manual configuration variable for the PAC file url, on ubuntu it all needs to happen automagically if proxy-webkit is available and e.g. ubuntu services are used to set global proxy and pac file settings.
 * xnox has debs \o/
<xnox> testing
<xnox> mvo_: magic =) all works like a charm!
<mvo_> xnox: \o/
<xnox> mvo_: this makes my life just a little bit more wonderful, when using "enterprise" network =)
<mvo_> xnox: great, I will push into git - so libproxy-tools should ship a config or nt :) ?
<mvo_> not
<xnox> mvo_: not for now. In neither ubuntu or debian.
<mvo_> xnox: *sigh*, ok :) I guess we need to put it into the documentation or something then as it seems to be super useful
<xnox> mvo_: since in neither of those it would honor things as root. E.g. "apt-get download" would honor user session proxy settings from gnome, but "sudo apt-get download" would not.
<xnox> mvo_: i will probably create a mini package which uses e.g. APT::PAC-URL thing to specify and fetch proxies, for debian (and/or as a patch for libproxy-tools, or apt with appropriate either compiled binary or python script)
<xnox> and on ubuntu, i'll add support in ubuntu-service to store global PAC url for root user, and make libproxy plugin to talk to ubuntu-service to fetch all those root settings.
<xnox> and then life will be complete.
<mvo_> xnox: great
<xnox> *****-
<sergiusens> Saviq: no, did you create one?
<Saviq> sergiusens, did not, doing now
<Saviq> sergiusens, ciborium or lxc-android-config? both?
<sergiusens> Saviq: both
<sergiusens> I'll link if not
<Saviq> sergiusens, bug #1364434
<ubottu> bug 1364434 in lxc-android-config (Ubuntu) "SystemHint sometimes remains false on system volumes, causing permanent ciborium bubble" [Undecided,New] https://launchpad.net/bugs/1364434
<sergiusens> Saviq: thanks
<tedg> jodh, hallyn, so where are we with fixing upstart cgroups?
<jodh> tedg: I believe hallyn is on the case wrt the required systemd-shim changes - we can't really be convinced everything works as expected until we have that piece.
<tedg> jodh, Okay, cool.
<tedg> Hopefully we can get those pieces moving together.
<hallyn> tedg: I'm working with $*&%(*$&% g_dbus.  I will have StopUnit - which kills all tasks on logout - working today.  I don't know how to get Abandon - which would just mark cgroups remove-on-empty on logout - working, but post what i have so hopefully someone who knows this stuff can tell me how to fix it
<tedg> hallyn, Ah, cool.
<barry> mvo_: ping
<mvo_> barry: pong - want to play again?
<barry> mvo_: still recovering from our last tourny :)
<smoser> pitti, do you have any idea why ca-certificates wouldn't work ?
<pitti> smoser: I haven't dug into that yet, but I suppose we sign the images and catalogue with a cert that isn't in ca-certificates?
<smoser> this "works for me".
<pitti> or sign it with a cert whose CA isn't there, I mean
<smoser> $ wget https://cloud-images.ubuntu.com/query/released.latest.txt
<pitti> smoser: that's on utopic?
<smoser> yeah.
<smoser> (note, all i did was that single command, but as i understood the bug you were asserting that fails)
<pitti> infinity, slangasek, stgraber: TB meeting now
<smoser> $ dpkg-query --show wget ca-certificates
<smoser> ca-certificates	20140325
<smoser> wget	1.15-1ubuntu1
<pitti> same here
 * pitti tries again in a schroot, but I thought I already did that yesterday
<pitti> apt install wget
<smoser> http://paste.ubuntu.com/8216407/
<pitti> fun, it works there
<smoser> you're sure you *had* ca-certificates in the root ?
<pitti> Setting up ca-certificates (20140325) ...
<pitti> yes
<smoser> yeah, and cloud-iamge-utils does Depend on it
<pitti> wget does, t oo
<pitti> too
<pitti> smoser: ah fun -- purging ca-certificates and reinstalling helps
<pitti> so that smells like some weird upgrade issue
<smoser> oh. that is fun.
<smoser> pitti, yeah, very weird in that i dont have it here on my utopic
<pitti> smoser: ok, then sorry for the noise! I'll set it to incomplete and see whether I can reprorduce that on an upgrade
<smoser> which is upgraded pretty much daily-ish
<pitti> I suspect some leftover conffiles from older versions, or missing upgrade cleanup or so
<pitti> smoser: thanks for checking on your system!
<smoser> pitti, if you see stuff like that, please feel free to msg/bump me in irc.
<pitti> smoser: yeah, I did two days ago, but apparently it got lost in the noise
<smoser> i miss a lot of bugmail, sadly i'm not as on top of things as you are  :)
<pitti> so I decided to go for a bug report instead, and keep track of debugging info
<pitti> wasn't all that trivial to get from "juju deploy" failure down to wget, so it at lesat helped wiht the notekeeping :)
<pitti> ah, the beloved bug mail firehose :/
<pitti> smoser: ok, upgrade worked as well; daily utopic dist-upgrade must have gotten that wrong at some point, but *shrug*, fixed itself :0
<pitti> :) even
<pitti> so only one bug left without a workaround
<hallyn> pitti: desrt: ok, if i have a GVariant (returned by a dbus call), g_variant_get_type_string(variant) says "(as)" and g_variant_iter_n_children(iter) says 1, should I not be able to simply g_variant_iter_loop (&iter, "&s", &child) to get the content of that single string into child?
<hallyn> (I asssume not -b c it's not working - but i've tried tons of variations like "(s)" "{s}" as well as using g_variant_iter_get_next)
<hallyn> maybe i should just walk g_variant_get_child with a count
<hallyn> it's not glib-y, but should work
<pitti> hallyn: you mean g_variant_iter_next_value ()?
<hallyn> yeah
<pitti> or g_variant_iter_next () (more convenient in C)
<pitti> hallyn: ought to work, yes (with just "s")
<pitti> not &s
<pitti> hallyn: but g_variant_get_child () seems altogether eaiser
<pitti> hallyn: if g_variant_iter_next () with "s" doesn't work, then I think desrt will be better to answer that (I don't do much with variants, I have little experience with that API)
 * pitti waves good night
<hallyn> pitti: thanks, gnight.
<hallyn> yay, got the string finally
<hallyn> desrt: hi, if you have a few mins at some point, github.com/hallyn/systemd-shim #stopunit.2 has working org.freedesktop.systemd.Manager StopUnit support;  but I cannot get it to respond to org.freedesktop.systemd.Scope Abandon.  Any hints for obvoius reasons why would be greatly appreciated
<hallyn> (could
<hallyn> just be that i didn't set the method prototypes right, i suppose, but probably something even dumber)
<JFSTWO> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<Unit193> henrix: Sorry to see you go, but thanks for your efforts!
<cousteau> any chance of getting the font OCR-B on the repositories?  There's already OCR-A (fonts-ocr-a).  OCR-B is used often in Europe for ID cards and similar.
<cousteau> (and I don't know if it can be freely distributed, but I found it for free on a quick "ocr-b ttf" google search)
<cousteau> maybe I should ask debian?
<cousteau> (it also seems to be available from Arch's AUR, so maybe this means it's legal to distribute, dunno)
<Unit193> "my own contributions are public domain, and others have licensed their copyright claims."  Good luck, sir.
<hallyn> desrt: hm, since I guess the error is "Failed to abandon scope session-6.scope: No such interface 'org.freedesktop.systemd1.Scope' on object at path /org/freedesktop/systemd1/unit/session_2d6_2escope"  I assume that measn I'm supposed to actually set up a new listener on that path when the unit is started?  meaning systemd-shim would have to persist for the duration of the session?  (or a child of its)
<hallyn> i'd kinda prefer to hack systemd to call Manager.Abandon, but that wouldn't fly upstream :)
<cousteau> Unit193, anyway that's not the font I found; the one I found has all iso8859-1 characters
<cousteau> (I also found another one for 30-something dollars, so I'm not going to trust the legality of the first font I found)
<hallyn> in wihch case maybe i didn't need to swicth to subtree after all
#ubuntu-devel 2014-09-03
<pitti> Good morning
<dholbach> good morning
<didrocks> good morning dholbach
<dholbach> salut didrocks
<dholbach> didrocks, how was the response so far? :)
<didrocks> dholbach: excellent! and more than positive overall, so great to see that!
<dholbach> :-D
<seb128> didrocks, nice to read that!
<pitti> stgraber: I'd appreciate if you could take a look at bug 1362224 -- that seems to break cloning and juju-local pretty thoroughly?
<ubottu> bug 1362224 in lxc (Ubuntu) "lxc-clone does not randomize MAC address - juju-local machines have same IPs" [High,Confirmed] https://launchpad.net/bugs/1362224
<zbenjamin> cjwatson: ping, is there some API i can use to find out the writeable location of a specific app or scope ? I could use a way to find this out from the SDK launcher
<mardy> Laney: hi! About bug 1029289, I'd like to have the fix backported to trusty as well. Should I prepare a branch of eds 3.10.4 containing the backported fix?
<ubottu> bug 1029289 in Online Accounts: Account plugins "Need to authorize my google account each time I boot the computer" [Critical,In progress] https://launchpad.net/bugs/1029289
<seb128> mardy, laney is on holidays
<seb128> mardy, but yeah, having an update on top of 3.10.4-0ubuntu1.2 would be the way to go there
<mardy> seb128: OK, I'll try to prepare it
<seb128> mardy, thanks
<zbenjamin> jdstrand: ping, do you know if there is any API to query app writeable locations i can use from the SDK launcher? I need a shared directory so i can communicate with the app
<zbenjamin> jdstrand: same is required for scopes
<pitti> wgrant: to confirm, is the RTM langpack export cron'ed now?
<wgrant> pitti: Yup.
<pitti> wgrant: thanks! adjusting work items in https://blueprints.launchpad.net/ubuntu/+spec/qa-u-spanish-translations accordingly
<pitti> [wgrant] Confirm that message sharing between Ubuntu and this distro will work: TODO
<pitti> wgrant: there's still that one, FTR
<wgrant> Oh, forgot about the blueprint.
<wgrant> pitti: That all works fine, but let me know if anything seems off.
<wgrant> We're on lightly tested ground here.
<pitti> wgrant: ack, thanks; if it works in principle (i. e. stuff has translations with by and large the same numbers than ubuntu), it's fine
<rbasak> infinity: are you available to talk about bug 1359349 please?
<ubottu> bug 1359349 in mysql-5.6 (Ubuntu) "FFe: make mysql 5.6 default mysql-server" [Undecided,Triaged] https://launchpad.net/bugs/1359349
<rbasak> AIUI, you had some concern about the upgrade/transition path?
<Saviq> xnox, hey, can I bug you about a x-building conundrum?
<doko> ScottK, please check packages before blindly removing them:  lp: #6107581 this is a normal ftbfs, and afaics has nothing to do with clang.
<ubottu> Error: Launchpad bug 6107581 could not be found
<doko> bug #1346252
<ubottu> bug 1346252 in dune-grid (Ubuntu) "RM bin dune-grid/ppc64el only, build-depends on missing clang/llvm" [Medium,Fix released] https://launchpad.net/bugs/1346252
<doko> xnox, no idea why you filed this one ...
<ScottK> doko: ansgar asked me to remove it.  The documentation may have been off, but it wasn't blind.
<Saviq> doko, maybe you'll be able to help, libqtdbusmock is a library execing python, it depends on python-dbusmock, too, the problem for x-building is that it tries to pull in build arch python-dbusmock instead of host arch, how should this be solved?
<pete-woods> xnox: hi. do you have any time to help me with this cross-build issue I have received? https://bugs.launchpad.net/ubuntu/+source/libqtdbusmock/+bug/1364842
<ubottu> Launchpad bug 1364842 in libqtdbusmock (Ubuntu) "Unable to install in an armhf chroot" [Undecided,New]
<pete-woods> basically libqtdbusmock is a wrapper around the python-dbusmock library
<pete-woods> it doesn't link it it, just execs as a module
<pete-woods> but it seems that the ubuntu-system-settings app won't cross compile due to a dependency on libqtdbusmock now
<pete-woods> ha
<pete-woods> hadn't realised Saviq was just asking the same thing!
<pitti> darkxst: FYI, I just synced https://launchpad.net/ubuntu/+source/systemd-shim/7-2 -- so you now merely need to rebuild that in your PPA against/for systemd 214
<darkxst> pitti, great!
<rbasak> didrocks: http://blog.didrocks.fr/post/Ubuntu-loves-Developers returns Content-Type: application/octet-stream and Firefox wants me to save a download file :-/
<rbasak> Server: cloudflare-nginx
<didrocks> rbasak: interesting, I don't have that with my Firefox, let me try something
<didrocks> rbasak: mind trying again?
<didrocks> I wonder if it's static htlm page + cloudflare doing this
<didrocks> html*
<didrocks> (sorry, can't really test in the same condition as my ISP doesn't allow self-dns redirection as my IP == server IP)
<rbasak> didrocks: working now
<didrocks> rbasak: ok, mind trying with http://79.94.243.69/post/Ubuntu-loves-Developers ?
<didrocks> (bypassing cloudflare + static html page)
<rbasak> didrocks: that also works in Firefox. Using wget, I no longer see a Content-Type header at all.
<didrocks> rbasak: yeah, so it's cloudflare + static html page, thanks! that gives me a hint from where to start my investigation :)
<rbasak> didrocks: ah, so cloudflare turns the no-content-type into a content-type=octet-stream?
<didrocks> rbasak: that's my guess
<rbasak> That seems a bit wrong to me.
<didrocks> it clearly is :)
<mdeslaur> xnox: happy birthday :)
<jdstrand> zbenjamin: there is not yet an api to query for a writable area, though, there will be. however, the writable areas are very predictable: http://developer.ubuntu.com/apps/platform/guides/app-confinement/
<jdstrand> zbenjamin: (see Runtime Environment)
<jdstrand> zbenjamin: scopes are similar: https://wiki.ubuntu.com/SecurityTeam/Specifications/ScopesConfinement
<zbenjamin> jdstrand: i saw that document, my only concern is that they might change
<jdstrand> zbenjamin: pick the ones in .local/share/...
<zbenjamin> jdstrand: can i somehow query if a app/scope is running in confinement or not?
<zbenjamin> jdstrand: or going to be run in confinement, i think for the app there is some env var defined that specifies that
<jdstrand> zbenjamin: the paths won't change any time soon (we follow XDG basedirs to be predictable)
<jdstrand> zbenjamin: you have everything you need in the sdk to know if it will be confined
<jdstrand> zbenjamin: if it is not click, then it won't be confined. if it is click, check the apparmor template. if it is not 'unconfined', it is confined
<zbenjamin> jdstrand: awesome thx
<zbenjamin> jdstrand: same for scopes i gues
<zbenjamin> s
<didrocks> rbasak: ok, that should be fixed now (played with my htaccess to force the content type if the file is set)
<didrocks> rbasak: I used a static html file yesterday after popey tried to DDOS me when tweeting :)
<popey> lolz
<jdstrand> zbenjamin: yes. so, for apps, use the ~/.local/share/<'name from click manifest'>
<zbenjamin> jdstrand: i'm going to put files and named pipes the helper script has to read and write into those locations , so we do not need to have access to /tmp anymore, but only the supported directories
<zbenjamin> jdstrand: ok
<jdstrand> zbenjamin: for scopes, if it uses the 'ubuntu-scope-network' apparmor template, use ~/.local/share/unity-scopes/leaf-net/<name in click manifest>
<ogra_> xnox, happy birthday !!
<jdstrand> zbenjamin: for scopes, if it uses the 'unconfined' template, use ~/.local/share/unity-scopes/unconfined/<name in click manifest>
<jdstrand> zbenjamin: that sounds great
<rbasak> didrocks: :)
<didrocks> thanks again for the notice :)
<rbasak> didrocks: I use a static generator for my blog now, just so I don't have to care.
<rbasak> No problem.
<zbenjamin> jdstrand: so we have real confinement in case when gdbserver is not attached (no debug policy needed), and when gdbserver is attached we can cut some more privileges from the debug policy
<jdstrand> cool
<jdstrand> (we could remove the user-tmp abstraction)
<zbenjamin> jdstrand:  :)
<vak> i use  "apt-get source --compile" to compile a huge package. Is it possible to pass "-j N" option to the underlying make utility calls?
<rbasak> vak: the standard that Debian source packages follow is to heed the environment setting DEB_BUILD_OPTIONS="parallel=N"
<rbasak> vak: I'm not sure if apt-get source --compile passes that through or not, but you could try it.
<rbasak> vak: paying attention to that environment setting is up to the source package though. Helpers like debhelper support it by default, unless the packager is doing something custom.
<vak> rbasak: thank you! will the compilation continue from its interrupted place if i CTRL-C it ?
<rbasak> vak: no idea about apt-get source --compile; I don't use that. Usually you can resume a build if you're managing it manually only.
<rbasak> So I'd say probably not, at a guess.
<vak> well... not sure what you mean, because the package isn't my, and the compilation i started as 'apt-get source --compile this_damn_huge_package'
<vak> i see ))
<vak> gotta wait then ((
<doko> jamespage, why is bug #1353729 a blocker? there is a workaround. the real blocker for mysql-5.6 are the failing autopkg tests, now known for months and still unfixed ...
<ubottu> bug 1353729 in gcc-4.9 (Ubuntu) "[4.9 Regression] ICE in final_scan_insn, at final.c:2952 (aarch64-linux-gnu)" [Medium,Confirmed] https://launchpad.net/bugs/1353729
<jamespage> doko, that's not what's blocking transition - rbasak is working on the autopkgtests
<jamespage> doko, what's the workaround - must have missed it
<doko> jamespage, "works with -O1", so just build this file with lowered optimization
<vak> rbasak: 1)the DEB_BUILD_OPTIONS is respected! 2) the compilations starts from scratch
<mardy> seb128: hi! About bug 1029289, I created a branch (lined to the bug), tested it in a ppa (ppa:mardy/daily) and updated the bug description to make it ready for the SRU
<ubottu> bug 1029289 in Online Accounts: Account plugins "Need to authorize my google account each time I boot the computer" [Critical,In progress] https://launchpad.net/bugs/1029289
<seb128> mardy, thanks, did you subscribe ubuntu-sponsors to the bug?
<mardy> seb128: no, I was trying to get someone from #ubuntu-bugs; I'll follow your advice, though
<seb128> k
<Lazza> Hello everyone
<mpt> mvo, hi, update-manager just opened while I was in the middle of an apt-get upgrade. That isnât supposed to happen. Any extra logs that might be useful for the bug report?
<mvo> mpt: it used to check with the ubuntu-system-service, but http://bazaar.launchpad.net/~ubuntu-core-dev/update-notifier/ubuntu/revision/788 changed this - but the change happend a long time ago. is this utopic or trusty?
<kenvandine> bigon, i have a request related tot he folks package
<kenvandine> bigon, i'm looking at splitting the dummy and key-file backends out of the lib package into a separate binary, so they don't get loaded everything it's used
<mvo> mpt: if the upgrade is still running, could you run pkgexec /usr/lib/update-notifier/package-system-locked and see what that outputs?
<kenvandine> s/everything/everytime
<kenvandine> bigon, i think they are only used by tests
<mpt> mvo, itâs 14.04
<mpt> mvo, assuming you meant pkexec: â/var/lib/dpkg/lock:  22676â
<mvo> mpt: ups, pkexec indeed . and echo $? - do you see "2" there?
<mpt> mvo, yes
<mvo> hm, those are the correct values, it should not have started it :/
<mpt> Ok, just using ubuntu-bug then
<bigon> kenvandine: hey, the key-file is used if eds is not running I think
<bigon> the dummy one I'm not too sure
<kenvandine> we noticed it with the address-book-service, which only needs eds
<kenvandine> bigon, bug 1364548
<ubottu> bug 1364548 in folks (Ubuntu) "Avoid install devloper backends with main folks package" [Medium,Triaged] https://launchpad.net/bugs/1364548
<kenvandine> bigon, i have a branch that moves them both to a libfolks-misc25 package
<kenvandine> bigon, what do you think of that?
<doko> jamespage, 5.5.39-0ubuntu3 re-introduces the autopkg test failures
<doko> mlankhorst, what is the mesa/llvm status? time to update mesa?
<jamespage> doko, I look again
 * jamespage siggs
<bigon> kenvandine: maybe this should be discussed with the other telepathy folks
<bigon> are you on #telepathy?
<kenvandine> wow... i'm not anymore :)
<mlankhorst> doko: still waiting for someone to ack the MRE's
<doko> mlankhorst, ok, commented
<shadeslayer> pitti: poke
<pitti> hello shadeslayer
<shadeslayer> pitti: hey, so I'm sort of seeing this https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1359439 on the kubuntu-plasma5 ISO
<ubottu> Launchpad bug 1359439 in systemd-shim (Ubuntu) "[ 7.287663] systemd-logind[1057]: Failed to start unit user@126.service: Unknown unit: user@126.service" [Undecided,Triaged]
<pitti> yep, known issue; I think that hallyn is working on that
<shadeslayer> pitti: trying to get to the live session from ubiquity-dm just relaunches ubiquity-dm
<shadeslayer> http://paste.ubuntu.com/8224229/
<shadeslayer> pitti: ok, but can someone check if it's the same issue?
<shadeslayer> I /think/ it's the same issue, but would be nice to get confirmation
<shadeslayer> that paste is the ubiquity-dm debug log
<shadeslayer> http://paste.ubuntu.com/8224245 is the dmesg log
<zbenjamin> jdstrand: i could use some more help with this. On the launcher side i can just install the click package and inspect the apparmor file to know if the app will run in confinement. But in confinement. how does a process know if its confined or not?
<zbenjamin> jdstrand: my small helper script that sets up the env inside needs to know that
<pitti> most certainly not; that shim error is mostly cosmetical (or sohuld be)
<pitti> shadeslayer: that QXcbConnection: XCB error, is that the cause or consequence of the crash?
<shadeslayer> pitti: I /think/ that's comes from ubiquity-dm and has nothing to do with the login process
<shadeslayer> pitti: mmmm
<shadeslayer> pitti: [   93.207654] kactivitymanage[4339]: segfault at 7f06c56bf9c8 ip 00007f06ced5f4bd sp 00007fff471f7958 error 4 in libQt5Core.so.5.3.0[7f06cea60000+516000]
<shadeslayer> that looks bad
<pitti> shadeslayer: sorry, gotta run now; but seems you found something there?
<shadeslayer> yep
<shadeslayer> I'll have a look
<shadeslayer> pitti: thx for your help
<jdstrand> zbenjamin: so, there are two ways: look in /proc/self/attr/current and see the label the process. the UBUNTU_APPLICATION_ISOLATION env var is also set, but I think possibly only for apps
<jdstrand> zbenjamin: however, there is an issue-- apps that use the 'unconfined' template apparmor template in the security manifest end up with an apparmor label that is not 'unconfined'
<zbenjamin> jdstrand: ok, the UBUNTU_APPLICATION_ISOLATION is not set for scopes , that was my first hope ;)
<jdstrand> so the test is imperfect in that instance
<jdstrand> scopes actually try to readdir ~/.local/share/unity-scopes/unconfined/ to see if they are unconfined
<jdstrand> an app could try to readdir ~/.local/share
<jdstrand> that isn't ideal, I realize
<jdstrand> an app could check UBUNTU_APPLICATION_ISOLATION=1, and if it is, look in its security manifest to see if it is using the unconfined template
<jdstrand> it will be better once we have the query api in place
<zbenjamin> hm but the app or scope will not know the name of the apparmor file :/
<zbenjamin> jdstrand: we are just supporting click packaged apps for now
<jdstrand> tbh, this isn't a use case that was part of the design-- we figured the app developer would know whether s/he chose to use an unconfined template
<jdstrand> why does the app need to kinow if it is confined for your use case?
<jdstrand> actually, the query api doesn't solve this-- you still have to ask it if a particular path is readable or writable (though it would be much cleaner than doing a readdir and checking the return code)
<zbenjamin> jdstrand: not the app, we use a generic helper script to setup the debugging environment (inject gdbserver, redirect stderr and stdout to pipes) , the config file for that has to be in a location it can read, and it of course needs to know where to look at
<tseliot> xnox: hi, I'm wondering what was the use case of adding support for scaling the plymouth theme for LP: #1292458
<ubottu> Launchpad bug 1292458 in plymouth (Ubuntu) "[FFe] a bunch of updates to plymouth" [Undecided,Fix released] https://launchpad.net/bugs/1292458
<tseliot> *for
<zbenjamin> jdstrand: the helper script runs, sets up what we need, and then replaces itself with the app or scope using execv
<jdstrand> zbenjamin: I suggest this: write a small library function, eg is_confined(). have it do a readdir on $HOME. if it fails, return 0, if it succeeds, return 1. when the query api is available, you can change is_confined() to use the query api
<zbenjamin> jdstrand: awesome :) sounds good enough for me
<jdstrand> zbenjamin: this is to be used with the debug policy group?
<zbenjamin> jdstrand: the goal is to make this work without the debug policy group and only use it when debugging c++ or qml (release mode vs debug mode)
<zbenjamin> jdstrand: but with the debug policy group i can read /home right, so my library call will fail
<jdstrand> zbenjamin: that is what I was getting at, yes
<jdstrand> the bash abstraction which is #included in the debug policy group has: @{HOMEDIRS}                      r,
<jdstrand> so, let's use ${HOME}/.local/share
<zbenjamin> jdstrand: that is harder than i thought ;)
<jdstrand> that should work fine. click user hooks do stuff in ~/.local/share/click so ~/.local/share is guaranteed to exist if you install a click
<jdstrand> if we need to change the path at some point, we can
<Saviq> mardy, hey, found an interesting bug in OA as trusted prompts... if I go "Cancel" in the U1 setup, I get the same UI as a standalone app...
<Saviq> mardy, one reason seems to be that it has the --desktop_file_hint still, which it shouldn't any more
<Saviq> mardy, the other seems to be that it respawns it
<alexbligh1> possibly a stupid question, but what is the cleanest way for a package to get its own version number either at build time (I can copy it to an installed file) or in the postinst script?
<infinity> rbasak: I'm around now.
<rbasak> infinity: on a call. I will ping when done.
<infinity> rbasak: Alrighty.
<cjwatson> alexbligh1: grub2/debian/rules:deb_version          := $(shell dpkg-parsechangelog | sed -ne "s/^Version: \(.*\)/\1/p")
<cjwatson> or anything roughly similar
<cjwatson> alexbligh1: in fact, since dpkg 1.17.0, you can use $(shell dpkg-parsechangelog -SVersion)
<cjwatson> I should convert my packages to that
<alexbligh1> cjwatson, ah that's neater. I was using dpkg-gencontrol -O, which is yucky.
<alexbligh1> thx
<rbasak> infinity: ping
<infinity> rbasak: Hai.
<rbasak> So this thing.
<rbasak> I found that if I dist-upgrade to my prepared packaging (in my PPA), then apt-get seems to resolve the upgrade to removing mysql-server.
<rbasak> And not installing mysql-server-5.6.
<rbasak> I can force it by asking for a newer mysql-server.
<rbasak> I didn't really see a way round this. A similiar thing must have happened during 5.1->5.5 but I don't see exactly what.
<rbasak> However, AFAICT, if apt-get has no visibility of mysql-5.5 generated binary packages, then it is happy to upgrade mysql-server and install mysql-server-5.6 to resolve the situation, which is what we want.
<infinity> rbasak: So, this will happen if the resolver thinks the 5.5->5.6 upgrade will remove more packages than just removing mysql-server would do.
<rbasak> So, for a one off, it seemed easier to do it that way. But if you can tell me what I should be doing instead, that's fine too.
<rbasak> I thought it was something like that.
<rbasak> The catch is that we have multiple binary 5.5 packages that should be removed and replaced with different name 5.6 ones.
<infinity> This may be a subtle badness in how conflicts are forcing things off, or similar?
<rbasak> mysql-server-5.5, mysql-server-core-5.5 off the top of my head.
<rbasak> Those would be removed, and 5.6 equivalents would be installed.
<infinity> If it's a 1:1 swap, that shouldn't be an issue.  If the dpkg relationships are right.
<rbasak> Removing mysql-server is removing just one package, right?
<rbasak> And the upgrade involves removing at least two 5.5 server packages.
<rbasak> And I do want those two removed.
<rbasak> So surely whatever I do, apt-get will favour removing one package over removing two packages?
<rbasak> And then once mysql-server is removed, there's nothing to pull in 5.6 even after 5.5 disappears.
<infinity> rbasak: You mean upgrading removes 2 net packages?
<infinity> rbasak: (ie: install 4, remove 6?)
<rbasak> I'm not sure. Let me check.
<infinity> rbasak: If so, you can hint apt to DTRT with decent abuse of C/R pairs.  But I'd have to see the specifics to know what's up.
 * rbasak digs
<rbasak> infinity: it involves installing 5 and removing 4.
<rbasak> dist-upgrade wants to remove mysql-server, in total removing 2, installing 1 and upgrading 2.
<rbasak> To be complete, for the upgrade it wants to remove 4, install 5 and upgrade 1.
<infinity> rbasak: Okay, so it sounds like this is something that package relationships might be able to get slightly more right.
<infinity> rbasak: Fundamentally, though, unless you stage your entire transition in a devirt PPA and sync it all at once, we can't do what you're asking for (process NBS before you do the transition), as that breaks the archive.
<rbasak> I was asking to process NBS after the new binaries arrive, but before a publisher run.
<rbasak> (I know that's unusual, but I couldn't see any other way out)
<rbasak> Can you help me with the package relationships please? It's not clear to me what I'm looking for.
<rbasak> Thinking about it deeper I can understand how what I was asking for may well be impossible.
<infinity> rbasak: Asking me to process NBS after you upload is "before the transition".
<infinity> rbasak: As things will still depend on the old binaries, and become uninstallable.
<rbasak> OK
<infinity> rbasak: Unless there's no new libmysqlclient this time?  That simplifies things a lot.
<rbasak> libmysqlclient18 stays and with the same soname. I've just switched it from being built from src:mysql-5.5 to it being built from src:mysql-5.6. So apt-get sees a packaging version bump but nothing else.
 * rbasak hopes he checked the other reverse deps, but it was a while ago.
<zbenjamin> jdstrand: so i can write anywhere in ~/.local/share ? or in ~/.local/share/packagename
<infinity> rbasak: So, for package relationships, the key to apt's view of the world WRT "violent removal" versus "polite removal" is that the polite option needs a Conflict/Replace pair hint, not just a conflict.  If you have a bunch of conflicts, then it assumes all conflicting packages are "equal", and picks the path of least damage.
<infinity> rbasak: If one package C/R another, however, it will get a precedence in the preference weights for the purpose of an upgrade calculation.
<rbasak> I think I've got mostly B/R rather than C/R, but I do seem to have an R in most things, unless I missed something.
<infinity> rbasak: B/R means something entirely different.
<infinity> rbasak: B/R means "I overwrite some files from this other thing", C/R means "when I'm installed, this other packages needs to go away".
<infinity> rbasak: mysql-5.5 and mysql-5.6 shouldn't break each other (unless, in some version combo, they're coinstallable), they should conflict.
<infinity> rbasak: Another way to think about it is that if it's no versioned (and can't be), breaks was probably wrong, and the logical inverse, if you can version it, conflicts is probably wrong.
<rbasak> infinity: OK, thanks. I thought Breaks was enough (and I think I inherited this from the original 5.6 packaging). I didn't realise it affected apt's resolution.
<infinity> rbasak: Right, so.  A policy re-read might be in order.  Or some nuanced education. ;)
<rbasak> I have it up and have been re-reading :)
<rbasak> With your explanation I can see how I can interpret policy in the way that you say.
<rbasak> I'm not sure it's obvious from just reading it though.
<infinity> rbasak: Conflicts means "these two packages can't be installed together".  Breaks means "deconfigure A to install B".  Replaces means "overwrites some files".  B/R means "deconfigure and replace some files" (the best way to replace files, as it won't let you undo the process and lose files mysteriously), C/R means "can't install together and, furthermore, prefer this package always".
<Saviq> seb128, hey, I think you've been through this before... is there a script for moving all bugs from project to ubuntu/project?
<infinity> rbasak: In the case of two packages that should never coexist, Conflicts is always right.  When one should take precedence over another (ie: a version takeover, or a change or upstreams, etc), the "good" one should C/R instead of just C.
<rbasak> OK, got it.
<rbasak> So if I change the relevant (I think probably all, but will check) Breaks to Conflicts, apt should do the right thing.
<rbasak> I'm >EOD now, so I'll try this tomorrow. Thank you.
<rbasak> (and also noted that it's more correct to use Conflicts here, so I'll do that)
<infinity> rbasak: One could make some very solid arguments for how all of these states should be different relationships instead of mysterious magic pairs, but it's what we've got to deal with today. :P
<rbasak> :)
<rbasak> I think I was just reading from a point of view that breaks is less invasive (in general, I see now it's probably not relevant here) and from what I read in policy that breaks would do, so I didn't consider it an issue.
<rbasak> I didn't realise that it also affected apt's resolution.
<rbasak> Anyway, I get it now. Thanks.
<infinity> rbasak: It's possible that even with policy-compliant relationships, the upgrade won't do what you want.  If that end up being the case, point me at your work, and I'll argue with the tools (and mvo) instead of you. :)
<shadeslayer> can someone help me with a weird build failiure that I absolutely do not get
<shadeslayer> https://launchpadlibrarian.net/183945400/buildlog_ubuntu-trusty-i386.firefox_32.0%2Bbuild1-0ubuntu0.14.04.2~ppa1~trusty1_FAILEDTOBUILD.txt.gz
<shadeslayer> it only happens on i386 on Trusty
<shadeslayer> https://launchpad.net/~rohangarg/+archive/ubuntu/firefox/+sourcepub/4389166/+listing-archive-extra
<sarnold> shadeslayer: on a first guess, it looks like the headers may not be protecting themselves against multiple inclusion with the usual #ifndef mangled_header_name #define mangled_header_name .... #endif   trick
<shadeslayer> they are not
<shadeslayer> sarnold: how would that affect amd64 btw?
<sarnold> some projects don't do that, instead they manage their dependencies to avoid it.. dunno what firefox does..
<shadeslayer> or for that matter, precise built fine on i386 and amd64, same patches
<sarnold> shadeslayer: d'oh, I forgot that bit :(
<LocutusOfBorg1> https://launchpadlibrarian.net/183614592/buildlog_ubuntu-trusty-i386.firefox_32.0%2Bbuild1-0ubuntu0.14.04.1_UPLOADING.txt.gz
<LocutusOfBorg1> seems that the official build succeeded
<shadeslayer> LocutusOfBorg1: yes, this is specific to 2 patches that I add
<infinity> LocutusOfBorg1: Yeah, the official build lacks the KDE patches that are causing the issue. :)
<LocutusOfBorg1> but cris reported a similar build failure https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1348333
<ubottu> Launchpad bug 1348333 in firefox (Ubuntu) "Firefox 32 fails to build on Trusty x86 only" [Critical,Triaged]
<shadeslayer> nah, looks like a different thing
<LocutusOfBorg1> ah ok there is a delta :)
<shadeslayer> LocutusOfBorg1: yeah :)
<shadeslayer> LocutusOfBorg1: specifically these patches : http://www.rosenauer.org/hg/mozilla/file/e4fa9844604e/mozilla-kde.patch & http://www.rosenauer.org/hg/mozilla/file/e4fa9844604e/firefox-kde.patch
<LocutusOfBorg1> mozilla-kde.patch
<LocutusOfBorg1> firefox-kde.patch
<LocutusOfBorg1> yes, I was already looking at them lol
<shadeslayer> :)
<infinity> shadeslayer: Anyhow, I'd say the class redefinition error is pretty clear.  Why it's only happening on one arch could be any number of things, but maybe that header is conditionally included, or the class conditionally defined, etc.
<shadeslayer> that would be very weird
<infinity> Have you read the mozilla codebase?
<infinity> Weird doesn't begin to describe it.
<jdstrand> zbenjamin: if confined, you can neither read nor write to ~/.local/share/, which is why I was saying do (the equivalent of) a readdir()
<shadeslayer> infinity: I have
<shadeslayer> infinity: unfortunately, you're right :(
<jdstrand> zbenjamin: if confined, you can write to ~/.local/share/<name for click manifest>
<jdstrand> ~/.local/share/<name from click manifest/*
<jdstrand> zbenjamin: ^ (and  ~/.local/share/<name from click manifest/ itself)
<LocutusOfBorg1> shadeslayer, mozilla-kde.patch
<LocutusOfBorg1> +++ b/uriloader/exthandler/unix/nsCommonRegistry.h
<LocutusOfBorg1> there is no #ifdef guard
<shadeslayer> yeah
<shadeslayer> I think adding ifdef guards is the best way forward here
<LocutusOfBorg1> +++ b/uriloader/exthandler/unix/nsCommonRegistry.h
<sarnold> shadeslayer: hmmm, http://www.rosenauer.org/hg/mozilla/file/e4fa9844604e/mozilla-kde.patch#l2579
<LocutusOfBorg1> also in nsKDERegistry
<shadeslayer> sarnold: that's utils
<sarnold> this one is missing though http://www.rosenauer.org/hg/mozilla/file/e4fa9844604e/mozilla-kde.patch#l2842
<shadeslayer> not registry
<sarnold> shadeslayer: ahh d'oh
<LocutusOfBorg1> I think I found it
<LocutusOfBorg1> +++ b/uriloader/exthandler/unix/nsKDERegistry.cpp
<LocutusOfBorg1> there is one +#include "nsKDERegistry.h"
<LocutusOfBorg1> also done here
<LocutusOfBorg1> +++ b/uriloader/exthandler/unix/nsCommonRegistry.cpp
<LocutusOfBorg1> and the last one includes nsKDERegistry.h
<LocutusOfBorg1> so it might be repeated here since there is no guard
<LocutusOfBorg1> also nsMIMEInfoUnix.cpp includes it
<shadeslayer> shouldn't that be fine btw?
<shadeslayer> or well, it looks fine to me
 * shadeslayer thinks it's a issue with the generated CPP file
<shadeslayer> which probably has arch dependent includes and what not
<sarnold> just fix up the includes to properly handle multiple inclusions
<shadeslayer> sarnold: yeah
<shadeslayer> that's what I'm doing
<sarnold> shadeslayer: if you figure out why it only errors on x86 and not amd64, I'd be interested to know why :)
<sarnold> shadeslayer: but if you just get it fixed that'd make sense, hehe
<shadeslayer> sarnold: heh ok, I'll have to do a local build probably
<shadeslayer> if I have time, I'll look into it
<hallyn> pitti: stgraber: slangasek: tedg: so I do have a concern actually about the upstart-cgroup-phone thing.
<hallyn> I was going to make Abandon mean that we set the cgorup remove-on-empty and try to delete it.  But I guess that actually doesn't work for upstart
<hallyn> bc if the upstart job has a task still in the cgroup, then we can still have the same race.
<hallyn> (alas jodh is gone)
<hallyn> the question is can that ever happen - that an upstart job says 'pre-start' or 'start script' is done, but there are stlil tasks running thta are descendents of that job?
<tedg> Couldn't it just set it to remove-on-empty and just make it Upstart's job to remove the PIDs?
<hallyn> that's not the problem
<hallyn> I have StopUnit to kill the tasks, I'm happy with that
<hallyn> but by default we use Abandon.  So if a task remains in the upstart job's cgroup, then it could still exit - causing autoremove of the cgroup - after the post-stop has created the cgroup but before it exec'd the tasks
<hallyn> so, until i hear from jodh (or someone else) that upstart wlil ensure that all job tasks are done at the end of pre-start etc,
<hallyn> i wont set remove-on-empty
<hallyn> i'll just delete, and if it wasn't empty, well, it won't be removed.
<tedg> For the UAL case (which is the one I care about) we try and ensure that all the processes are removed.
<tedg> I'd honestly rather just be able to set a flag that says if PIDs are left, kill them.
<hallyn> ok, then i will do the remove-on-empty.  if you end up having trouble after al, then we can remove it
<tedg> So it would call RemoveUnit at the end of the instance.
<hallyn> well you have htat 'flag', only systemwide
<hallyn> (KillUserProcesses in /etc/systemd/logind.conf)
<hallyn> desrt_: so using /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service we can register Name=org.freedesktop.systemd1 as a path for which we are started when there is activity.  can we do the same at runtime (only until reboot)?
<seb128> Saviq, bdmurray has something for that iirc
<Saviq> seb128, almost got there myself, thanks :)
<bdmurray> pitti: do you have any ideas about bug 1365079?
<ubottu> bug 1365079 in apport (Ubuntu) "apport should gather package information about click packages" [Undecided,New] https://launchpad.net/bugs/1365079
<bdmurray> pitti: I'm not positive how to proceed.
<doko> cjwatson, looking at the coreutils autopkg test failures. there are now a lot more, and I don't know if just disabling these is the right thing to do. It might be better to build a coreutils-test package including the config.h and test binaries like getlimits and ginstall
<catbus1> Hi, I don't see Ubuntu 14.04.2 release date on https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule, is there a plan to update this page with the upcoming point release schedule info?
#ubuntu-devel 2014-09-04
<Unit193> pitti: guten Morgen
<pitti> Good morning
<pitti> hey Unit193
<pitti> bdmurray: yeah, so far we never talked about click support in apport; a lot of concepts are quite different (e. g. they don't necessarily have an LP project, don't have source packages, can't be retraced), so we need to invent some new fields and teach the error tracker about it (Click: and SystemImageVersion:, and it wouldn't have Package:/SourcePackage:/Dependencies?)
<zbenjamin> jdstrand: but wouldn't the debug policy allow me to read the ~/.local/share directory as well?
<mardy> Saviq: hi! Thanks for the report, I'll remove the --desktop_file_hint
<Saviq> mardy, cool, any idea why it would restart the ui?
<mardy> Saviq: but we don't respawn it... Did you start the U1 account creation from the System Settings, or from where?
<Saviq> mardy, it got spawned by the pay ui
<Saviq> as we now can do prompts in prompts
<mardy> Saviq: then most likely the pay UI has a loop like "while (!accounts) { createAccount() }"
<Saviq> mardy, well, it restarted outside of the trusted session, though
<Saviq> mardy, which is why it ended up a separate app
<Saviq> mardy, I'll report bugs with steps to repro
<mardy> Saviq: that is weird, I'll investigate (though I suspect a bug with the "trust session in trust session" thing, maybe the second session cannot be restarted)
<mardy> Saviq: excellent, thanks
<mardy> Saviq: speaking of bugs, I got this one yesterday, which I don't believe is really mine: bug 1365097
<ubottu> bug 1365097 in Online Accounts: Sign-on UI "Blocked trusted prompt session after resume from suspend" [High,Confirmed] https://launchpad.net/bugs/1365097
<mardy> Saviq: do you have any idea if that could be unity8 or qtmir or...?
<Saviq> mardy, right, when that happens I have a lingering /usr/bin/online-accounts-ui
<Saviq> mardy, same happened to me when I cancelled the pay ui before it was able to trigger the accounts ui
<dholbach> good morning
<Saviq> mardy, I can't get another prompt until I restart the service, though
<mardy> Saviq: I'll see if I get some notification from mir about the trust session state, maybe I can cancel it
<Saviq> mardy, but it is also true that we shouldn't be closing the prompt on unfocus, which we do
<Saviq> mardy, you can reproduce the same situation by just swiping from the right to switch to the dash
<Saviq> mardy, and yeah, I can't reproduce the respawning with settings app, so must be pay doing something indeed
<Saviq> but why would it start outside of a trusted sesssion...
<mardy> Saviq: I'll investigate, it may be that we don't clear our session properly
<Saviq> mardy, yup, I'll go through and file some bugs with steps then
<mardy> Saviq: so, when we get unfocused, we do get a signal that the prompt session has been stopped; I'll make sure that we clean it up, then
<Saviq> mardy, coolz
<Saviq> mardy, yeah, confirmed, the respawned one is actually a second session, filing a bug against pay-ui
<mardy> Saviq: cool, thanks
<Saviq> mardy, bug #1365346
<ubottu> bug 1365346 in pay-service (Ubuntu) "Cancelled accounts prompt gets respawned in an invisible session" [Undecided,New] https://launchpad.net/bugs/1365346
<Saviq> tvoss, can we get your opinion please https://bugs.launchpad.net/qtmir/+bug/1355173/comments/15
<ubottu> Launchpad bug 1355173 in unity8 (Ubuntu) "Switching windows with a Trusted Prompt Session active loses the trusted prompt session" [High,Triaged]
<penghuan> cjwatson, hi, can you help to do the merges  of   https://code.launchpad.net/~laney/ubuntu-archive-publishing/kylin/+merge/232828   and   https://code.launchpad.net/~laney/ubuntu-cdimage/kylin/+merge/232829
<He4dShOt> hi
<He4dShOt> i upgraded to utopic and now X won't start automatically
<He4dShOt> can't understand why
<He4dShOt> any help?
<didrocks> hey doko_, I have an issue with our system python version and coverage report on subprocess. If I used the same coverage library, but within a virtualenv python3, everything works fine, not if I use our system python3 though (the subprocess isn't covered)
<didrocks> doko_: is that known, want a more detailed bug report?
<zbenjamin> jdstrand:  i tried you suggestion but i can read the dir when the debug policy is enabled :/
<didrocks> doko_: barry: after more investigation, it's init_cov_core.pth which is missing in the system path dir. That's why subprocess coverage report isn't enabled at all. Any reason why it's not shipped?
<didrocks> doko_: barry: it seems to be controlled by an env var to enable/disable coverage, so shouldn't impact (apart from the extra .pth file import) perfs
<LocutusOfBorg1> thanks dholbach
<LocutusOfBorg1> :)
<LocutusOfBorg1> He4dShOt, are you sure using utopic is the best thing to do at this moment? :)
<cjwatson> penghuan: thanks, I just got back from conference/vacation, can you give me a while to get through my mail pile?
<cjwatson> penghuan: those MPs are in there ...
<penghuan> ok, cjwatson, if the code does not have any problem, can you help merge it, then we can go the next step for ubuntukylin seeds
<cjwatson> penghuan: I'm not sure you read what I wrote :)
<penghuan> cjwatson, you mean you are doing it? sorry for my bad English:)
<cjwatson> penghuan: I mean please give me a while to get through my mail archive, which contains the merge proposals you are asking about
<penghuan> cjwatson, ok, thanks!
<coderus> hello! o/
<coderus> can i get help about ubuntu sdk for ubuntu touch here?
<ogra_> coderus, try #ubuntu-app-devel
<coderus> ogra_: yep, sorry, already asked here :)
<doko> jamespage, mysql-5.5 blocking gcc-4.9 again ...
<jamespage> doko, ok - I'd not realized that  main.mysqlhotcopy_myisam was also failing
<jamespage> let me see
<doko> didrocks, so, the python-coverage is a non-issue?
<didrocks> doko: the issue is that nose-cov doesn't ship init_cov_core.pth. I think barry packaged it.
<didrocks> python-coverage by itself doesn't support subprocess coverage tracking
<doko> ahh, ok. waiting for him
<barry> doko, didrocks hi
<didrocks> hey barry!
<barry> what's up?
<didrocks> barry: so, I was wondering why my subprocesses (once outside my virtualenv) were not reported in the coverage report
<didrocks> I'm using nose-cov
<didrocks> I see that this is because init_cov_core.pth isn't shipped in the python3 system path
<didrocks> would you think of any bad reason to avoid doing that?
<didrocks> (it seems code coverage activation is controlled by an env variable, so apart from python opening this file, the penalty for people installing it doesn't seem high)
<barry> didrocks: i don't remember this case in particular, but very often .pth files do evil things
<barry> didrocks: like, they get "auto" imported when python initially scans for sys.path.  they show up in sys.modules before any explicit import.  yuck.
<didrocks> barry: however, without this, subprocesses coverage is broken
<didrocks> barry: import os; os.environ.get("COV_CORE_SOURCE") and __import__('cov_core_init').init()
<didrocks> so yeah, it will import os anyway
<barry> didrocks: i initially packaged nose2-cov and cov-core.  i guess nose coverage also uses cov-core?  there's a new upstream i haven't gotten to yet for cov-core.  i got subproc coverage working properly in systemimage (which uses nose2) without cov-core because cov-core was causing too many problems.
<didrocks> barry: I did package nose-cov, and yes, it's using cov-core.
<didrocks> which kind of problems?
<barry> didrocks: the question is whether you have control over the subprocs.  if so, you *can* instrument them to invoke coverage when you want
<jdstrand> zbenjamin: can you paste the output of 'apparmor-parser -p /var/lib/apparmor/profiles/click_<your app policy with debug policy group>
<jdstrand> '
<didrocks> barry: I don't have control over it in some tests that are using docker containers
<barry> didrocks: i can point to and explain the systemimage code that makes this work in its vcs of course
<barry> didrocks: hmm.
<jdstrand> zbenjamin: I see the problem: /**/ r,
<barry> didrocks: that code snippet is what's in the .pth file?
<didrocks> barry: yep
<jdstrand> zbenjamin: but please paste that and I can come up with a better path
<zbenjamin> jdstrand: ok :)
<didrocks> barry: not sure why it's not in the source package though, I got it with pip install in my virtualenv
<barry> didrocks: the problem isn't os, since you'll effectively always get that anyway, it's that if you start up python, you'll always get the .pth file "imported" and thus sys.modules will always have cov_core_init
<jdstrand> zbenjamin: can you also paste the checking code?
<didrocks> barry: well, only if you export the env var
<barry> didrocks: hmm
<barry> didrocks: let me look at the new upstream for cov-core today
<didrocks> sure, thanks!
<barry> didrocks: in general i'm not a fan of cov-core and nose2-cov (i greatly prefer nose2 over nose but whatevs :)
<zbenjamin> jdstrand: like this? http://pastebin.ubuntu.com/8233495/
<barry> didrocks: i'll let you know how it goes ;)
<didrocks> barry: thanks a lot :)
<zbenjamin> jdstrand: the python code is basically doing this:
<zbenjamin>     test_dir = os.path.expanduser('~')+"/.local/share"
<zbenjamin>     os.listdir(test_dir)
<didrocks> barry: yeah, I investigated some time already on it, so I won't switch right away :)
<didrocks> (as other people I guess)
<jdstrand> zbenjamin: yes, thanks, give me a sec
<barry> didrocks: i offer to help with a nose->nose2 :)  nose2 is the futchah!
<barry> (plus it has an awesome plugin architecture)
<didrocks> barry: if that can work as well on trusty without backporting the world, I'm happy for this (but would prefer first to go the easy road, then, accepting your offer ;))
<didrocks> barry: the .pth is generated in setup.py
<barry> didrocks: i'm pretty sure it does, given systemimage has used it forever :)
<barry> didrocks: gotcha.  i think i'll add a dep-8 test for this
<didrocks> barry: excellent! then, we'll discuss about nose2 :) (I need to backport your change to my trusty ppa first)
<barry> didrocks: it might be a little while.  thursdays are meeting days ;)
<jdstrand> zbenjamin: ok, can you add this before the last '}' in your profile: audit deny @{HOME}/.local/share/ r,
<didrocks> barry: no worry, if you think you can't do it before EOW, just tell me, I'll do this then
<jdstrand> zbenjamin: then do: sudo apparmor_parser -r /var/lib/apparmor/profiles/click_<your profile>
<barry> didrocks: np.  definitely should get to at least look + new upstream today
<didrocks> sweet!
<jdstrand> zbenjamin: then try again? I think I like this check so I can adjust the debug policy group for it
<zbenjamin> jdstrand: PermissionError: [Errno 13] Permission denied: '/home/phablet/.local/share'
<zbenjamin> jdstrand: looking good
<jdstrand> ok good. then I'll adjust the debug policy group
<jdstrand> zbenjamin: I'm going to use 'audit deny' so we still have the denial logged, to give a cue on the check. I could drop 'audit'. do you have a preference as the main consumer of this policy group?
<pitti> stgraber: do you have an opinion on bug 1361964?
<ubottu> bug 1361964 in calibre (Ubuntu) "FFE: Port to Qt5" [Undecided,New] https://launchpad.net/bugs/1361964
<zbenjamin> jdstrand: either way its fine for me
<jdstrand> zbenjamin: ok, it will be in the next upload. likely later this week
<zbenjamin> jdstrand: awesome thanks :)
<zbenjamin> jdstrand: i'll ping you when i don't need access to /tmp anymore
<lool> slangasek: multiarch question: install crossbuild-essential-armhf on my main system seems to want to remove multiarch-support; is that bad? this is because:  libgcc1:armhf : PreDepends: multiarch-support:armhf but it is not going to be installed
<lool> slangasek: ah well, transitional package; I guess i need not worry
<cjwatson> lool: sometimes happens if you have skew between arches, which shouldn't happen in the release pocket.  you don't have -proposed enabled by any chance?
<stgraber> pitti: oh, sorry, yes, I said I'd review that one, doing so now
<pitti> stgraber: yeah, pinged you as you said you wanted to; if you want to delegate to someone else (ScottK?) that's fine too of cousre
<ScottK> pitti: Did upstream release the Qt5 version?
<stgraber> pitti: edubuntu is the only flavour seeding it so I guess it sort of makes sense for me to review it, ScottK doesn't seem to be against it for utopic, just concerned about the backports and I believe you've addressed that (backport the last Qt4 version and then there won't be anything we can backport anyway)
<pitti> ScottK: yes, 2.0.0 is that (http://calibre-ebook.com/whats-new)
<pitti> stgraber, ScottK: If we want to go with the qt5 version, I'd like to get further 2.x reelases into utopic, as I expect a number of bug fixes for the new Qt5 UI
<pitti> ah, 2.1 is out already, like clockwork
<ScottK> Right, up to stgraber.  If it weren't seeded, I'd say go for it.
<pitti> stgraber: would that introduce qt5 into edubuntu, or does edubuntu already have it and thus rather want to get off qt4?
<pitti> to clarify, I won't be grumpy or anything if we postpone that to 15.04, just asking (as people generally prod me for packaging the latest and greatest)
<lool> cjwatson: I do not
<stgraber> pitti: there you go
<lool> cjwatson: this is on utopic
<lool> cjwatson: perhaps I'm doing it wrong too; basically it's an apt-get install crossbuild-essential-armhf on an utopic system with a moderate amount of tools installed; I've added "deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports/ utopic main restricted universe" to sources.list and that's it
<pitti> stgraber: ack, thanks; I'll keep up with 2.x versions, yes
<lool> cjwatson, slangasek: Right, it was me missing add-architecture armhf; sorry for the trivia; works now, not removing multiarch-support
<bdmurray> pitti: while all of that is true, we still get crash reports about click packages in the error tracker and at least having Package / ClickPackage information would help us better bucket these crashes.
<pitti> bdmurray: hm, that's curious
<pitti> bdmurray: oooh -- that's becuase we don't check any UnreportableReason for whoopsie
<pitti> as the UI would reject those as they aren't from a package
<pitti> now I at least understand why we are getting them in the first place
<pitti> jodh, seb128, tedg: so it seems cjohnston has big trouble after a T->U dist-upgrade: almost none of his session upstart jobs run
<pitti> cjohnston: mind pastbin'ing "initctl --list"?
<pitti> any idea how to debug that?
<pitti> so there's just a bare minimum desktop without much real meat
<seb128> pitti, they are pending/waiting?
<pitti> cjohnston: ^
<pitti> (just the messenger, haven't seen much data myself)
<cjohnston> http://paste.ubuntu.com/8233880/
<cjohnston> seb128: ^
<pitti> that's system upstart
<pitti> "initctl --user list" then?
<jodh> pitti: cjohnston: try changing STARTUP="upstart --user --debug 1>&2" in /etc/X11/Xsession.d/99upstart, attempt to login then (via a console) look at ~/.xsession-errors.
<pitti> odd, for me it defaults to user when I run it as user
<jodh> pitti, cjohnston: what does "almost none" mean - does the session actually start and run?
<cjohnston> pitti: when adding --user I get: UPSTART_SESSION isn't set in the environment. Unable to locate upstart isntance
<pitti> aah
<pitti> "ps ux|grep upstart" -> I get upstart --user, and some upstart-*-bridge
<cjohnston> jodh: when I login, I see unity, I see the top bar... the time/date, NM icon, sound icon, etc are missting... None of the icons in the unity bar work, can't open dash, ctrl+alt+t doesn't work
<pitti> cjohnston: is upstart --user running for you? I. e. issue with passing the env, or starting upstart itself
<jodh> cjohnston: try 'initctl list-sessions' to see if there is a session you can join (http://upstart.ubuntu.com/cookbook/#joining-a-session)
<cjohnston> pitti: I do see upstart --user in the ps ux
<jodh> cjohnston: please raise a bug via 'ubuntu-bug upstart' (even via the console) as that will suck up useful meta-data for the bug.
<jamespage> doko, the start of that test failing seems to correspond to the switch to 5.20 of perl
<cjohnston> jodh: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1365535
<ubottu> Error: launchpad bug 1365535 not found
<cjohnston> jodh: does that give you the info you need?
<pitti> FWIW, I can't see this either -- is it super-private?
<cjohnston> pitti: try again
<pitti> ah, works now
<jamespage> doko, yes - both in debian and ubuntu - at least that give me a clue
<bulletxt|2> hi, is there someone here willing to put in ppa an update version of cifs-utils 6.0 for Ubuntu 12.04 ? I really need it........ thanks so much
<cjohnston> jodh: someone else in #ubuntu+1 is reporting that with an intel gpu they don't have these issues
<coreycb> mterry, hi, wanted to ping you on this bug as it's been idle for a bit https://bugs.launchpad.net/ubuntu/+source/python-pysnmp4-apps/+bug/1349868
<ubottu> Launchpad bug 1349868 in python-pysnmp4-mibs (Ubuntu) "[MIR] new build dependencies for ceilometer" [Undecided,New]
<mterry> coreycb, ah yes so it has, sorry
<mterry> coreycb, will try to look at today
<coreycb> mterry, np thanks!
<cjohnston> jodh: http://paste.ubuntu.com/8234110/
<ahasenack> hi, I have this in debian/rules:     dh $@ --with python2 --no-guessing-deps
<ahasenack> I want to pass --no-guessing-deps to dh_python2
<ahasenack> but here is how it ends up being called:
<ahasenack>  dh_python2 -O--no-guessing-deps
<ahasenack> how do I make it right?
<cjohnston> jodh: fwiw there is also https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1365039 and https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1365336
<ubottu> Launchpad bug 1365336 in lightdm (Ubuntu) "duplicate for #1365039 Lightdm update=No desktop" [Undecided,Confirmed]
<ubottu> Launchpad bug 1365336 in lightdm (Ubuntu) "Lightdm update=No desktop" [Undecided,Confirmed]
<ahasenack> that -O is added by debhelper it seems, but incorrectly perhaps? The debhelper manpage talks about -O=option|bundle
<ahasenack> here it's just breaking things
<ahasenack> D: dh_python2:591: argv: ['/usr/share/python/dh_python2', '-O--no-guessing-deps']
<cjohnston> jodh: not sure if it's helpful but I see: nouveau E[ PBUS] MMIO read of 0x00000000 FAULT AT 0x002140 [ !ENGINE ] quite a number of times... and also a systemd-login thing where it can't abandon a session scope
<rbasak> infinity: so it looks like C/R didn't resolve the problem.
<rbasak> Behaviour has changed a little, but apt still wants to remove mysql-server.
<cjohnston> jodh: gQuigs has a similar issue, but for him he doesn't see the unity icons
<infinity> rbasak: Kay.  Point me at a PPA, and I can have a look after some slightly more urgent firefighting.
<cjwatson> ahasenack: I think that's a bug in dh_python2 for not handling that in a debhelper-standard way, though I haven't looked too closely
<cjwatson> ahasenack: but you can easily work around it.  rather than passing that to the dh wrapper, you can instead use:
<cjwatson> override_dh_python2:
<ahasenack> cjwatson: right, I just did that
<cjwatson> \tdh_python2 --no-guessing-deps
<ahasenack> +1
<cjwatson> (where \t is a literal tab of course)
<ahasenack> sounded overkill, though
<ahasenack> but it's the only thing that worked
<cjwatson> it's fairly normal
<cjwatson> ahasenack: this issue is raised in a comment on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638679
<ubottu> Debian bug 638679 in python "[dh_python2] Please don't error out on unknown options" [Important,Open]
<rbasak> infinity: thanks. Uploaded 5.6_5.6.19-1~exp1ubuntu1~dev4 to ppa:racb/experimental. That includes my C/R changes. Building will take a while, but hopefully will be done by the time you look.
<ahasenack> it didn't error, it just ignored it
<ahasenack> I think at some point they "fixed" it to not error on unknown options
<ahasenack> but that is just masking the problem
<cjwatson> ahasenack: you didn't read the whole bug
<rbasak> infinity: to reproduce, I'm just doing 1) apt-get install mysql-server on Utopic, without the repo, and 2) Adding the repo, apt-get update and apt-get dist-upgrade to see what it wants to do.
<ahasenack> no :)
<infinity> rbasak: Righto.
<ahasenack> "dh_python2 and dh_python3 also don't handle -O properly, which makes it
<ahasenack> impossible to pass options to them from dh.
<ahasenack> "
<rbasak> infinity: though note that I used a local repo with just the debs from the mysql-5.6 build, not the PPA, since I'm building with nocheck to speed things up.
<cjwatson> ahasenack: I'm specifically talking about the third paragraph in the second message.  it's not part of the "error out" bit, but it's caused by the same misdesign
<infinity> rbasak: A local repo could also cause curious preference weight issues due to apt's strong dislike of unsigned repositories (unless you pass -o APT::Get::AllowUnauthenticated=true).
<infinity> Unless that's ignored for file:// repos, I can never remember.
<cjwatson> infinity,rbasak: deb [trusted=yes]
<rbasak> Oh
<rbasak> That might be a major issue for my testing actually.
<rbasak> I will try hitting my PPA instead.
<infinity> cjwatson: That's a thing?
<infinity> cjwatson: I like this thing.
<cjwatson> it sure is
<infinity> cjwatson: How long has that been a thing?
<cjwatson> couple of years I think
<rbasak> When I use the local repo, I add a pin. I forgot about that.
<rbasak> (since it's in a script)
<cjwatson> also rather more recently mvo let you use rfc822-style sources.list
<infinity> cjwatson: We should switch lp-buildd to using it, instead of the APT::Get::AllowUnauthenticated hammer, if all our build targets support it.
<rbasak> Pin-Priority: 999
<infinity> rbasak: Pinning doesn't change the internal "screw you, I hate unsigned packages" logic.
<cjwatson> infinity: apt 0.8.16~exp3, 2011-07-15
<rbasak> Oh, OK.
<cjwatson> don't know if it was in Ubuntu earlier
<infinity> cjwatson: Okay, so not supported in lucid, probably.  BUt could switch syntax when lucid dies.
<infinity> cjwatson: Good to know.  I've always hated that we paper over that the way we do.
<rbasak> No dice with [trusted=yes]
<infinity> rbasak: Alright.  Will play later.
<infinity> cjwatson: Hrm, also, this thing means that sbuild's ridiculously complex "let's generate a key to self-sign the local archive for the build-dep metapackage" thing is seriously overengineering and unnecessary.
<cjwatson> yeah, fair point
<infinity> cjwatson: Unless one is actually concerned about a third party without access to the sbuild user's private key somehow having access to poison the sbuild package cache.
<cjwatson> though of course you can build for older series
<rbasak> I hate that too. And anything else that blocks on /dev/random on a throwaway dev machine with low entropy. I'm looking at you too, adt-run.
<cjwatson> but maybe we could detect apt versions
<rbasak> I have a script to throw the same test key on my throwaway dev machines as a workaround. It's still annoying though.
<infinity> cjwatson: Or just add a nice '/* FIXME: REMOVE ALL THIS CODE WHEN WE STOP CARING ABOUT SQUEEZE */'
<ScottK> Didn't we do that already?
<doko> pitti, ricotz: you sponsored/uploaded gtkhtml4, but it requires a transition, currently stuck in -proposed
<infinity> ScottK: squeeze and lucid are both still supported, so some of us have to care. :P
<ScottK> Lucid yes, but unless you're in the special squeeze-lts thing, not so much.
<doko> LocutusOfBorg1, you uploaded insighttoolkit to -proposed, needs a transition
<LocutusOfBorg1> yes doko I missed the point
<LocutusOfBorg1> 4 packages needs to be rebuilt
<doko> LocutusOfBorg1, please do
<LocutusOfBorg1> I have no upload privileges
<LocutusOfBorg1> :(
<LocutusOfBorg1> I asked cjwatson a while ago about them
<LocutusOfBorg1> (not about the upload privileges of course :p)
<cjwatson> anyone with access can do no-change uploads; it's not a good idea to have me responsible for all of them
<LocutusOfBorg1> I was meaning that I asked "here" about them
<LocutusOfBorg1> wasn't a blame against you and your precious work ;)
<LocutusOfBorg1> is it difficult to become an ubuntu developer?
<LocutusOfBorg1> sometimes I would like to have sync privileges for packages I maintain in debian
<ScottK> LocutusOfBorg1: Are you a DD?
<LocutusOfBorg1> not yet
<LocutusOfBorg1> DM
<ScottK> That would make it easier, but it's still not hard.
<LocutusOfBorg1> DM since one year, but my sponsor agreed that will advocate me soon
<LocutusOfBorg1> (unfortunately he is really overbusy and I don't want to ask him again)
<ScottK> LocutusOfBorg1: You probably want https://wiki.ubuntu.com/UbuntuDevelopers#PerPackage and https://wiki.ubuntu.com/DeveloperMembershipBoard/#Application_process
<LocutusOfBorg1> thanks a lot, I'll read them, I remember I read them a while ago, but I gave up :(
<doko> LocutusOfBorg1, but this is not about syncing, but about keeping up until your upload is in the release pocket
<LocutusOfBorg1> I understand, even this morning I looked at the proposed output, hoping that somebody had done the rebuild :(
<LocutusOfBorg1> but unfortunately I need to ask, and people like cjwatson had already done too much for me :) (also daniel, who synced a package this morning)
<LocutusOfBorg1> ScottK, so if I read correctly I need to put my name on the schedule, wait for the meeting and hope for the best? :)
<doko> seb128, Sweetsha1k: any update on https://bugs.launchpad.net/ubuntu/+source/libixion/+bug/1349859 ? pending for a month ...
<ubottu> Launchpad bug 1349859 in libixion (Ubuntu) "[MIR] libixion (b-d of liborcus)" [Undecided,Incomplete]
<seb128> doko, I don't know, that's one for Sweetsha1k
<seb128> doko, in fact seems it's fixed, https://launchpad.net/ubuntu/+source/libixion/0.7.0-2ubuntu1
<seb128> doko, should it be put back to New?
<doko> seb128, why? where is the information for the MIR?
<seb128> doko, ?
<seb128> doko, why what?
<seb128> doko, I was looking at https://launchpad.net/ubuntu/+source/libixion/0.7.0-2ubuntu1 , it seems it built on ppc64el in the current upload
<seb128> doko, but I don't know more than this, maybe you are looking after another problem, I recommend you check with Sweetsha1k
<doko> seb128, https://wiki.ubuntu.com/MainInclusionProcess
<seb128> doko, I know what MIR are, thanks
<seb128> doko, not sure why you ping me, it's not my MIR requests, it's Sweetsha1k's, I was just trying to help by pointing out that the ftbfs issue seems resolved
<doko> seb128, you're the tech lead, afaik, that's why
<seb128> doko, well, doesn't seems there is much tech to resolve there
<seb128> Sweetsha1k just needs to write the content of the MIR
<seb128> Sweetsha1k, ^ can you do that?
<ScottK> LocutusOfBorg1: After writing an application and getting some endorsements.
<doko> pitti, your no-change upload for pgrouting is wrong. needs sourceful changes
<doko> slangasek, https://launchpad.net/ubuntu/+source/libphonenumber/6.0+r655-0ubuntu4 do you care about the ftbfs?
<slangasek> doko: yes, it's on my list of lists
<jtaylor> doko: if you have the time can you look at my numpy sru bug 1358870?
<ubottu> bug 1358870 in python-numpy (Ubuntu) "update numpy to 1.8.2 in trusty" [Undecided,New] https://launchpad.net/bugs/1358870
<doko> jtaylor, commented. but I can't approve it
<jtaylor> someone has to upload it first :)
<doko> slangasek, libphonenumber fixed on ppc64el, arm64 still ftbfs
<slangasek> doko: oh sure, you fixed the easy one ;)
<doko> ahh, ok
<doko> slangasek, so you don't get distracted ;-P
<slangasek> heh
<cjwatson> siretart: were any of your changes in https://launchpad.net/~motumedia/+archive/ubuntu/libav11/+packages more than straight rebuilds?
<nadrimajstor> Hello everyone... Could someone point me to a proper guide on how to make a binary only (no upstream tar.gz) quilt 3.0 package?
<cjwatson> that's not binary-only
<cjwatson> I think you mean native?
<cjwatson> if there's no upstream, then you cannot use 3.0 (quilt), as it doesn't make sense
 * nadrimajstor having trouble wrapping his head around .install/include-binary and tools to manage
<cjwatson> the point of the quiltiness is to manage differences from upstream
<cjwatson> maybe step back and explain exactly what pieces you have
<nadrimajstor> cjohnston: I just have a bunch of .PNGs that should be put in /boot/grub/themes
<nadrimajstor> cjohnston: nothing else...
<cjwatson> please note that I am cjwatson not cjohnston
 * nadrimajstor oooops
<cjwatson> ok, so I don't understand why you specifically want 3.0 (quilt), then
<cjwatson> that sounds better handled as a native package
<nadrimajstor> cjwatson: Reading the post on introduction of 3.0 packages and there was a mention of a quilt feature to have binary includes
<cjwatson> you put "3.0 (native)" in debian/source/format and then do the rest of the packaging as normal, making sure not to have any patches (sounds like there's no danger of that here), and making sure that the version in debian/changelog does *not* contain the "-" character which ordinarily separates the upstream version from the revision of the packaging
<cjwatson> that feature of 3.0 (quilt) isn't necessary here.  it's needed when you otherwise have an ordinary package from upstream and your packaging needs to contain a binary file like an icon or whatever
<nadrimajstor> cjwatson: Being a total noob on deb packaging I wondered off to wrong direction...
<cjwatson> but in this case a native package will do fine, and the whole thing will just be put together as a single tarball by debuild -S
<cjwatson> that feature of 3.0 (quilt) is by comparison with the 1.0 format, which in the case where you had an upstream tarball would create a .diff.gz for the packaging; the diff could only represent text
<cjwatson> but it's a red herring here
<cjwatson> yeah, in cases where things have been put together incrementally over the years it can take a bit of catching up
<nadrimajstor> cjwatson: I got it... Thank you.
<cjwatson> np
 * nadrimajstor thinks that deb package maintainers should get a medal... or a straightjacket... or both.... or a crate of whiskey at least. :D
 * nadrimajstor is just lazy... ignore him.
<cjwatson> well, my whiskey cupboard is quite full
<cjwatson> but it's not really that hard when you're doing it regularly, like most things
<cjwatson> it's just a system that does a lot of things and that people ask a lot of, so it has something of a learning curve
 * nadrimajstor wondered of to make his grub theme package....
<mterry> hallyn, hello!  Can I pick your brain on how to debug a cgroup issue I'm seeing?
<hallyn> mterry: of course
<mterry> hallyn, yay!
<hallyn> :) what's up
<mterry> hallyn, so on krillin devices with Ubuntu Touch, I'm seeing that apps don't have proper cgroups info in /proc/PID/cgroup, such that policykit requests are failing because it doesn't associate them with an active logind session
<mterry> hallyn, I've got this far, but I'm not sure how to find out *why* there's no good info in the cgroup file
<hallyn> mterry: i don't undestand.  what is in your /proc/pid/cgroup then
<mterry> 4:name=systemd:/
<mterry> 3:freezer:/
<mterry> 2:cpuacct:/
<mterry> 1:cpu:/
<mterry> hallyn, ^
<hallyn> so they're in the root cgroup.  these were started from a login session?
<mterry> hallyn, I believe so yes
<hallyn> what is /proc/pid/status and /proc/pid/cmdline?
<mterry> hallyn, cmdline is system-settings
<mterry> hallyn, status is http://paste.ubuntu.com/8253138/
<hallyn> what is 1439, and what cgrou pis it in?
<mterry> hallyn, 1439 is init --user
<hallyn> hm.  on my laptop that is in proper cgroups (as is unity-settings)
<mterry> hallyn, its cgroup file is similar
<mterry> hallyn, right.  I have two devices next to me, mako and krillin.  Only happening on krillin
<hallyn> is this with the newest upstart?
<mterry> hallyn, this isn't a generic problem
<mterry> hallyn, maybe upstart is related, but I haven't bisected the cause yet
<hallyn> mterry: so as usual i guess i would set /etc/default/cgmanager to cgmanager_opts="--debug",
<hallyn> reboot the device and look at /var/log/upstart/cgmanager.log
<hallyn> look for entries for the user --session pid
<mterry> k
<hallyn> it didn't use to do this right?
<mterry> hallyn, I don't recall no.  Some change happened
<mterry> I just don't know which yet
<hallyn> mterry: can you ssh into the device, cat /proc/self/cgroup there?
<mterry> hallyn, why would ssh matter?
<mterry> hallyn, I must not have followed the --debug instructions right, I don't have /var/log/upstart/cgmanager.log
<mterry> hallyn, /etc/default/cgmanager didn't exist either...
<hallyn> you have to create /etc/default/cgmanager
<hallyn> but, ps -ef | grep cgmanager - is it there?
<hallyn> zul: ok, so qa-regression-testing is failing for me everywhere, so i guess i'll ignore it for now.  Please take your 1.2.8 source, do "quilt pop", copy the add-cgmanager patch from 1.2.6 back in, uncomment that from series, quilt push, quilt ref, quilt push, test-build (should work, did for me) an dpush that.
<hallyn> i'm gonna have to spend more time on qrt itself.  i think virtinst is the problem, but i'm not sure
<hallyn> for instance:
<hallyn> ERROR    internal error: process exited while connecting to monitor: qemu: could not load kernel '/home/serge/.cache/virt-manager/boot/virtinst-linux.is3pnZ': Permission denied
<mterry> hallyn, yes: /sbin/cgmanager --sigstop --debug -m name=systemd
<mterry> hallyn, I did create the /etc/default file
<mterry> with contents: cgmanager_opts="--debug"
<hallyn> then restarting cgmanager by all rights should create /var/log/upstart/cgmanager.log
 * mterry reboots again
<mterry> hallyn, there isn't...  :(
<hallyn> is there /var/log/upstart/cgproxy.log?
<mterry> yes
<hallyn> that's a start...  pb it?
<mterry> hallyn, http://paste.ubuntu.com/8253267/
<hallyn> and now what pid is init --user?
<mterry> hallyn, 1442
<hallyn> can you show a full ps -ejH?
<mterry> hallyn, http://paste.ubuntu.com/8253379/
<zul> hallyn,: ack
<hallyn> speaking of init --user, why do i have like 20 of these running:  lightdm  10268     1  0 Sep03 ?        00:00:00 init --user --startup-event indicator-services-start
<mterry> hallyn, I dunno
<Ampelbein> barry: Hi. A user in #-bugs asked about the SRU of bug 1290847 into trusty. Do you know the current status of this?
<ubottu> bug 1290847 in python3.4 (Ubuntu) "pyvenv fails due to mising ensurepip module" [Undecided,Fix released] https://launchpad.net/bugs/1290847
<barry> Ampelbein: that was dstufft i gather :)
<Ampelbein> Yeah. You two have a history? ;)
<hallyn> mterry: oh, sorry.  so your init --user, does it hit systemd-logind?  That should be the one, i assume talking to cgmanager for you
<mterry> hallyn, btw I tried adding --verbose too, but no luck for cgmanager output
<hallyn> that's really weird
<mterry> hallyn, what do you mean by hit?
<barry> Ampelbein: oh yes :).  we know each other well from the python community.  we were talking earlier today about the sru for that bug.  i suggested he open an sru bug (rather than modifying the above, which he doesn't have perms for) and he said he'd see if someone on #-bugs could help. he's not an ubuntu dev, but he's friendly to the cause :)
<mterry> systemd-logind is running...
<hallyn> i mean does it get spawned by a task that goes through pam, thence through libpam-systemd
<hallyn> what's its pid
<mterry> hallyn, systemd-logind is 1040
<hallyn> that's pretty late
<Ampelbein> barry: I see. I'll see if he's at the keyboard currently and maybe can help him filing the SRU request. Thanks!
<barry> Ampelbein: thanks!
<hallyn> thogh older than lightdm i guess
<Ampelbein> barry: bug 1365728 is the SRU request opened by dstufft.
<ubottu> bug 1365728 in python3.4 (Ubuntu) "SRU: pyvenv fails due to mising ensurepip module" [Medium,New] https://launchpad.net/bugs/1365728
<barry> Ampelbein: thanks!
<doko> mlankhorst, llvm 3.4 final is now in utopic
<mbiebl> kees: hi, did you get the email regarding libseccomp
<kees> mbiebl: hi! I did, though I'm still digging through a giant inbox after weeks of back-to-back conferences. :)
<kees> mbiebl: ultimately, I have no problem with raising the priority, but I would note that libseccomp is not available on all archs.
<mbiebl> kees: hm, thanks for the pointer
<mbiebl> is libseccomp not functional on those particular architectures?
<mbiebl> i.e. ! i386 amd64 armhf armel
<mterry> robert_ancell, poke -- I think lightdm 1.11.8 is causing problems on krillin devices
<robert_ancell> mterry, oh, rsalveti said it was working
<rsalveti> which problems?
<mterry> robert_ancell, rsalveti: I'm seeing that cgroups aren't being set for the user session correctly, so a lot of policykit requests are failing
<robert_ancell> mterry, you have a lightdm.log?
<mterry> robert_ancell, uh hold on just flashed
<robert_ancell> 1.11.7 would have those problems
<rsalveti> right, the issue I had got fixed with 1.11.8
<robert_ancell> So, anyone want to send me a krillin? :)
<mterry>  Interesting.  I'm not seeing the problem with 1.11.7
<robert_ancell> mterry, it was a crash triggered by a race, so you might not have seen it
<mterry> robert_ancell, well the failure is reliable with 1.11.8 (only on krillin)
<robert_ancell> So I suppose your issue is different, though they both sounds related to logind
<siretart> cjwatson: now, they were all straight rebuilds
<siretart> cjwatson: btw, libav now migrated to debian/testing
<robert_ancell> mterry, are you getting a log?
<mterry> robert_ancell, yeah sorry had problems
<robert_ancell> np
<robert_ancell> just checking :)
#ubuntu-devel 2014-09-05
<mterry> robert_ancell, http://paste.ubuntu.com/8254607/
<mterry> worth the wait!
<robert_ancell> mterry, hmm, so that log looks good. There's definitely a logind session open and we activated it
<robert_ancell> mterry, have you tried running loginctl and checking everything looks happy there?
<mterry> robert_ancell, it does yes
<mterry> robert_ancell, it's a cgroup thing as far as I can tell
<mterry> root@ubuntu-phablet:/# cat /proc/`pidof unity8`/cgroup
<mterry> 4:name=systemd:/
<mterry> 3:freezer:/user.slice/user-32011.slice/session-c1.scope
<mterry> 2:cpuacct:/user.slice/user-32011.slice/session-c1.scope
<mterry> 1:cpu:/user.slice/user-32011.slice/session-c1.scope
<robert_ancell> mterry, right, but the cgroups are all set by pam_systemd aren't they?
<robert_ancell> mterry, have you confirmed 1.11.7 works fine?
<mterry> robert_ancell, it does for me yes
<mterry> let me try downgrading on this same image to double confirm
<cjwatson> siretart: right, cool, I'll just keep ploughing through the equivalent rebuilds then ...
 * cjwatson wants binNMUs
<ScottK> +1
<robert_ancell> mterry, can you get a lightdm.log from 1.11.7 so we can diff
<mterry> robert_ancell, yup, downgrading works fine
<robert_ancell> there's just nothing significant in the diff in how we interact with PAM... very odd...
<mterry> robert_ancell, http://paste.ubuntu.com/8254652/
<mterry> and more relevantly:
<mterry> root@ubuntu-phablet:/# cat /proc/`pidof unity8`/cgroup
<mterry> 4:name=systemd:/user.slice/user-32011.slice/session-c1.scope
<mterry> 3:freezer:/user.slice/user-32011.slice/session-c1.scope
<mterry> 2:cpuacct:/user.slice/user-32011.slice/session-c1.scope
<mterry> 1:cpu:/user.slice/user-32011.slice/session-c1.scope
<robert_ancell> mterry, that's on a good run?
<robert_ancell> What does "loginctl session-status $XDG_SESSION_ID" say on a good and bad run
<mterry> robert_ancell, right
<mterry> root@ubuntu-phablet:/# loginctl session-status c1
<mterry> Failed to query ControlGroup: No such interface 'org.freedesktop.DBus.Properties' on object at path /org/freedesktop/systemd1/unit/session_2dc1_2escope
<mterry> c1 - phablet (32011)
<mterry>            Since: Fri 2014-09-05 00:07:59 UTC; 4min 11s ago
<mterry>           Leader: 1439 (lightdm)
<mterry>             Seat: seat0; vc1
<mterry>          Service: lightdm-autologin; type unspecified; class background
<mterry>            State: active
<mterry>             Unit: session-c1.scope
<mterry> that's a bad run
<mterry> Would need to reflash to get good run
<mterry> robert_ancell, like I said, logind thinks everything is fine
<mterry> robert_ancell, the problem is that apps don't think they are part of the active session
<robert_ancell> not sure about "class background"
<mterry> robert_ancell, I don't know what that means either
<robert_ancell> mterry, you can't just update lightdm back to 1.11.8?
<mterry> robert_ancell, oh right!  ahem
<mterry> robert_ancell, I forgot I had downgraded in fact
<mterry> robert_ancell, so this is from a good run
<mterry> let me upgrade again
<robert_ancell> rsalveti, did we confirm if your krillin does the PK stuff right with lightdm 1.11.8?
<mterry> robert_ancell, I'm a little loopy right now
<robert_ancell> no worries
<mterry> root@ubuntu-phablet:/# loginctl session-status c1
<mterry> Failed to query ControlGroup: No such interface 'org.freedesktop.DBus.Properties' on object at path /org/freedesktop/systemd1/unit/session_2dc1_2escope
<mterry> c1 - phablet (32011)
<mterry>            Since: Fri 2014-09-05 00:15:09 UTC; 44s ago
<mterry>           Leader: 1359 (lightdm)
<mterry>             Seat: seat0; vc1
<mterry>          Service: lightdm-autologin; type unspecified; class background
<mterry>            State: active
<mterry>             Unit: session-c1.scope
<mterry> robert_ancell, that's the bad
<mterry> seems identical
<robert_ancell> yeah
<hallyn> will be really curious to see how lightdm could cause it
<robert_ancell> hallyn, if we were setting up PAM incorrectly that would do it, but I can't see any significant change there
<robert_ancell> mterry, could you do a bisect?
<robert_ancell> mterry, also, is it just you or is this widespread?
<mterry> robert_ancell, widespread
<mterry> on krillin
<mterry> robert_ancell, sure, I can bisect... let me get a build env set up for krillin
<robert_ancell> It's got to be either r2037+r2038 or r2041
<mterry> ok, will check those explictly
<mterry> robert_ancell, looks like it wasn't 2041
<robert_ancell> mterry, how's it going with the bisecting?
<mterry> robert_ancell, good but ran into a problem with re-running a debuild without cleaning (didn't seem to like that)
<mterry> robert_ancell, I'm now testing the 2037/2038 commits
<robert_ancell> so to confirm - it works with 2036 (1.11.7) and not 2043 (1.11.8)
<robert_ancell> what other revs?
<siretart> cjwatson: thanks. let me know if you encounter problems!
<cjwatson> siretart: jitsi and lightspark are my undiagnosed failures so far
<mterry> robert_ancell, it does not work with 2040
<mterry> robert_ancell, and I'm testing 2038 now
<siretart> cjwatson: jisti is debian bug #759835
<ubottu> Debian bug 759835 in src:jitsi "jitsi: FTBFS: [javadoc] /Â«PKGBUILDDIRÂ»/lib/src/jsip/src/gov/nist/javax/sip/header/AuthenticationHeader.java:443: error: unmappable character for encoding ASCII" [Serious,Open] http://bugs.debian.org/759835
<mterry> robert_ancell, as expected, 2038 doesn't work either
<cjwatson> siretart: is it?  seems to be a warning in our build ...
<mterry> robert_ancell, is it worth trying 2037 specifically?
<cjwatson> siretart: oh, sorry, apparently I can't read
<robert_ancell> mterry, have you tried a locally built 2036?
<mterry> robert_ancell, yes, it worked
<robert_ancell> you should probably try for completeness, but 2038 is probably the candidate
<siretart> lightspark looks kindof unrelated to libav: /build/buildd/lightspark-0.7.2/src/scripting/abc.cpp:38:36: fatal error: llvm/Analysis/Verifier.h: No such file or directory
<cjwatson> sure, unrelated but nevertheless a blocker
<cjwatson> relatedness is irrelevant if it's in the list :)
<cjwatson> there was a recent llvm change I think ...
<cjwatson> (no details, I just saw it go by in my mirror update)
<robert_ancell> mterry, what method are you using to build on your device? Remount rw then bzr-buildpackage?
<mterry> robert_ancell, uh, I put the device in rw mode sure.  Not remounting each time though
<mterry> robert_ancell, and then debuild sure
<robert_ancell> mterry, you just do a "# mount / -o,remount,rw" to go from a stock image? No other special tricks?
<mterry> robert_ancell, there's a file you can put in  /userdata that makes the image rw on boot
<robert_ancell> ah, what is that?
<mterry> robert_ancell, than I can do normal stuff like apt-get build-dep lightdm etc
<mterry> robert_ancell, uh I think the file is .writable_image, but I usually just run "phablet-config writable-image" from my host device
<robert_ancell> awesome, thanks
<mterry> robert_ancell, do you have a krillin?
<siretart> cjwatson: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-March/071087.html indicates that Verfier.h moved post 3.4 to llvm/IR/Verifier.h
<robert_ancell> mterry, no, I was hoping I might be able to reproduce on mako
<mterry> robert_ancell, I have not been able to myself
<robert_ancell> :(
<cjwatson> siretart: ah, plausible
<robert_ancell> mterry, The only thing I can think of now is to manually start removing parts of r2038 to find out what's actually triggering it.
<mterry> robert_ancell, nothing seems especially suspicious to you?
<siretart> cjwatson: https://github.com/lightspark/lightspark/commits/master/src/scripting/abc.cpp indicates that upstream didn't port it to llvm 3.5 yet
<robert_ancell> mterry, I've been reading through the code here and there's nothing that stands out. We listen to move D-Bus events from logind, we activate sessions slightly differently (but from reading the systemd source both methods should have the same outcome) and we check CanGraphical on the seat. But the logs indicate that's always TRUE in your case so it should be the same behaviour as previously
<robert_ancell> mterry, dmesg doesn't show logind complaining about anything does it?
<mterry> [    9.925763] (1)[1099:systemd-logind]systemd-logind[1099]: New seat seat0.
<mterry> [   11.310221] (0)[1099:systemd-logind]systemd-logind[1099]: Failed to start unit user@32011.service: Unknown unit: user@32011.service
<mterry> [   11.311741] (0)[1099:systemd-logind]systemd-logind[1099]: Failed to start user service: Unknown unit: user@32011.service
<mterry> robert_ancell, but those are normal errors I think
<robert_ancell> yeah, I get them here
<robert_ancell> mterry, I have a "New session c1 of user lightdm." on my desktop, do you get those on a good run?
<siretart> what's going on with llvm in ubuntu? it seems to me that debian testing has both llvm 3.4 and 3.5, whereas ubuntu dropped 3.4 already. why is that?
<mterry> robert_ancell, hold on, testing 2037
<robert_ancell> k
<mterry> robert_ancell, 2037 is good
<robert_ancell> well, that confirms it, 2038 it is
<mterry> robert_ancell, you have that message in your dmesg?
<robert_ancell> mterry, on my desktop
<mterry> robert_ancell, I don't here, even on a good run
<mterry> robert_ancell, ok...  shall I start disassembling 2037?
<mterry> *2038
<robert_ancell> yes please
<cjwatson> siretart: I'll finish uploading the remaining rebuilds tomorrow.  sleep now, night
<cjwatson> I've probably loaded up the buildds enough for a while anyway :)
<siretart> cjwatson: sure, thanks for your help, and have a good night!
<RAOF> robert_ancell: Are you trying to work out why sound doesn't work now? :)
<robert_ancell> mterry, ^?
<robert_ancell> is the symptom no sound?
<RAOF> On the desktop.
<robert_ancell> RAOF, sound works for me..
<RAOF> Maybe you don't VT switch enough :)
<mterry> no that's a separate issue I think :)
<mterry> from this krillin thing
<robert_ancell> RAOF, still works after VT switch
<RAOF> Hm. *Something* was messing with my logind sessions, because I didn't have an X11 session and none of my sessions were marked as active.
<robert_ancell> RAOF, what version of lightdm?
<RAOF> 1.11.8
<RAOF> robert_ancell: ck-list-sessions output: http://paste.ubuntu.com/8255328/
<robert_ancell> RAOF, don't you mean loginctl?
<RAOF> Apparently not :)
<robert_ancell> loginctl show-session to show the current session properties
<RAOF> http://paste.ubuntu.com/8255346/
<RAOF> Well, that's all of them.
<RAOF> Obviously I can't run that command in the failing case :)
<RAOF> Well, not now.
<robert_ancell> RAOF, you're c2 right?
<robert_ancell> That's the active session
<RAOF> Right. I *gained* an active session by running ck-launch-session
<robert_ancell> That would have been c4 - it's the last session added
<RAOF> But it was run on vt7
<mterry> robert_ancell, ah hrm...  I looked in the folder I built my 2038 bisect in, and it wasn't valid -- rebuilding 2038 and it works.
<robert_ancell> mterry, ah
<robert_ancell> mterry, so where does that leave the range of possibilities?
<robert_ancell> RAOF, can you check lightdm --show-config
<mterry> robert_ancell, I no longer have my 2040 folder lying around.  But assuming I did do that one right, either 2039 or 2040 are broken
<robert_ancell> mterry, 2040 was reverted in 2042
<robert_ancell> mterry, and 2039 is only test changes
<mterry> hrm.  Then let me redo my 2040 bisect
<RAOF> robert_ancell: http://paste.ubuntu.com/8255461/
<robert_ancell> RAOF, urgh, how did you get a (null) in there...
<robert_ancell> RAOF, are you in unity8?
<RAOF> No.
<RAOF> Heh. This was after removing a .dpkg-bak file in /etc/lightdm/conf.d that was causing lightdm to segfault on startup... :)
 * RAOF needs to go out and get lunch; back later.
<mterry> robert_ancell, 2040 works too, will try 2041
<mterry> which I'm guessing will fail?
<robert_ancell> that's the guess
<mterry> robert_ancell, OK 2041 seems to work too...  Are the later commits risky?
<mterry> Or am I just screwing up my bisects
<robert_ancell> 2042 is a reversion and 2043 is the release
<mterry> :(
<robert_ancell> is 2043 working now?
<mterry> grr, it better not be
<mterry> robert_ancell, ok 2043 did not work
<mterry> so that's good I guess
<robert_ancell> I guess?
<mterry> Assuming my 2041 test was valid, which I'm not guaranteeing, I'll test 2042 next...  Is that likely to be a problem commit?
<mterry> You indicated no
 * mterry is beginning to doubt his ability to bisect
 * mterry tries 2041 again -- that really should be the problem commit
<robert_ancell> mterry, how goes 2041?
<mterry> robert_ancell, it was good again
<mterry> robert_ancell, trying 2042 for the lulz
<robert_ancell> mterry, do you have all the packages built so you can easily switch between?
<mterry> robert_ancell, I unfortunately have been building the .debs over each other.  But I have the build directories sitting there so could regenerate debs in relatively shorter order
<mterry> robert_ancell, and 2042 predictably fails (if it worked and 2043 failed, I'd just give up)
<mterry> robert_ancell, so assuming my 2041 tests have been valid, and I did redo it...  That means 2042 is the problem
<robert_ancell> that makes no sense
<mterry> robert_ancell, I do see something about add_login1_seat in that commit...  any chance that is odd?
<mterry> s/odd/buggy/
<robert_ancell> 2042 = "Revert globbing changes - there are problems with it"
<mterry> right... so we're going back to historical behavior
<robert_ancell> only has changes in src/lightdm.c regarding configuration loading
<robert_ancell> And they only relate to multi-seat anyway, which is not being used on krillin
<mterry> robert_ancell, :(
<mterry> robert_ancell, so I'm guessing I mis-tested 2041...  twice
<robert_ancell> mterry, does repeated runs have the same result?
<mterry> robert_ancell, it always has in the past
<robert_ancell> mterry, So to summarise: LightDM 1.11.8 is breaking PolicyKit on krillin, but not mako. 1.11.7 doesn't break PolicyKit on krillin, but does have a race-conditn triggered crash. The bisect it indicating r2042 could cause the problem, but it doesn't make sense. There's been some inconsistency in the bisecting
<robert_ancell> I should also say "not mako or desktop"
<mterry> robert_ancell, the inconsistency in the bisecting so far was just me building the wrong revisions -- not actual inconsistencies in results observed -- i.e. so far each revision has exhibited reliable behavior
<mterry> I think
<mterry> robert_ancell, I take that back -- I built the same 2041 deb and this time it is broken
<mterry> so maybe I need to do more reboots before declaring a given revision as "clean"
<robert_ancell> I have to head out soon, and you must be almost falling asleep. What do you think we should do?
<mterry> I'll go back and test the 2040 revision
<mterry> robert_ancell, I think the likely culprit is 2041 -- but if this problem isn't 100% reproducable, I need to retest my older bisects
<mterry> robert_ancell, but my 2041 test has proven that the problem existed in at least 204
<mterry> 2041
<mterry> even if it doesn't always show up
<mterry> robert_ancell, I am about to fall asleep, so I'm going to bed.  I can continue testing tomorrow.  But I'm not sure I'm qualified to fix it, especially since I don't have the context for the original 2041 commit
<robert_ancell> mterry, 2041 is the fix for bug 1364725
<mterry> robert_ancell, and it's tough for you to investigate without a krillin
<ubottu> bug 1364725 in lightdm (Ubuntu Trusty) "logind session ID not used due to race condition" [High,In progress] https://launchpad.net/bugs/1364725
<robert_ancell> yeah, I'm just guessing here
<mterry> robert_ancell, so I can continue tomorrow and work on it myself
<mterry> robert_ancell, but if you have any guesses, email them to me and I can try
<robert_ancell> mterry, an option is trying r2040.1.1 which is the sticking plaster solution to the above bug instead of the proper solution in r2041
<mterry> robert_ancell, OK, will try that tomorrow
<robert_ancell> mterry, thanks for staying up. bye
<mterry> but first I should probably stress test r2040 itself to make sure that it doesn't exhibit the bug
<mterry> it's annoying that it creeped back
<mterry> I thought it was always reproducable
<mterry> anyway, bye
<pitti> doko_: pgrouting> ah right; thanks for the sync
<pitti> doko_: I'll sort out postgis
<pitti> doko_: I wedged the mysql-5.5 result for gcc-4.9, will go in now
<pitti> (new mysql-5.5 version itself will still stay in -proposed)
<dholbach> good morning
<mlankhorst> morning
<mlankhorst> doko_: don't you mean llvm 3.5 final?
<robert_ancell> RAOF, who is the nvidia person who I should subscribe bug 1365336 to? And which package collects nvidia issues?
<ubottu> bug 1365336 in lightdm (Ubuntu) "Lightdm update=No desktop" [Undecided,Confirmed] https://launchpad.net/bugs/1365336
<robert_ancell> It has some udev rules to make nvidia cards work with logind and CanGraphical
<dholbach> zul, lamont: happy birthdays! :)
<seb128> robert_ancell, try tseliot or mlankhorst
<mlankhorst> alberto milone
<seb128> robert_ancell, did you figure out/resolve that "lightdm not working" issue that started this week? I saw a few people mentioning it, including kenvandine
<robert_ancell> seb128, there seem to be a few issues
<seb128> seems sil2100 might have issues as well (but I missed the start of the irc discussion so just assuming there)
<seb128> robert_ancell, ken said lightdm failed to start (or start a session) where gdm is working
<seb128> that was yesterday
<robert_ancell> need bugs and information...
<seb128> the bug you just listed doesn't have info?
<robert_ancell> seb128, that one does, don't know if they have the same issue
<seb128> k
<sil2100> Not sure if my bug is related
<sil2100> Since I get Unity launching, I can see that I can actually do stuff on it (as the mouse cursor changes and such), but nothing refreshes the screen
<sil2100> i.e. Unity always stays like a screenshot
<sil2100> If I restart unity I can see the new changes, like Nautilus or terminals that I open, but it hangs again and nothing refreshes
<sil2100> Even though I clearly am able to move around the windows that I open (as per cursor)
<Saviq> ogra_, no mtp (or adb for that matter) on boot latest mako, had to toggle developer mode back'n'forth, that expected?
<Saviq> ogra_, is passlock required for mtp?
<ogra_> Saviq, only for adb
<Saviq> ok yeah, no mtp here
<sil2100> I didn't see anything useful in logs though...
<ogra_> Saviq, i'm just writing an announcement mail :)
<Saviq> ogra_, maybe hold off on that :D
<ogra_> Saviq, ??
<Saviq> ogra_, I've dev mode enabled (even though I have no passcode... so can't disable)
<Saviq> ogra_, mtp nowhere to be seen
<ogra_> why would one have anything to do with the other ?
<ogra_> is mtp-server running ?
<ogra_> also what device ?
<Saviq> ogra_, now I added passcode, disabled devmode, MTP up
<Saviq> ogra_, mako r223
 * Saviq reboots
<Saviq> ogra_, the problem seems to be that you can disable passcode without disabling devmodwe
<Saviq> devmode
<ogra_> Saviq, known bug
<ogra_> next on my list
<Saviq> ogra_, that results in no mtp or adb
<Saviq> kk
<ogra_> mtp shouldnt be affected at all, could you file a bug ?
<Saviq> ogra_, yeah, will do, against what?
 * ogra_ needs to see if he can reproduce that 
<ogra_> Saviq, heh, good question, thats most likely the gadget driver itself (property settings)
<ogra_> start with dbus-property-service ... not really accurate but the closest i can think of
<sil2100> I'll be in the meeting in a moment, just need to fetch the HO link
<Saviq> ogra_, devmode toggles on for me on reboot...
<Saviq> ogra_, yeah, I can't seem to disable devmode so that it would stick across a reboot...
<ogra_> Saviq, yeah, thats still hardcoded until we have found all issues
<ogra_> (the boot toggle)
<Saviq> ogra_, so it's always enabled on boot, that explains things...
<ogra_> yeah, that needs a change on the android side
<ogra_> which will be the very last step in landing this
<Saviq> kk
<Saviq> ogra_, bug #1365911
<ubottu> bug 1365911 in dbus-property-service (Ubuntu) "MTP not working on boot if passcode not set" [Undecided,New] https://launchpad.net/bugs/1365911
<ogra_> thanks
<rbasak> infinity: I tried a dist-upgrade from my (now built) PPA with C/R today. That wants to also remove mysql-server :-(
<rbasak> infinity: so I don't see any way to make progress on this now, save for uploading and keeping the window for processing NBS short, and telling people caught in that window to re-install mysql-server manually again.
<jamespage> doko: my latest mysql-5.5 upload should resolve the autopkgtest failure
<jamespage> hopefully that unblocks your stuff
<jamespage> rbasak, mysql-5.6 is suffering from the same problem as mysql-5.5 - are you planning an upload?
<rbasak> jamespage: yes. I'll cherry-pick your patch shall I?
<jamespage> rbasak, yes please - I'm also looking at the main.ctype_uca failure - seems it does not like running as a non-root user
<rbasak> jamespage: I'm not sure about the dep8 test failures for 5.6 though. They failed previously though, so I didn't see it as a regression to prioritise the migration first.
<rbasak> jamespage: I'm also doubtful about the benefit they provide anyway, since they're not package integration tests.
<jamespage> rbasak, there are three - my patch resolves two of them
<jamespage> rbasak, I'd suggest we skip the ctype_uca test for now in the autopkgtests - it wants to write a file to the CHARSETSDIR which bad
<rbasak> jamespage: do I want fix-func_math-test-failure.patch for 5.6 in Ubuntu?
<rbasak> Just noticed a merge conflict in series.
<rbasak> (hence I'm wondering)(
<rbasak> and fix-mysqlhotcopy-test-failure.patch doesn't apply either :-/
 * rbasak investigates
<jamespage> rbasak, lemme push it to the debian git repo - you can pick from there if you like
<rbasak> Thanks
<jamespage> rbasak, ok - added three commits - http://anonscm.debian.org/cgit/pkg-mysql/mysql-5.6.git/log/
<rbasak> (hence I'm wondering)(r 5.6?
<rbasak> Argh
<rbasak> jamespage: ah, so dep8 tests now pass for debian on 5.6?
<jamespage> rbasak, testing now but they should I think
<rbasak> Nice. Thanks!
<jamespage> rbasak, they don't get run anywhere automatically right now due to being in experiemtnal only
<rbasak> I'm still not convinced we want them at all though. If the tests being run on package build are different, can we shove this test run into the build also?
<rbasak> Or would regressions in dependencies actually cause a test failure?
<jamespage> rbasak, they do indeed cause failures - the hotcopy ones where due to the perl 5.20 bump
<rbasak> Fair enough
<rbasak> That's enough for me.
<jamespage> rbasak, I don't think you need the func_math one with mysql-5.6 - can't see that failing
<rbasak> OK
<rbasak> jamespage: Bjoern applied my apport patch to Debian. Is that right, or is that an issue?
<rbasak> Makes it easier for me in Ubuntu mind.
<jamespage> rbasak, he did indeed
<rbasak> Also it's all flattened into one commit? :-/
<rbasak> I suppose it does no harm to install something into /usr/share/apport/package-hooks/ into Debian. I don't know if that's really allowed though.
<ogra_> Saviq, your mtp issue will be fixed in the next image ... fix uploaded
<jamespage> rbasak, hrm yes it is
<jamespage> rbasak, I was justing thinking about that
<jamespage> its pretty easy to scope that to derives-from ubuntu
<rbasak> Yeah that would work well.
<rbasak> And then there's the postinst debhelper change, which I was just a little concerned about for Debian and SysV. I don't know the implications, since there was presumably a reason it was removed in the first place.
<jamespage> rbasak, let me make that change
<rbasak> jamespage: please do. It looks like I can just upload from Debian VCS then, or sync if you upload to experimental.
<rbasak> (when we're ready)
<rbasak> There's still this upgrade path question for infinity, but I don't see that as a problem in experimental.
<rbasak> jamespage: oh, one more thing though. infinity said that Conflicts/Replaces is more correct than Breaks/Replaces here. I checked each Breaks and they all should be changed to Conflicts. I've done that in my PPA, but that needs committing to Debian, too.
<jamespage> rbasak, how does this look - http://paste.ubuntu.com/8258806/
<rbasak> jamespage: that looks fine. I wouldn't include the unrelated noise in 21/22 in that commit, but it doesn't matter.
<rbasak> jamespage: also, shouldn't the tag line in 11 change? Again, doesn't matter.
<jamespage> rbasak, nah - team upload
<rbasak> OK
<jamespage> not released yet - that can still change tho
<jamespage> rbasak, will use of Conflicts break the swap out variants stuff?
<infinity> rbasak: I disagree that you changed all your relationships.
<infinity> rbasak: mysql-client-core-5.6 has no Conflicts, only Breaks.
<infinity> rbasak: And if you run the upgrade with "-o Debug::pkgProblemResolver=true", you can see that's where it starts to fall down.
<infinity> jamespage: "Swap out variant stuff"?
<infinity> jamespage: Fundamentally, nothing has changed here as far as co-installability.  YOu had unversioned Breaks (usually a sure sign you're doing something wrong), so those packages couldn't be co-installed anyway.
<infinity> jamespage: But all those virtuals should be C/P/R, not B/P/R, and the straight upgrades should be C/R, not B/R
<jamespage> infinity, no - co-installability was not supported, but installing say mariadb-server would swap out mysql-server automatically
<infinity> jamespage: This won't make anything worse.  Doing it right will make some things better, though.
<jamespage> infinity, OK - nice to have another pair of eyes on that stuff
<infinity> rbasak: So, yeah, your claim that you changes all the Breaks to Conflicts in your PPA is a blatant lie, from the PPA I'm testing. ;)
<infinity> rbasak: Which would explain why it no workie.
<infinity> Or, at least, would be one of the reasons.
 * rbasak looks
<rbasak> infinity: https://launchpadlibrarian.net/184032264/mysql-5.6_5.6.19-1~exp1ubuntu1~dev3_5.6.19-1~exp1ubuntu1~dev4.diff.gz
<infinity> Oh, wait, there's three versions published in here.
<infinity> THAT'S NOT CONFUSING ME AT ALL.
<rbasak> The changelog is wrong mind, since it didn't fix it. But I didn't know that when I uploaded.
<rbasak> I thought older versions got superceded?
<rbasak> https://launchpad.net/~racb/+archive/ubuntu/experimental/+packages only shows me the latest.
<infinity> If anything went NBS, they'll stick around.
<rbasak> Oh
<infinity> Plus, things stick around for a short while regardless.
<rbasak> I'd never considered NBS inside a PPA before.
<rbasak> They're sort of hidden from the web view.
<infinity> Anyhow, I think I need to unwind this (and maybe tag-team with mvo) when I'm more awake.
<rbasak> OK
<rbasak> Do you mind extending your FFe deadline in the bug though, please?
<infinity> But if I don't get to anything interesting by Monday, let's opt for uploading something that's mostly correct and make sure we sort it before release.
<infinity> Feel free to copy and paste the above. :P
<rbasak> OK, thanks.
<rbasak> I will check again, but I believe it'll be sorted by release just by processing NBS.
<jamespage> rbasak, oh - we need to fix the arm64 build failure for 5.6 as well
<jamespage> well workaround it at least
<rbasak> Maybe drop to -O1 for arm64 universally? Probably easier than messing with the buildsystem to pick out one file.
<cjwatson> I noticed recently that it's possible to fiddle with optimisations on a per-function basis
<jamespage> rbasak, yes - that was my thinking but if we can apply something like cjwatson suggests that might be nice
<rbasak> Ah, so patch in a #if defined(arm64) #pramga?
<infinity> rbasak: No, "just processing NBS" doesn't magically make the bug go away.  It's not actually entirely uncommon for people to have multiple releases in sources.list, and we certainly don't stop people from doing so.
<rbasak> It'll be annoying to test though. I don't have access to an arm64 machine right now.
<cjwatson> __attribute__ ((optimize ("O1"))
<rbasak> infinity: OK. I didn't think that case was one that we considered. If we do, then I guess we need to dig further.
<cjwatson> or __attribute__ ((optimize ("no-tree-dce"))) or whatever
<rbasak> Thanks cjwatson
<cjwatson> (oh yes I missed a ")" off my previous example)
<infinity> rbasak: Well, define "we".  Some people don't, some people do.  It's a bug if that breaks, but probably not as horrendous a bug as not being able to upgrade at all.
<infinity> rbasak: But, more to the point, anything that breaks like that is also either a sign of messy dependencies that make apt think too hard, or an apt bug, and the latter would want fixing, while the former should be made less scary to not make upgrades needlessly complex.
<infinity> (Cause the more complex you make an upgrade, the more likely you are to have things like this happen)
<rbasak> OK, that makes sense.
<infinity> The curious thing in a debug run is that it gets the first couple of swaps right, then starts choking.  So, it needs a closer look.
<infinity> Which I'll try to get to when I'm not asleep.
<rbasak> Given the binary package structure we have at the moment, I'm not sure how to declare things any better or in a way that would fix things without being wrong. So I'll wait for you to take a look.
<rbasak> It may be that the set of binary packages we have is needlessly complex (I think it is, anyway), but I'd like some justification to start messing with it (and it's extra work).
<infinity> I'm curious why you suddenly sprouted a new mysql-common-N.N package.
<rbasak> That's one thing I can get rid of.
<rbasak> It's because mysql-common was previously provided by src:mysql-5.5.
<rbasak> (I presume; I didn't do it).
<rbasak> The mysql-common package is pretty broken in itself IMHO. I don't think it makes sense for a single binary package from one variant's source package to be providing a my.cnf for all variants' packages.
<rbasak> The variants shouldn't be sharing the same /etc/mysql either, IMHO.
<rbasak> It's a mess.
<infinity> It is indeed.
<infinity> But even weirder to still have both the unversioned and versioned one when you're taking over the former.
<infinity> So, I assume you want that to become just mysql-common
<infinity> And drop -5.6
<rbasak> Yes. I can do that.
<rbasak> I was trying to address this, but with release timing it seemed easier to drop 5.5 and reduce the complexity that way first.
<infinity> I doubt that'll magically make apt happy, but any subtle change in dependencies (and this would drop a dep) might help. :P
<rbasak> So I was trying to do the minimal thing to get the 5.6 move done without messing with the other pieces at the same time.
<infinity> Well, you're messing the the other pieces anyway...
<infinity> You're taking over mysql-common.
<infinity> *and* shipping a new mysql-common-5.6 that depends on it.
<infinity> Which is weird.
<rbasak> Sure. I was just going for the minimal change.
<rbasak> If you think it might help, I'll fold the two packages together as well.
<rbasak> I'll experiment now.
<infinity> Doesn't actually matter if it'll help or not (though that would be nice), let's not upload half-finished stuff. ;)
<infinity> Take those packages over with purpose and zeal.
<rbasak> I see fixing up mysql as a multi-release gradual improvement. I don't think it's feasible to do it all at once.
<rbasak> There's some debate in Debian over the best way to do this as well, because all the other variants are tangled up in it (since they depend on mysql-common)
<rbasak> And so there are other maintainers involved.
<rbasak> Hence the glacial pace.
<infinity> rbasak: Also, I'm sure you have done this, but can you be explicit in the bug as to how you've made sure upstream didn't break ABI in their supposedly-the-same SONAME library?
<infinity> rbasak: Maybe Debian's yelled at them enough over the years and they get it now, but they've broken ABI a few times in the past without bumping.
<rbasak> infinity: I just believed them. I'll ask upstream to comment in the bug confirming it.
<infinity> rbasak: Well, or actually run an ABI checker against the libraries.
<rbasak> infinity: can you point me to a tool? Happy to do that, but I should ask as presumably ABI can break even if no symbols have disappeared?
<rbasak> Or is there a tool that can check prototypes from the source also? Though that will has the same catch.
<infinity> rbasak: Symbols can remain but argument sizes/positions can change, for example.
<infinity> rbasak: xnox gave a talk about this at Debconf actually. :P
<infinity> rbasak: IIRC, abi-compliance-checker is the tool he was recommending for checking both binaries and headers.
<rbasak> Thanks
 * infinity decides to try harder to sleep, starting with not typing.
<cjwatson> siretart: I'm working around the lightspark thing
<mterry> jamesh, hello!  How can I get debug output from upstart itself about job timings and such?
<cjwatson> siretart: also working on jitsi, so that's all the build failures I currently know about
<jodh> mterry: Run upstart with --debug' (or 'initctl log-priority debug' for an already booted system). However, Upstart doesn't keep timestamp information itself. But pid 1 uses kmsg so dmesg. For session init jobs, try 'sudo apt-get install upstart-monitor && upstart-monitor -n'. Alternatively, just listen for the D-Bus EventEmitted signal yourself and timestamp their receipt.
<mterry> jodh, thanks!
<mterry> jodh, I guessed wrong on what your nick was  ;)
<pitti> rbasak, jamespage: FTR, apport is in Debian as well, so I don't think it's a really bad thing to install hooks in Debian
<rbasak> Ah, I didn't realise that. Thanks!
 * rbasak wonders if the hook itself is Ubuntu-specific though
<jamespage> pitti, awesome
<mterry> jodh, I'm trying to monitor bootup sequencing, how do I pass --debug to upstart on boot?
<jamespage> rbasak, reverted that commit
<jodh> mterry: add --debug to the kernel command-line via the bootloader
<mterry> jodh, fair enough, thanks!
<jodh> mterry: what specifically are you trying to do?
<mterry> jodh, there is some race between lightdm and *something* which triggers on krillin but not on mako.  I'm trying to see if it's an upstart job (though I think it may be a dbus-activated issue)
<jodh> mterry: is there an bug number?
<mterry> jodh, bug 1365095 righ tnow
<ubottu> bug 1365095 in unity8 (Ubuntu) "Greeter not asking for pin code in image 11 (krillin)" [High,Confirmed] https://launchpad.net/bugs/1365095
<pitti> jamespage: "error 9,11,2304,255" -- strangest error code list ever :)
<pitti> jamespage: thanks for fixing mysql!
<jamespage> pitti, np and yes its odd
<mterry> hallyn, hello again!  So remember my cgroup oddity from the other day?
<mterry> hallyn, still having problems, but now I've traced it down to a possible race with lightdm...
<lagzilla> Sorry is this is the wrong place to ask but I can't seem to find it on google. Where can I find the build flags used to make the bind9 package.
<pitti> lagzilla: the build log should provide a good first start: https://launchpadlibrarian.net/174230080/buildlog_ubuntu-utopic-amd64.bind9_1%3A9.9.5.dfsg-4_UPLOADING.txt.gz
<pitti> lagzilla: from https://launchpad.net/ubuntu/+source/bind9 -> current version -> architecture of your choice -> "build log"
<pitti> lagzilla: otherwise you see the package specific flags in debian/rules (after apt-get source bind9)
<pitti> lagzilla: i. e. the flalgs which are different from the defaults (call dpkg-buildflags to see those)
<lagzilla> pitti: Thank you!!
<LocutusOfBorg1> cjwatson, may I ask you something?
<cjwatson> just ask, don't ask to ask
<LocutusOfBorg1> can you please instead of rebuilding hedgewars for libav11 just sync from debian?
<hallyn> mterry: so when you login, exactly what is it that calls pam to setup login session?  is it the init --user?  is it lightdm?
<mterry> hallyn, lightdm does that
<LocutusOfBorg1> the two changes between the utopic verion are: enable --parallel switch, patch cmake to work with cmake 3.0 (two " " added)
<LocutusOfBorg1> it will build I hope in less time, and with cmake 3.0 compatibility
<cjwatson> LocutusOfBorg1: sure, done
<LocutusOfBorg1> thanks
<LocutusOfBorg1> I hope in the next release when I'll upgrade to utopic to install cmake 3.0
<hallyn> mterry: I assume this is an autologin?  Is there a way to logout and log back in?
<mterry> hallyn, not really no, Touch just does one autologin the whole time
<hallyn> mterry: i saw you were bisecting last night - can you paste a debdiff of the last good and first bad?
<hallyn> mterry: does sleeping 10 secs before doing the actual login make a difference?
<mterry> hallyn, yes, sleeping for 5 seconds before running the session command fixes it.  *but* sleeping for 5 seconds before launching lightdm does not
<mterry> in the upstart job
<mterry> hallyn, http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/revision/2041 is the troublesome commit
<hallyn> so you mean 5 seconds before calling or at top of session_set_pam_service?
<mterry> hallyn, we think the change in session-child.c to not call a dbus command changed the timing enough to expose this problem
<hallyn> mterry: one thing to possibly try would be to create an upstart job to start systemd-shim, start on starting lightdm
<mterry> hallyn, in that diff, I added sleep(5) to where we get the XDG_SESSION_ID var from pam
<hallyn> thx looking at the diff
<mterry> hallyn, but pam-systemd would start logind and all that shim stuff, right?
<pitti> smoser, jamespage: hm, I just noticed that our cloud images still use grub-legacy? I tried to change kernel params in /etc/default/grub and /etc/default/grub.d/50-cloudimg-settings.cfg, but they still don't become active in /boot/grub/menu.lst
<pitti> smoser, jamespage: what's the appropriate place to set them?
<pitti> apparently update-grub doesn't update menu.lst from the files above
<cjwatson> smoser,jamespage: speaking of which, pv-grub2 is making progress again, see #759018
<cjwatson> er that's Debian #759018
<ubottu> Debian bug 759018 in src:grub2 "please provide prebuilt grub-xen binaries for host (dom0) use" [Wishlist,Open] http://bugs.debian.org/759018
<hallyn> mterry: in login.c, could you add a sanity check to make sure that session->priv->login1_session and console_kit_cookie are right?
<cjwatson> so hopefully we'll eventually be able to actually use that :)
<hallyn> i dunno that's reaching tough
<pitti> smoser, jamespage: I tried to call update-grub-legacy-ec2 explicitly and that also said "Updating /boot/grub/menu.lst", but apparently still doesn't take GRUB_CMDLINE_LINUX_DEFAULT into account?
<mterry> hallyn, the values are right in the child session at least
<mterry> hallyn, I checked /proc/pid/environ
<jamespage> pitti, I'd defer to smoser or utlemming - this is more their area if expertise!
<pitti> jamespage: ah, thanks
<pitti> smoser, utlemming: it seems that menu.lst doesn't even have the options that we set by defualt -- console=tty1 console=ttyS0 ?
<mterry> hallyn, systemd-shim isn't a job?
<pitti> mterry: it's d-bus activated
<mterry> pitti, what does it do different from logind or whatnot?
<pitti> mterry: I'm not sure it's sensibly comparable to logind; but it only offers a D-BUS API and doesn't need to run all the time, so D-BUS activation seems fine?
<mterry> pitti, sure I'm just trying to figure out whether it might be related to my problem.  not sure what it did
<pitti> mterry: it mostly just translates requests like "start unit suspend" or "create a cgroup" into calling "pm-suspend" or cgmanager
<mterry> pitti, ooh...  that cgroup thing sounds related
<pitti> mterry: so if you look for it, it shouldn't run most of the time (it times out after 10 s of not talking to it)
<hallyn> pitti: not for long :(
<pitti> mterry: so you'll only see it on new logins (or logouts), or suspend/resume etc.
<mterry> hm.  but if it's dbus-activated, I'm not sure what the timing issue would be
<hallyn> mterry: it'd be a bug in logind or libdbus i guess, not waiting unti lit actuall starts up to return a nerror
<hallyn> mterry: what is v2 of the login protocoal?
<pitti> hm, we've been using d-bus activation for years with tons of stuff; quite unlikely that d-bus activation still has such blatant bugs
<pitti> systemd-shim could of course still have bugs, the cgmanager integration is still rather new
<hallyn> seems to demand extra newlines.
<pitti> only a few days ago there was a race condition between lightdm starting earlier (or too early) than cgmanager; stuff of that sort
<mterry> hallyn, v2 returns both logind and consolekit cookies, rather than just the appropriate one
<mterry> hallyn, one of which is now always NULL
<pitti> wow, are we still concerned about CK?
<mterry> pitti, lighdm is
<pitti> ah, interesting
<hallyn> pitti: looking at the process table yesterday cgmanager and cgproxy definately started before lightdm on the bad krilin system
<pitti> right, that shoudl work now
<hallyn> but, the cgproxy.log doesnt' show any requests on behalf of lightdm
<hallyn> might rebuild libpam-systemd with some introspection (fprintfs :) added to see if it's being called at all
<pitti> have you tried modifying /etc/pam.d/common-session to append "debug=true" to pam_systemd.so?
<pitti> then you get some nice debugging in /var/log/auth.log
<ogra_> if i use dh_installudev in debian/rules and have multiple packages, does the order of the dh_installudev commands matter ? (i.e. if the generic one comes last will it override the named ones above ?)
<pitti> ogra_: you mean you call it with different -p options?
<mterry> pitti, good point, will try that
<pitti> order shouldn't matter at all
<ogra_> verride_dh_installudev:
<ogra_>         dh_installudev --name=android-tools-adbd --priority=98
<ogra_>         dh_installudev --priority=70
<ogra_> pitti, like that
<ogra_> oh, crap
<pitti> ogra_: ah; still,order shouldn't matter at all, as long as the files are named correctly
<ogra_> indeed i did use --name not -p
<pitti> ah :)
<ogra_> hmm
<rbasak> infinity: I've folded mysql-common-5.6 into mysql-common now, but apt still wants to remove mysql-server :-(
<ogra_> it doesnt know -p
<pitti> ogra_: then you should call the other with -Nandroid-tools-adbd
<ogra_> according to the manpage
<pitti> ogra_: or --remaining-packages
<pitti> ogra_: otherwise the second command will install debian/android-tools-adbd.rules again with prio 70
<pitti> ogra_: as by default it acts on all pacakges
<ogra_> pitti, right, it ends up with 70 currently
<pitti> ogra_: right, so in that regard the order matters, if you install a rules several times with different prio
<mterry> hallyn, pitti: yeah libpam-systemd is being called, can see the output in auth.log.  I mean, it was returning the correct XDG_SESSION_ID to lightdm already.  Logind thinks everything is fine, the session is active, etc.  No problem with logind.  It's just that the session doesn't have proper cgroup paths defined, they are all the root path
<smoser> pitti, update-grub-legacy-ec2 does not do that.
<smoser> and i wouldn't plan on it doing that.
<pitti> smoser: yeah, I just tried it as the usual update-grub didn't
<smoser> it *should* correctly allow you to edit /boot/grub/menu.lst
<smoser> the way things used to work with grub 0.97
<pitti> smoser: ah, so I'm supposed to edit that file directly?
<smoser> i think that file has information in it on how to update it
<smoser> its "legacy"
<hallyn> mterry: can you build a version of systemd-shim with the src/cgmanager.c call to cgmanager_call("RemoveOnEmpty") commented out?
<smoser> but it should behave the same way grub 0.97 did. ie, what was that , prior to lucid ?
<pitti> smoser: ok, WFM, thanks; sorry, I have completely forgotten how grub-legacy works, it seem s:/
<LocutusOfBorg1> have a nice weekend
<pitti> smoser: I'll do that then
<pitti> smoser: it's nothing permanent anyway; I'm writing tests for booting with systemd as init
<didrocks> hey barry, do you need any help for nose-cov? (I can ship the file if you +1 on it)
<barry> didrocks: you'd be shipping an init_cov_core.pth file in nose-cov?  that doesn't seem right.  would you mind filing a bug on cov-core in debian describing the issue?  i will take a look at it and test it when i do a cov-core update, and i will try to get to that today
<didrocks> barry: sorry, I meant cov-core actually. I can open a bug, sure
<barry> didrocks: awesome, thanks
<bdmurray_> slangasek: Did you setup a test for whoopsie with daisy.staging.ubuntu.com?
<didrocks> yw!
<mterry> hallyn, yeah ok I could try that
<slangasek> bdmurray: I didn't
<mterry> hallyn, didn't help
<slangasek> bdmurray: is that something you were expecting me to do, or did somebody do this and you're trying to figure out who?
<hallyn> mterry: mterry or maybe build with http://paste.ubuntu.com/8260445/   (so we can also see if it's getting called)
<hallyn> mterry: oh.  ok, well that's good on the one hand, at least we know it's not that race again
<mterry> hallyn, shall I try that debdiff still?
<hallyn> mterry: yeah, and then pastebin /tmp/debug and ps -ef output so we can check whether shim is being called to set the cgroups
<bdmurray> slangasek: I was thinking of this https://code.launchpad.net/~vorlon/ubuntu-test-cases/better-whoopsie-testing/+merge/229152
<didrocks> barry: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760583 FYI
<ubottu> Debian bug 760583 in cov-core "cov-core should ship the generated .pth file to enable subprocess coverage tracking with nose-cov" [Normal,Open]
<mterry> hallyn, http://paste.ubuntu.com/8260524/
<mterry> hallyn, those cgroup paths look right!
<mterry> hallyn, so... process 1450 has the right cgroup paths
<mterry> hallyn, but the session it spawns (init --user) does not
<barry> didrocks: got it
<barry> let me work on that now
<didrocks> thanks :)
<mterry> hallyn, the session is created by a fork() in that same function I mentioned adding a sleep(5) to earlier
<mterry> hallyn, is process 1450 granted the cgroup info after the fork?
<mterry> hallyn, how does cgroup assignment work?
<mterry> hallyn, I don't even know where the call to the shim to create the cgroup is made...
<slangasek> bdmurray: oh - /that/ test, yes, I did point the smoketesting at staging, sorry
<bdmurray> slangasek: was it ever merged though?
<slangasek> bdmurray: hmm - it was merged somewhere, but that MP suggests that the target branch is some ancient thing
<mterry> pitti, can you explain a little bit about who calls the shim for cgroup stuff?  I'm confused on when/where cgroups are created
<pitti> mterry: logind calls shim's (or systemd's) StartTransientUnit() which creates a new group, and then that contains the new session
<pitti> mterry: I don't know much detail about that though, that'd be desrt or hallyn
<slangasek> bdmurray: so it was merged, but I think someone rearranged the branches
<mterry> pitti, ah...  ok thanks
<desrt> hi :)
<slangasek> bdmurray: apparently the new branch target is https://code.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch
<mterry> desrt, hello!  I'm investigating some race we have with lightdm and cgroups....  let me do a little investigation first
<desrt> mterry: can you ping again in half an hour or so?  in a meeting....
<slangasek> bdmurray: but my change isn't merged there either.  so I really don't know what happened here
 * pitti waves good bye, enjoy the weekend everyonr
<mterry> desrt, sure!
<mterry> pitti, bye!
<mterry> hallyn, so yeah...  "cgroups being set for the process" racing with the fork() call fits the facts...  any ideas if that's possible?
<tedg> hallyn, Do you have a reviewer for the systemd-shim MR?
<hallyn> mterry: that really shouldn't be possible. pam should be synchronous
<mterry> hallyn, yeah looking at all the logind calls into cgmanager, it certainly seems all sync
<mterry> hallyn, is some part of our cgmanager daemon async?
<hallyn> mterry: only removeonempty
<hallyn> jodh: ^ is it possible that 'init --user' spawned by lightdom as phablet user could be doing a movepidabs?
<hallyn> I only see one such call, in init/cgroup.c:cgroup_create,
<hallyn> and it only does it if ! user_job
<hallyn> so is that considered a user job?
<hallyn> (but really, why would that change with lightdm version?)
<jodh> hallyn: only system-level cgroup jobs do that, so no.
<hallyn> yeah that cna't be it
<hallyn> so something in that lightdm delta must be changing the synchronous flow
<mterry> hallyn, well the lightdm change just affected the timing we think
<hallyn> so that the fork is happening before the call to pam_session_init
<mterry> hallyn, like I said, if I add a sleep(5) it goes back to working behavior
<mterry> hallyn, pam_start is called far before the fork
<hallyn> but yo uput the sleep at the top of pam-start right?  not the fork?
<hallyn> is it always the case that lightdm --session-child is in the right cgroup and init --user is not?
<mterry> hallyn, I can test more
<mterry> hallyn, I put the sleep between pam_start/pam_open_session and the fork
<hallyn> mterry: ok so I guess I haven' tlooked at that part of the logind code itself.  pam itself should be completely synchronous, and shim and cgmanager in that part are.  But i guess i'ts possible that logind sets everything else up, queues a task to do the dbus call to shim, and immediately returns
 * hallyn goes to look
<mterry> hallyn, the seemingly most relevant code is in src/session-child.c
<mterry> hallyn, certainly seems like the session-child/init cgroup delta is consistent (when the problem occurs -- it's not 100% consistent)
<hallyn> mterry: no, src/login/logind-dbus.c:manager_start_scope() blocks on the return from StartTransientUnit, so that's not it
<hallyn> (that is, no, logind is not th eprolbem)
<bdmurray> plars: how can we get this merged / going? https://code.launchpad.net/~vorlon/ubuntu-test-cases/better-whoopsie-testing/+merge/229152
<mterry> hallyn, sometimes init --user has 3 cgroups set, just not the systemd one.  Other times it is missing all 4
<mterry> (and sometimes it has all 4)
<desrt> mterry: systemd-shim!!!!
<desrt> whoever wrote this shit... my god...
<mterry> desrt, agreed!
<plars> bdmurray: I was looking for your ack on it. If you are happy with it, then I can get it merged
<mterry> desrt, so I don't know how much you've been following, but...
<desrt> i already have a theory
<desrt> systemd-shim, in the name of efficiency, submits cgroup requests to cgmanager async
<mterry> desrt, it seems like there's a race between lightdm/cgmanager/logind/something
<desrt> all at the same time
<mterry> desrt, aha!  an async achille's heel
<desrt> which means that systemd-shim is capable of returning to its caller "okay!  all done!" before the cgroup is properly setup
<hallyn> feh
<hallyn> i forgot it did that
<hallyn> iow i lied to mterry
<desrt> i wrote the code in such a way that it would be easy to change if this became a problem
<desrt> ie: should only need to patch one place
<hallyn> desrt: i don't know if you've been following the Abandon discussoin as well, but systemd-shim now has to become long-lived actually
<slangasek> plars: surely, this was already merged and that's why the whoopsie smoke test has been failing?  I don't understand what happened with that particular MP though, which is not (no longer?) targeting the correct branch.  http://ci.ubuntu.com/smokeng/utopic/touch/mako/222:20140904.1:20140903.1/10220/default/1631128/
<desrt> hallyn: :(
<desrt> hallyn: what about the idea of poking through sysfs to find the state we need?
<hallyn> desrt: for what?
<plars> slangasek: sec, it's been a while since I looked at it, let me check
<desrt> the idea is that we can shutdown existing transient units, right?
<desrt> those transient units will be recorded as state in the kernel in the form of cgroups visible in sysfs
<plars> slangasek: the mp was against the wrong branch, so that could be why it didn't automatically go away
<bdmurray> plars: well, I've approved it now fwiw
<mterry> desrt, is this in cgmanager_call()?
<desrt> mterry: probably.
<desrt> "Avoid round-trip delays: issue all calls at once and report errors..."
<desrt> so you have two options
<hallyn> desrt: no the problem is that we have to listen to object path org.freedesktop.systemd.unit.session_2d${sessionid}_2d.scope
<desrt> one is to add a counter and block until that counter is reached
<hallyn> that's where Abandon gets sent
<desrt> this would involve using a private maincontext probably
<desrt> the other is to just convert it to using sync calls
<desrt> will hurt performance, but this isn't exactly an operation that is happening once per second
<slangasek> plars: yes - but I also can't seem to figure out the right branch
<hallyn> desrt: add the counter in shim, right?
<desrt> hallyn: we can do that.... and you can also use a subtree watch
<desrt> hallyn: ya... i'm not totally keen on the counter idea
<mterry> desrt, I will certainly test the fix with a sync call, testing now
<desrt> i've seen these sorts of things go off the rails before... they're hard to get right
<desrt> mterry: be sure to unref the return value
<bdmurray> slangasek: maybe its failing because of the run in foreground change?
<hallyn> desrt: but we can't use a subtree for dbus activation right?
<mterry> desrt, ok.  I've lived in qt land too long already, unref'ing things seems quaint
<plars> slangasek: yeah, it's kind of a pain. I'll check on it right after this call but I suspect you're right that it's already merged
<desrt> mterry: welcome back, man!
<slangasek> bdmurray: I really don't know why it's failing; help understanding this is appreciated
<desrt> hallyn: we certainly can
<desrt> hallyn: one merely has to register the subtree watch before taking the bus name
<hallyn> desrt: !  if so then we can far simply my mp against lp:ubuntu/utopic/systemd-shim
<desrt> so that it's already there by the time we start receiving messages
<desrt> man
<desrt> you guys have been busy :)
<desrt> so a bit of theory: on dbus, it's the well-known names that are activated
<hallyn> ok well i need to go back to server-land for a few hours.
<hallyn> hm,
<desrt> the object paths are solely a concern of the process that owns that name
<desrt> and that process has a chance to setup whatever object paths it wants to during its activation
<hallyn> but that never worked for me
<desrt> so when it comes online it already has a full set
<desrt> so we could even do things like scan sysfs on startup to decide which objects to export, if we wanted
<desrt> "exporting" an object is even a bit of a misnomer... we actually do nothing to "export" it... we only make a note to ourselves, that if somebody asks about this object in the future, then we handle it in such a way....
<hallyn> i registered the org.freedesktop.systemd1.Scope name, but never received the org.freedesktop.systemd1.unit.session*.Abandon methods,
<hallyn> and logind said no such interface
<desrt> the bus itself has absolutely no concept of objects
 * hallyn rereads
<desrt> is org.freedesktop.systemd1.Scope a name or an interface?
<hallyn> that is the interface
<desrt> so how it works is that you register an object with a particular interface, right?
<hallyn> right.  long as i'm running that works fine
<desrt> you have to register the object path before we take the name...
<hallyn> i cna't know the object path
<desrt> ie: in shim_bus_acquired
<desrt> but you can do subtree...
<desrt> which will watch all paths below /x/y/z/*
<hallyn> on the object path tree?
<hallyn> ok, and for the dbus activation, what Name do I use - interface or path subtree?
<hallyn> (i.e. org.freedesktop.systemd1.Scope or org.freedesktop.systemd1.unit)
<desrt> neither?
<desrt> bus activation is always based on bus names
<desrt> which is probably always going to be org.freedesktop.systemd1
<hallyn> ok
<desrt> interfaces are also not a concern of the bus
<desrt> all of this stuff is only interpreted by the client _after_ it has activated
<hallyn> so i get dbus-actviated for Abandon (not sure that was working, but imght have), then i register subtree for org.freedesktop.systemd1.unit?
<hallyn> I think I only ever tried org.freedesktop.systemd1.Scope
<desrt> strictly, you get dbus-activated because someone tried to send a message to org.freedesktop.systemd1
<hallyn> right
<desrt> then you set stuff up...
<desrt> then you claim the name
<desrt> then you get the message
<hallyn> i can't claim the name until i know what the name is,
<desrt> only at that point do you start making sense of interface, object, method, etc.
<desrt> but the name is always org.freedesktop.systemd1
<hallyn> oh
<desrt> the other things are interface/object/method
<hallyn> ok, so i can try all this this way again on monday hopefuly,
<desrt> welcome to dbus -- the land of confusion :)
<hallyn> if you wanted to take a stab, the actual cgroup code we wnat is in my mp
<desrt> k.  i might get a chance to take a look after lunch
<hallyn> lp:~serge-hallyn/ubuntu/utopic/systemd-shim/shim-abandoncg
<desrt> this approach seemed to work well last time :)
<desrt> you deal with cgmanager, i deal with dbus :)
<hallyn> i would SO much rather get the activation to work tha make shim long-lived!
<hallyn> great to have you back :)
<desrt> same.
<hallyn> thanks much, ttyl
<desrt> ta
<mterry> desrt, seems to be fixing it
<desrt> mterry: win!
<mterry> desrt, trying more runs to reduce the chance I've just been getting lucky
<desrt> of course, with races, one never truly knows.... :)
<desrt> mterry: do you want me to just make the chance here and push it?
<mterry> desrt, it was happening about 4 out of 5 before, I've run 3 times without it
<desrt> or should i use your patch?
<mterry> desrt, my patch is what you'd imagine -- moving the callback code up to the call itself
<desrt> (did you do the error handling correctly, etc?)
<desrt> k
<desrt> i'll just do it locally then
<mterry> desrt, 5 successes so far
<hallyn> \o/
<mterry> desrt, yeah, I'm getting tired of rebooting, 7 successes in a row, I'll take it as fixed
<desrt> awesome
<mterry> desrt, bug 1365095 is where I've been tracking it
<ubottu> bug 1365095 in unity8 (Ubuntu) "Greeter not asking for pin code in image 11 (krillin)" [High,Confirmed] https://launchpad.net/bugs/1365095
<mterry> desrt, I'll add a comment to the bug, but just if you write a changelog entry
<desrt> can you take a quick look at http://ur1.ca/i4id7 ?
<desrt> i'm about to push that -- just want to make sure this is the same fix as you had :)
 * mterry looks
<desrt> for somewhat silly reasons, i am currently unable to login to launchpad :p
<mterry> desrt, that is the exact same patch, awesome
<mterry> only so many ways to do that  :)
<desrt> (long story: i attached my yubikey to my dorm-room keyring at debconf... and when i left, i turned it in...)
<desrt> okay.  pushed upstream.
<mterry> desrt, :)
<desrt> they were nice enough to drop it in the mail... but now i wait :)
<desrt> https://github.com/desrt/systemd-shim/commit/80e9dc98b733a4386c0cca78861892506b2cfae2
<mterry> desrt, you need a second key!
<desrt> ya
<desrt> i want to wait until their next model comes out, though
<desrt> since their website is doing a good job of convincing me not to buy the existing one by saying "next model will support new auth spec.  CURRENT MODEL NOT UPGRADABLE"
<mterry> desrt, :)
<mterry> desrt, so what's the path into Ubuntu's archive for this package?  This fix is something I'd like to land in shorter order rather than waiting on bundling other shim fixes
<desrt> talk to pitti, i think?
<desrt> i have no idea how that half of it works :/
<desrt> maybe slangasek could also help... i think he was involved in the debian side?
<bdmurray> plars: if you find the branch containing the test let me know as I'd like to make some changes to it.
<plars> bdmurray: yes, I was just about to check it, one sec
<plars> bdmurray: confirmed, it was merged already
<slangasek> desrt, mterry: I'm happy to cherry-pick a change into Debian and sync to Ubuntu today.  But we should also resolve https://code.launchpad.net/~serge-hallyn/ubuntu/utopic/systemd-shim/shim-abandoncg/+merge/233280 today
<bdmurray> plars: and what branch contains the test so I can make a change to it?
<desrt> slangasek: if you want to vendor-patch that as well, go ahead... but i'd rather not take it upstream without a closer look first
<slangasek> desrt: well, I'm also not vendor patching it without taking it a closer look than I have so far :)  but it's critical urgency
<plars> bdmurray: lp:ubuntu-test-cases/touch
<desrt> okay
<mterry> slangasek, sure if that's critical too then I have no issues with bundling them
<desrt> so let me move it from my "i might take a look at it this afternoon" list to "i will take a look at it" :)
<hallyn> slangasek: desrt was going to do a cleaner version of my mp - that lets systemd-shim still timeout
<bdmurray> plars: got it, thanks
<slangasek> hallyn: oh.  Should I hold off then?
<hallyn> slangasek: so given that, i'd prefer to not have my mp make it into any package if possible :)
<hallyn> slangasek: yeah
<slangasek> desrt: ^^ is that on your plate for today?
<desrt> slangasek: yes.
<desrt> had a few other things, but none of them could be described by anyone as 'critical'
<slangasek> desrt: ok, then I'll step back from that and just look at the other cherry pick.  that's https://github.com/desrt/systemd-shim/commit/80e9dc98b733a4386c0cca78861892506b2cfae2 ?
<desrt> yes
<desrt> if i land the other thing today i'll probably also do a new release, though
<desrt> there is a pitti patch for changing a typesignature there as well
<cjwatson> siretart: landing libav; after that's in I'll demote jitsi and sort out ubuntustudio-meta
<cjwatson> that should hopefully be enough
<desrt> cjwatson: what ever came of this ffmpeg discussion?
<cjwatson> desrt: nothing very concrete as yet
<desrt> hello debian :)
<ScottK> I think we understand once again why there was a fork.
<desrt> that's helpful, at least
<ScottK> Those of us who were around then, weren't particularly confused on that point.
<awe_> slangasek, quick question... if a bug is filed in LP because of a crash, it's marked as private by default.  Can anyone besides the owner look at the bug, or must the owner make it public first?
<jtaylor> I think bug control members can see it
<unstable> I want to maintain a change management process for updating deb packages on a lot of ubuntu machines. I know koji/bodhi for rpm based systems works really well ( https://admin.fedoraproject.org/updates / http://koji.fedoraproject.org/koji/ ), or pulp. Is there an equivalent to these systems that the ubuntu team uses?
<desrt> hallyn: hey... are you around again?
<slangasek> awe_: what jtaylor said, I think
<awe_> all good now, but thanks
<hallyn> desrt: for 10 mins
<desrt> hallyn: any reason why you didn't explore the sysfs tree of cgroups yourself?
<hallyn> desrt: you mean /sys/fs/cgroup/freezer etc?
<desrt> was just easier to use the dbus api and get cgmanager to do it for you?
<hallyn> that usually is not mounted
<hallyn> no, it's because cgroup fs acces is not guaranteed,
<hallyn> especially not in nested unpriv containers
<desrt> interesting.
<hallyn> (cgmanager's raison d'etre)
<desrt> i suppose that makes sense.  thanks.
 * desrt is glad he asked :)
<hallyn> yeah it slows things down a bit, especially through a proxy.  but it's necessary given cgroup kernel maintainer's view on fs access delegation
<desrt> ya... i've read about these views :)
<desrt> makes sense, though
<desrt> feels slightly odd that we delegate the delegation, ... but meh
<desrt> it is a shim, after all
<hallyn> desrt: heh, just wait until we put an fs on top of cgmanager :)
<hallyn> s/we/stgraber/
<desrt> i guess we will not do that soon?
<hallyn> i think we will
<desrt> (or ever...)?
<desrt> post 14.10, aren't we supposed to hop to systemd entirely?
<hallyn> that will allow systemd to run using it's current fs accesses
<stgraber> desrt: not this cycle, but we should have this for 15.04
<hallyn> yeah, and systemd uses fs access
<desrt> but i mean... don't we stop using cgmanager then?
<stgraber> that's so we can start systemd in an unprivileged container which isn't allowed to mount cgroupfs itself so systemd in that container can still do any cgroup configuration it needs
<hallyn> desrt: no, then a fuse fs will talk to cgmanager to present what looks like cgroupfs to systemd in a child container
<hallyn> you thought dbus was bad :)
<desrt> i'm making a face
<desrt> if this was a videochat, you'd see my face
<hallyn> a happy on ei'm sure
<desrt> "wince" would probably be the best description
<desrt> google helpfully gives this result for image search: http://mocoloco.com/art/upload/2007/10/wince/greenberg_wince_oct07.jpg
<desrt> i assume that we've communicated with systemd upstream and they are not interested in implementing this in a more reasonable way?
<hallyn> desrt: it's always possible that at plumber's we'll come to a magical consensus that stops the need for that
<desrt> i certainly hope so
<desrt> makes me wish i didn't turn down my invite to plumbers :(
<hallyn> desrt: i'm giving a talk on cgmanager at linuxcon.eu and hoping to talk to systemd folks after that
<hallyn> nice fangs btw
<hallyn> oh didn't look clsely enough, tguess that's not what they are
<desrt> sigh.
<desrt> maybe i ought to go after all :/
<desrt> too much travel in this month....
<hallyn> yes, oct/nov seems to be busy for everyone travel-wise
<hallyn> but my goal is to just come to an agreement of how we can get to what we need - unprivileged containers running systemd in a way safe for the host.
<bdmurray> plars: https://code.launchpad.net/~brian-murray/ubuntu-test-cases/autoreport-check/+merge/233571
<plars> bdmurray: ok, we need to talk to slangasek about that one... I did have that in there before after our last discussion, and slangasek said it used to be needed but shouldn't be anymore, and having it there could hide problems
<plars> bdmurray: actually this is slightly different, you're just checking for it, I was previously creating it
<plars> bdmurray: so maybe you intend for this to be just a test case, rather than saying the test can't run unless something else sets up autoreporting?
<slangasek> bdmurray, plars: I'm ok with this change, as the test will still fail and if it's failing due to the lack of this file it's better to explicitly report that problem
<plars> ack
<slangasek> plars: I guess we can have the philosophical argument about whether this is part of a test case for whoopsie vs. something else :)
<plars> slangasek: I don't think that's necessary :)
<plars> slangasek: it's a problem that affects whoopsie, nobody is suggesting that a failure here is necessarily caused by whoopsie
<slangasek> bdmurray: are you adding this check because you're seeing /var/lib/apport/autoreport missing in practice?
<bdmurray> slangasek: no, because the test is failing and we don't know why and it would if autoreport didn't exist.
<slangasek> bdmurray: ok.  FWIW in my own testing I had ruled this out as the cause of the failures
<bdmurray> slangasek: another issue is that the whoopsie-test.sh removes all _bin_sleep.0.* files in /var/crash/ so the .uploaded file can be removed before whoopsie-upload-all notices it so it can keep running until its timeout
<bdmurray> the second it being whoopsie-upload-all
<desrt> hallyn, stgraber: might it be possible to get an API on cgmanager to dump out all of the cgroups?
<desrt> and/or one to let me find a cgroup by its basename?
<desrt> ie: i put in session-1.scope and it tells me about user.slice/user-1000.slice/session-1.scope
<desrt> because right now, this sort of sucks....
<desrt> also, in light of containers, my approach to this problem may actually be dangerous
<hallyn> desrt: the code i'd proposed looks under user.slice/* for all children, and looks to see which one has session-1.scope
<hallyn> bc we know that session-1.scope will be unique system-wide
<desrt> right
<desrt> except in case of containers..
<hallyn> ?
<desrt> where one of the containers could have a nested session-1.scope
<desrt> but that wouldn't be inside user.slice
<hallyn> the container would talk to its own slice no?
<hallyn> i mean its own shim
<desrt> yes
<desrt> but from the outside, we might find it by accident
<hallyn> you mean with what you were proposing?
<desrt> if we just naively looked for the first thing we find with the name "session-1.scope"
<hallyn> right
<desrt> i might have an even better idea, though
<desrt> we can parse /run/systemd/sessions/1 to find out the user
<desrt> it's ugly... but hey... this is systemd-shim, after all :)
<hallyn> c1?
<desrt> c1?
<hallyn> seems ok to me
<hallyn> on my ssystem it's /run/systemd/sessions/c1.  oh, that's for console, i guess,
<desrt> interesting.
<desrt> do you also have a session-c1.scope, then?
<mdeslaur> mvo_: I'm curious if there's been any progress on bug 1098738
<ubottu> bug 1098738 in apt (Ubuntu) "apt-get source only checks md5 hashes in Sources files" [High,In progress] https://launchpad.net/bugs/1098738
<hallyn> right when i ssh in i get a '15' in there
<hallyn> yeah, session-c2.scope
<hallyn> which actually would break my code i think
<desrt> ya...
<desrt> you need to stop using scanf :)
<hallyn> or dbus
<desrt> this is something like a red flag when i'm reading code
<hallyn> nonsense
<hallyn> i agree it shouldn't be used in glib code, but i couldn't find the glib thing to use
<hallyn> i really meant for the mp to just be a (working) poc
<desrt> hmm
<desrt> seems that logind often changes what goes in this file
<desrt> that's enough to make me think twice about using it
<hallyn> it's probably also free to change the path layouts though
<hallyn> you could keep /run/shim/scopes with all the info
<desrt> that's not the worst idea i've ever heard....
<desrt> that's actually a pretty nice idea
<desrt> really all we would need is a mapping of scope names to cgroup paths
<desrt> so what happens, then?
<desrt> logind Abandons the scope?
<desrt> why not shut it down entirely?
<hallyn> what do you mean?
<hallyn> you mean why not use StopUnit?
<desrt> yes
<desrt> Abandon seems ... meaningless, really
<hallyn> <shrug>  screen and tmux?
<desrt> ah.  interesting.
<hallyn> well, we set removeonempty so the cgroups will eventually go away
<hallyn> i think abandon is there to recognize the design flaw :)
<desrt> well, rather, i think screen/tmux are the ones with the design flaw :)
<desrt> although they can't be blamed
<desrt> probably in the future these things will need to be moved to a more robust system
<hallyn> for that matter, on a fedora systemd system, is it set to use abandon?
<desrt> no idea
<hallyn> or is #KillUserProcesses=no something we add on
<desrt> i guess so...
<desrt> i never noticed problems with screen...
<hallyn> well it's trivial for screen to be patched to move to another cgroup, of course.  though it the needs privs
<desrt> i was thinking rather that it would switch to some mechanism like dbus activation
<hallyn> huh
<desrt> the client would contact the service via dbus
<desrt> which would start in a new cgroup
<desrt> disconnected from the session...
<desrt> it could even be considered a new login session, if you think about it
<hallyn> still would require privilege - or help from logind/libpam - to create that new cgroup, but that's an interesting idea
<hallyn> right
<hallyn> that makes sense
<desrt> once we have proper 'user' kdbus, it won't need any help
<desrt> since processes launched this way are associated directly with the user -- not the session
<hallyn> i guess i'll have to go watch the kdbus talk
<desrt> more reasons to go to plumbers...
<desrt> sigh
<hallyn> hah - see you there :)
<desrt> what did you mention was coming up in november, btw?
<hallyn> hm, there's openstack early, then a sprint the server team needs to be at later
<desrt> ah
<hallyn> and lots of time off on my part
<desrt> neither one that i should care about :)
 * desrt goes back to beating on cgmanager
<desrt> btw: what is the problem with setting Remove at the start?
<desrt> and just ignoring Abandon?
<desrt> seems like this might be a massively easier approach to the issue
<desrt> if people wanted us to kill, then of course we'd still need to handle StopUnit
<desrt> but since that's turned off....
 * desrt wonders if he has fundamentally misunderstood something
<desrt> btw: your killtasks code is racy...
<desrt> if a fork() goes between our list of the pids and the kill() command, you will leave some pids in the cgroup
<desrt> hallyn: ^ ?
<hallyn> desrt: so if you just do Remove, and there are active tasks in the cgroup, then the remove will fail, and the cgrou will never be removed
<hallyn> i do removeonempty first, so that if it's not empty now but becomes empty while i'm working, it'll be deleted
<hallyn> then i remove any subdirectories and then itself;  if it's empty, that will remove it (and, in that case, autoremove would not, bc it only happens when it *becomes* empty)
<desrt> right... that's what i mean
<desrt> can we just remove-on-empty at the start?
<desrt> and then ignore abandon?
<hallyn> start of what?
<desrt> this seems like a __much__ easier approach, and i can't imagine anything wrong with it
<hallyn> sessoin create?
<desrt> when we first create it
<desrt> ya
<hallyn> we did that before, and it *does* go wrong :)  bc of upstart
<desrt> why?
<hallyn> upstart creates the same cgroup for pre-start, start, and post-stop
<hallyn> so when pre-start is done, autoremove fires,
<hallyn> then start tries to create the cgroup which already exists,
<hallyn> then remove-onempty handler kicks in (kernel-run),
<hallyn> cgroup is removed, now start tries to move the task into cgroup and fails
<desrt> is there any way we could delay the autoremove call until after we know the session is fully logged-in?
<desrt> ugh.. this is truly dreadful stuff :(
<hallyn> we (systemd-shim) would have to know whose behalf we are working on
<hallyn> i think what i had generally is ok - other than you're right i'm not working hard enough to kill everything
<desrt> we can know that, but i'd prefer not to :)
<hallyn> so yes we should loop over the killtasks until no tasks are left
<desrt> so after we get Abandon...
<hallyn> (and then fo rgood measure, if remove fails, re-try the kills I suppose)
<desrt> do we know that nobody will ever make a call to this again?
<desrt> (seems that cgmanager should have a kill-and-remove call)
<hallyn> i think that makes sense for cgmanager
<desrt> a recursive-autoremove might also be nice :)
<hallyn> yeah.
<hallyn> so maybe the thing to do is not fret too much over the code going into shim/src/cgmanager.c today, and then port those fns over to using the right cgmangaer call when available
<hallyn> (we'll have to check the cgmanager api_version for the support :( )
<desrt> my primary concern now is about the stateful thing
<desrt> nah -- we can just depend on the higher version
<hallyn> right.  so what's your thought on the /run/shim/sessions file?  is ther ea downside?
<desrt> there is absolutely no point in using the new API at all if we would have to keep the old code around
<hallyn> ok
<desrt> no downside as long as everything stays in sync
<desrt> which i think it should
<desrt> since these files represent units
<desrt> not random cgroups
<hallyn> well i've got two other fns to implement in cgmanager.  since i don't have to spend monday working on longevity of systemd-shim, i can work on those monday :)
<desrt> cool
<desrt> i'll try to have something for you by then
<desrt> but this is rapidly spinning into a not-done-by-today sort of task
<desrt> might be able to find a bit of weekend time for it
<hallyn> excellent.  so meanwhile will you push just your earlier commit to pkg for slangasek ?
<desrt> that's up to slangasek
 * hallyn expects to lose power soon, storms...
<desrt> it's already in master...
<desrt> and i don't maintain the debian package...
<Noskcaj> Can someone please tell me why usb-modeswitch-data hasn't migrated to utopic?
<infinity> mlankhorst: Along with that mesa 10.3 (when you're ready to upload), can you pull this patch?  http://lists.freedesktop.org/archives/mesa-dev/2014-August/064711.html
<hallyn> desrt: btw 'Prune' was listed as a low priority method to implement eventually in org.linuxcontainers.cgmanager.xml.  (that's the recursive_rmdir)  maybe that should take too booleans, 'kill' to say kill tasks, and 'recursive' to do recursive rmdir.
<hallyn> stgraber: ^ any opinion on best methods from api point of view?
<stgraber> hallyn: hmm, not sure it should be cgmanager's job to kill stuff though... recursive remove makes sense because the alternative is a crazy amount of queries to cgmanager, but kill, it's just getTasks + kill() so the clients can do it and can do it in a saner way (send sigterm, wait, send sigkill, ...) and if they want the cgroup to go away when they're done, they can set remove on empty
<hallyn> stgraber: but to kill all tasks reliably you have to keep redoing the getTasks to make sure nothing forked
<stgraber> hallyn: hmm, indeed
<hallyn> and really, if you're going ot recursively remove-and-kill a cgroup, you'll still hae to getTasks in al lchild cgroups
<hallyn> really the code doing that was pretty clean on the clien tside,
<hallyn> and i have concerns about cgmanager being able to tell whether the calling task has the rights to kill
<hallyn> in fact, there's no way for cgmangaer to be able to check whether the kill would be allowed by apparmor/yama/etc
<stgraber> indeed, that'd completely bypass apparmor's signal filtering
<hallyn> So I guess we can't do that.  and if we can't do that, i'm not sure recursive rmdir makes much sense.
<hallyn> well, it does,
<hallyn> if it does removeon_empty recursively first, then remove recursively
<slangasek> bdmurray: that's only a risk if a prior instance of whoopsie-test.sh has triggered, right?  Anyway, doesn't this tie into my proposed apport branch for changing the semantics of the upstart job?
<slangasek> desrt: which commits should I be looking at in master that fix our critical problem?
<desrt> slangasek: none yet
<slangasek> oh
<desrt> you can take the patch from hallyn but i want to substantially rework it before taking it upstream
<hallyn> the critical problem mterry was having?  that's upstream right?
<slangasek> I thought you said "it's already in master" - a different "it"?
<desrt> i plan to do that over the weekend
<desrt> slangasek: ah.. the mterry race problem is already upstream
<bdmurray> slangasek: well if there was some other crash before starting the testing, but my change wouldn't help that.
<desrt> i thought when you said "critical" earlier you were speaking of the Abandon thing
<slangasek> bdmurray: I think the case for /bin/sleep crashing on its own is an ignorable corner case
<slangasek> desrt: er, that is what I'm talking about
<desrt> the Abandon thing is not ready
<slangasek> ok
<desrt> unless you want to take hallyn's patch
<desrt> the race condition thing is fixed, though
<slangasek> no, I was just trying to interpret the highlights in my scrollback :)
<bdmurray> slangasek: I mean any crash would cause whoopsie-upload-all to run.
<desrt> i mean... in a certain sense, everything is great... because we have a patch for the one problem and as of today we discovered the cause of and patched the other
<slangasek> bdmurray: ok - true, but if I'm not misremembering, my apport branch changes the job so that it will trigger for each new file
<bdmurray> slangasek: okay, I haven't looked at it in a bit
<slangasek> bdmurray: this problem you describe is certainly precisely one of the things I was trying to fix, I just don't remember now what I concluded about the right way to fix it :)
<bdmurray> slangasek: well you should revisit the branch then ;-)
<slangasek> yes, it's on my todo for this afternoon... :)
<slangasek> the other thing was, ev raised it to my attention this morning that whoopsie+apport disagree about inotify and file modes
<slangasek> which I need to read scrollback to understand, but is possibly an argument for my approach to atomic file replacements in spite of pitti's objection
<cjwatson> Noskcaj: makes usb-modeswitch uninstallable
<mvo_> mdeslaur: yes, the fix is in experimental, it breaks ABI unfortunately
<Noskcaj> ok
<mvo_> mdeslaur: it will be in with the next abi break in ubuntu
<cjwatson> Noskcaj: because Breaks: usb-modeswitch (<< 2.2.0)
<cjwatson> (and usb-modeswitch Depends: usb-modeswitch-data, of course)
<cyphermox> Noskcaj, cjwatson, I will be fixing usb-modeswitch either tonight or this weekend
<Noskcaj> :)
<cyphermox> that is, unless someone beats me to it, but I don't wish it on anyone :-)
<cyphermox> Noskcaj is it breaking something for you?
<cyphermox> It's always useful to have some help with testing, I don't have the new Huawei devices that need the new code
<Noskcaj> cyphermox, I was just looking at the email to ubuntu-devel, and not looking at the control file for -data before i asked here
<cyphermox> OK. It is kind of broken how it is, perhaps the new data should not break things, and instead usb-modeswitch could (and does, I think) ignore the bits it doesn't understand and still do almost the right thing
<Saviq> so, who's a make guru? say I have targets like foo1-bar1, foo2-bar1, foo2-bar2 etc., can I make a single rule to make those, with foo? and bar? being available as variables in that rule?
#ubuntu-devel 2014-09-06
<Bluefoxicy> ugh
<Bluefoxicy> why does Google Maps lock up either Chromium or my whole desktop?
<Bluefoxicy> you know, by maxing out RAM usage whenever I open a tab to it and try to scroll wheel in
<sithlord48> its got a fevor and its only cure is more RAM?
<Bluefoxicy> I've also found that disabling swap doesn't help:  RAM bloats, pushes out page cache, then the hard disk thrashes re-reading libraries CONSTANTLY.  Why isn't there a page cache lock to OOM in favor of freeing page cache?
<Bluefoxicy> Seriously I have 16GB RAM.  The kernel is too stupid to understand that 50MB of page cache and 16.950GB of working memory is going to kill the machine.
<Bluefoxicy> ok driving off to starbucks with books to study from.
<sarnold> Bluefoxicy: you could always use ulimit -m   to limit chromeium to just eight or ten gigs or whatever
<sarnold> Bluefoxicy: maybe ulimit -v would be better. either way it's worth a shot
<Bluefoxicy> sarnold:  it doesn't work that way
<Bluefoxicy> sarnold:  you can limit the VMA--preventing mapping of file-backed segments et al, which is used for file caches and so forth, which is managed by the kernel--or you can limit nothing.
<Bluefoxicy> Trying to limit resident set size of memory per-process or per-user on Linux is really useless.
<Bluefoxicy> Second, the point is that the kernel will swap-thrash when you eat up memory even when you have no swap.
<Bluefoxicy> sarnold: btw, ulimit -m doesn't do anything
<mlankhorst> infinity: those kind of patches should really have been submitted with a cc to stable, to get it in 10.3 automatically
<sarnold> Bluefoxicy: aww, I thought the -m limits had been put back around 2.6.17 era :/
<infinity> mlankhorst: Fair enough, not my patch, but can we carry it anyway? :P
<mlankhorst> sure
<mlankhorst> I won't carry it, but I can commit it to mesa
<geofft> xnox: Logan_: can your capnproto delta be submitted to Debian? want me to file a bug in the BTS?
<Logan_> lemme check
<geofft> Debian has 0.4.1, so it seems like it'd be nice to be able to sync
<Logan_> it looks like my delta was already incorporated
<Logan_> they're using dh-autoreconf in Debian now as well
<Logan_> not sure about all of Dmitri's stuff, though
<Logan_> *Dimitri
<geofft> yeah, Debian doesn't appear to be multiarching it
#ubuntu-devel 2014-09-07
<Noskcaj> How can we make intel-vaapi-driver migrate to release? It seems to just be waiting for arches that it's not meant to build on
<Logan_> I'll take a look
<Logan_> usually that doesn't matter unless it built successfully on those architectures before
<Logan_> er, that seems like a bug with the excuses
<infinity> It's a minor misfeature.  It's not wrong about those packages being out of date.
<infinity> But they also happen to be NBS.
<infinity> It's hard to determine that because they were arch:all and then disappeared.
<Logan_> do they need to be removed?
<infinity> Yeah, I'm going to do that.
<Logan_> that's what I figured
<infinity> Should migrate after the next publisher cycle, but I'll keep an eye out.
<Logan_> any reason why it's not showing up in update_output.txt?
<infinity> Logan_: Because it failed in the excuses stage.
<infinity> Logan_: It's a 2-stage process, if it fails excuses, it's not tried in the output pass.
<Logan_> ah
<Logan_> I always thought the raw output included excuses as well
<infinity> Nope.
<infinity> escuses is checking up-to-date, RC bugginess, age (which we don't take into account in Ubuntu), autopkgtests...
<infinity> Only when all of that passes do we do the costly installability checks that output represents.
<Logan_> gotcha
<Logan_> infinity: I feel like it's a hacky solution to use the system libtool (i.e. force the LIBTOOL variable in Makefile.in to libtool rather than @LIBTOOL@), but when I get a version mismatch after autoreconf, it seems to be the only way around it
<Logan_> is there a better way to avoid that?
<Noskcaj> How can i make lp:debian/hexchat up to date again? (a new bugfix release should be in it)
<Noskcaj> Can someone please mass sync the openarena packages?
<cjwatson> Noskcaj: maybe but only given a complete list; I'm not going to search
<hallyn> desrt: i released 03.31 cgamager w prune.  i cannot safely do kill-and-remove, but i wll do gettasksrecusive wbich will letyouge allpids at once, hup then ksiglill, then reget to verkfy no new forkd, then prune
 * hallyn out
<nadrimajstor> From the shell, how can I see which configure flags were used for building a particular package? (i.e not the debian/rules but the configure options that were derived from rules)
<jtaylor> depends on the package
<jtaylor> if you are lucky dpkg-buildflags
<jtaylor> otherwise you have to read rules and the buildlog
<nadrimajstor> jtaylor: mesa package.
<nadrimajstor> jtaylor: I'm trying to follow the rules file but after two screens of config munging back and forth my brain hurts. :D
<TJ-> nadrimajstor: There's also pkgconfig entries; "/usr/share/pkgconfig/*"
<jtaylor> those should only contain paths
<jtaylor> very rarely abi stuff
<jtaylor> anything else in there is a bug
<nadrimajstor> dpkg-buildflags give me just generic options... pkconfig is mostly empty for me... (and it looks there is stuff that should not be there - will file a bug at ubuntu-mate)
<nadrimajstor> So, go to LP, look for build logs?
<jtaylor> yes
<nadrimajstor> ok
<jtaylor> what are you looking for?
<nadrimajstor> Does --with-egl-platforms= contain framebuffer (among dri, x11 ...)
<jtaylor> that can typically be found in the rules file
<nadrimajstor> jtaylor: On the second look... There is no mention of fbdev anywhere in the rules file... Thanks jtaylor
 * nadrimajstor off to recompile mesa
 * nadrimajstor thinks that apt-get build-dep is a bless :)
<jtaylor> then you'll love mk-build-deps -ir :)
 * nadrimajstor off to RTFM on mk-build-deps
<jtaylor> does the same but allows you to remove all again be removing a meta package it installs
<nadrimajstor> jtaylor: Ahaaa.... I got it. :)
#ubuntu-devel 2015-08-31
<tdaitx> teward, you can list the open session with schroot -l --all-sessions
<tdaitx> teward, then enter them using: schroot -r -c <session>
<teward> tdaitx: thank you
<tdaitx> teward, to clean up (delete the session), run: schroot -e -c <session>
<tdaitx> teward, or even: schroot -e --all-sessions (as the name says, to clean all of them)
<teward> tdaitx: right, i know how to clean em up i'm trying to see if the make rules i put into rules were ever even executed
<tdaitx> teward, ok, have fun =)
<teward> tdaitx: perhaps you know this, i have a .c file that needs compiled, it's just a wrapper for a perl program.  any way to make it build, as part of the rules file during building of the actual binary?  (The debian binary just installs perl scripts, it doesn't have anything else to compile)
<teward> so short of me making a makefile is there a way to force the build
<teward> before it throws things into the actual binary package for installation (since the compiled wrapper needs installed)
<tdaitx> teward, there are many ways to do it... the simplest one I can think of is to call gcc in the rules file itself
<teward> tdaitx: with or without a dh_make override?
<teward> the reason being that putting gcc in there made it try and run during the source package build
<teward> rather than the clean schroot
<teward> (let me try something...)
<teward> mmm, still not sure where in rules to put it :/
<tdaitx> teward, if the rules file is using dh, then try override_dh_auto_build
<tdaitx> override_dh_auto_build:
<tdaitx>   override_dh_auto_build
<tdaitx>   gcc
<teward> that works for me.
<teward> i thought i entered that, i misspelled xD
 * teward facedesks
<teward> lets hope this builds now
<tdaitx> ops, replace that second override_dh_auto_build with dh_auto_build
<tdaitx> =)
<teward> tdaitx: you're a godsend, thank you for the assist :)
<teward> i've beat my head on this the past few hours xD
<tdaitx> teward, glad to help =)
<seyeongkim> Who can i ask about multipath-tools which has cciss_tur for HP LOGICAL VOLUME as default value? redhat and suse has tur as default value. with cciss_tur there is err msg on multipath -v3.
<tdaitx> seyeongkim, chypermox does some testing on multipath, you should check if he knows or can point you to someone who does
<seyeongkim> tdaitx thanks
<tdaitx> seyeongkim, ops, nick without typo is cyphermox
<seyeongkim> tdaitx t :)
<seyeongkim> thanks
<tdaitx> you are welcome =)
<pitti> Good morning
<dholbach> good morning
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<dholbach> didrocks, is the ubiquity-slideshow-ubuntu fix already in lp:ubiquity-slideshow-ubuntu?
<dholbach> didrocks, I'm asking because I'm looking at https://code.launchpad.net/~ubuntu-mate-dev/ubiquity-slideshow-ubuntu/ubuntu-mate-welcome/+merge/269336 right now
<didrocks> dholbach: not sure it's the one I looked at and sponsored or another one (we had many of them)
<didrocks> let me confirm
<dholbach> no, I think it's a different one
<dholbach> but the branch is just up to 0.98 in d/changelog
<didrocks> dholbach: yeah, it's really annoying that we don't have access to this Vcs-Bzr branch
<didrocks> dholbach: yep, confirmed, the change isn't in the pacakge
<didrocks> package*
<didrocks> dholbach: be aware that darkxst just uploaded also some other changes without being able for us to merge into upstream's branch
<dholbach> ok
<dholbach> I'll ask for ubuntu-core-dev to be added to the team
<didrocks> dholbach: I did ping cyphermox about it
<didrocks> thanks :)
<didrocks> dholbach: if you can push https://code.launchpad.net/~darkxst/ubiquity-slideshow-ubuntu/UG-wily in between
<didrocks> (not sure if you have access)
<didrocks> https://code.launchpad.net/~darkxst/ubiquity-slideshow-ubuntu/UG-wily is the MP
<dholbach> I don't
<didrocks> ok ;)
 * didrocks doesn't fell lonely in this powerless schema :p
<dholbach> ok, mail sent
<dholbach> I also asked to transfer ownership of the team to TB
<didrocks> good :)
<ogra_> cjwatson, do you have an idea why https://launchpad.net/ubuntu/+source/ubuntu-touch-generic-initrd doesnt show any versions ? the package is definitely in universe since saucy
<cjwatson> ogra_: https://launchpad.net/ubuntu/+source/ubuntu-touch-generic-initrd/+publishinghistory disagrees with you, and says it was obsoleted by initramfs-tools-ubuntu-touch.  (Remember that /ubuntu/+source/<foo> wants *source* package names, not binary package names)
<ogra_> hmpf ... definitely not superseded
<cjwatson> And LP only shows information for non-obsolete series on the source package index page; that source package was only ever published in saucy, which is obsolete
<cjwatson> ogra_: initramfs-tools-ubuntu-touch builds an ubuntu-touch-generic-initrd binary package
<ogra_> i wonder how ...
 * ogra_ checks the code
<cjwatson> ogra_: you did it
<cjwatson> ogra_: https://launchpad.net/ubuntu/+source/initramfs-tools-ubuntu-touch/0.41
<ogra_> oh man
<ogra_> yeah, ignore me
 * ogra_ shakes head and thinks he should soon take vacation 
<pitti> ogra_: you mostly missed doing that during the hot summer days, though :/
<ogra_> i always miss it during the 12 months a year has :P
<ogra_> pitti, thanks for the fix for bug 1489410 ... note that i was referring to snappy-personal in it though ... they currently ship apport-cli as is (and wont have the dpkg lists because the build process removes them when removing apt and dpkg)
<ubottu> bug 1489410 in apport (Ubuntu) "do not require apt lists to be pre-installed" [Critical,Fix committed] https://launchpad.net/bugs/1489410
<ogra_> we should probably add an exception to keep the files for them then
<pitti> ogra_: yes, I know; but as I wrote that's a much bigger undertaking, and needs server-side infrastructure for doing the mapping if you guys want/need this at all
<ogra_> (i doubt snappy core will ship apport or any such tool)
<ogra_> yep
<pitti> ogra_: ah! that answers one of the questions already :)
<ogra_> but we have to ask mvo for a final work on that, he is tech lead here :)
<ogra_> (might be that apport might be a feature of "comfy" (which recently got renamed again and i forgot to what))
<ogra_> s/work/word :P
<darkxst> dholbach, can you sponsor syslinux stuff? its just new images
<darkxst> https://code.launchpad.net/~darkxst/debian-cd/UG-logo
<dholbach> darkxst, looks like Colin commented on it
<darkxst> dholbach, colin commented on the prior MP which hit the wrong branch
<dholbach> darkxst, I'm looking at the the MP linked from https://code.launchpad.net/~darkxst/debian-cd/UG-logo
<darkxst> dholbach, I resubmitted it against the correct branch since his comment!
<dholbach> ah ok
<dholbach> sorry
<sitter> in proposed we have libkonq5abi2 which needs transitioning from libkonq5abi1 but as it turns out that sobump wasn't needed. is it acceptable to simply go back to abi1 seeing as it hasn't gotten out of proposed?
 * ogra_ notes that apachelogger is incognito today :)
<sitter> I changed nick a while ago :P
<ogra_> :)
<sitter> doko: ^ thoughts on libkonq5abi2 question
<dholbach> darkxst, I can't merge this - sorry, I added a comment though - can you maybe request a review from infinity - it looks like the most recent changes came from him
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<doko> sitter, sounds ok, maybe add then a Provides: libkonq5abi2
<sitter> doko: I was thinking Breaks&Replaces actually
<doko> sitter, well, that too. but without the provides you have to binnmu
<sitter> doko: there were no builds against abi2
<sitter> reverting the version is to avoid having to rebuild the rdeps :)
<doko> $ apt-cache rdepends libkonq5abi2
<doko> libkonq5abi2
<doko> Reverse Depends:
<doko>   plasma-widget-folderview
<doko>   libkonq5-dev
<doko>   konqueror
<doko>   konq-plugins
<doko>   kfind
<doko>   kdepasswd
<doko>   dolphin4
<sitter> doko: all from the same source
<doko> ahh, ok
<doko> Laney, online?
<didrocks> doko: today is a bank holiday in the UK
<doko> ahh
<cjwatson> darkxst: the LP branch / MP will take a while to update, but it's merged where it counts now
<cjwatson> sorry for delay
<cjwatson> darkxst: no point asking anyone not in ~ubuntu-cdimage for that kind of merge, they can't do it
<tjaalton> hyperair: ping, heads up on openscad: mesa in ubuntu has no libgl1-mesa-swx11*, and debian will drop them too once 11.0.0 hits unstable
<hyperair> ugh okay
<hyperair> i need to check why i added that dep
<hyperair> is it being replaced by any other package?
<tjaalton> i've uploaded openscad to wily now, built fine without
<tjaalton> no
<hyperair> ah, okay, thanks
<hyperair> hmm, that change seems to have been done by chrysn and he left a note
<tjaalton> oh, apparently it got uploaded earlier already :)
<hyperair> it's in a comment in debian/control
<hyperair> O_o
<tjaalton> https://lists.ubuntu.com/archives/wily-changes/2015-August/008675.html
<tjaalton> err
<tjaalton> https://lists.ubuntu.com/archives/wily-changes/2015-August/008978.html
<cyphermox> good morning!
<sitter> doko: not considering because of the danling abi2 package now :/ http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kde-baseapps
<sitter> *dangling
<doko> sitter, removed
<sitter> thanks
<Riddell> mvo: what chances of a packagekit update this week?
<mterry> pitti, regarding the libmicrohttpd MIR bug, we like team bug subscribers, for bus factor reasons and all that  :)
<mterry> pitti, thanks for enabling tests, that's awesome
<pitti> mterry: ah; well, then I figure the only adequate one is the entire foundations team, as we don't have a team like "boot" or "systemd"
<pitti> mterry: I subscribed foundations-bugs now
<mterry> pitti, OK yeah, that's fine from my perspective. I just want a team to be able to yell at if something goes wrong.  Even if that means it's always you  :)
<doko> cyphermox, could you merge doxia?
<cyphermox> doko, sure
<barry> cjwatson: do you have a few minutes to talk about launchpad's api?  it's been too long for me and i think i'm missing something which i think i need to do a little data mining on a ppa
<bdmurray> pitti: the change in bug 1485787 was necessary because of bug 1485773.
<ubottu> bug 1485787 in apport (Ubuntu) "package_hook does not include package version" [High,Incomplete] https://launchpad.net/bugs/1485787
<ubottu> bug 1485773 in apport (Ubuntu) "new_only option when writing reports stops some data from being written" [Medium,New] https://launchpad.net/bugs/1485773
<doko> barry, uk bank holiday
<barry> doko: ah.  thx.
<bdmurray> while the UI displays it, it doesn't get written to the report iirc
<doko> bdmurray, at debconf I wasked how a debian devel could do some bug triage, and closing issues, in lp for some set of packages. was from the debian-science people, or debian-med. dholbach suggested to apply for https://wiki.ubuntu.com/UbuntuBugControl
<doko> is this correct?
<pitti> bdmurray: ah, that makes sense, thanks!
<bdmurray> doko: Yes, however see "If you are an upstream developer or bug triager for an upstream project contact Jorge Castro". Although jcastro probably isn't the best contact anymore.
<bdmurray> barry: I might be able to help.
<jcastro> not for the past two years or so
<jcastro> but tbh, I've only gotten like one or two queries
<doko> so who would that be?
<jcastro> and it's usually a nobrainer
<bdmurray> doko: How about me.
<bdmurray> pitti: will you reupload that apport change or should I?
<pitti> bdmurray: I'll fix that underlying bug for wily
<pitti> bdmurray: the change is still in stable-proposed, isn't it?
<pitti> that previous change is not a sufficient fix after all
<bdmurray> pitti: yes, that makes sense
<lamont> why would (wily) ssh hang after "debug1: SSH2_MSG_KEXINIT sent" ?
<infinity> lamont: What's the server?
<mterry> bdmurray, ~pkg-ime has committed to look after the tegaki-zinnia-japanese package, FYI
<mterry> bdmurray, same for zinnia package
<cjwatson> barry: well, let me know what you need and I can respond when I have a chance
<cjwatson> lamont: ssh -vvv
<bdmurray> mterry: thanks
<barry> cjwatson: thanks.  i'm looking at a few things and will ping or email in a little while
<Laney> doko: sort of online (train), can try to reply if you let me know what you want
<lamont> cjwatson: bad cable, believe it or not.
<lamont> from the land of wtf
<cjwatson> lamont: error detection ftw!
<cjwatson> barry: ok
<lamont> cjwatson: or some such.
<infinity> lamont: Special.
<lamont> pulling replacement cat5 about 100 feet?  loss
<doko> Logan, grrrrr, https://launchpad.net/ubuntu/+source/libindi/1.0.0-3/+build/7852395/+files/buildlog_ubuntu-wily-ppc64el.libindi_1.0.0-3_BUILDING.txt.gz
<doko> Logan, why do you override my fixes?
<Logan> yeah I was going to fix that
<Logan> strange the symbols didn't match up in Debian
<Logan> because the Debian maintainer claimed to fix the symbols
<Logan> and it's easy to fix if that claim isn't true
<Logan> less delta makes for a better Ubuntu
<Logan> it would be nice to have a PPA that can build on any architecture, though, so we don't have to do this guess-and-check thing
<doko> cyphermox, Unpacking libdoxia-core-java (1.1.4-3) ...
<doko> dpkg: error processing archive /var/cache/apt/archives/libdoxia-core-java_1.1.4-3_all.deb (--unpack):
<doko>  trying to overwrite '/usr/share/java/doxia-logging-api.jar', which is also in package libdoxia-java 1.1.4-2ubuntu1
<doko> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
<cjwatson> Logan: at least ppc64el really is coming soon, once the builders stop exhibiting random memory corruption
<Logan> ha, fun
<Logan> I should get around to becoming a Debian dev so that I can have access to the porting boxes
<cyphermox> doko: oh, wonderful
<Logan> doko: https://launchpad.net/ubuntu/+source/libindi/1.0.0-3ubuntu1
<zh1> noticed ubuntu menu bar is always left any specific logic for that?
<Logan> that's more of a question for #ubuntu
<Logan> but !controls
<zh1> Logan, did same question there and folks said to do it here
<Logan> !controls
<ubottu> Starting in Lucid, the minimize, maximize, and close buttons have been moved to the left side. For more information and workarounds, please see http://pad.lv/532633
<Logan> assuming that's what you're referring to
<zh1> most DE`s let move menu bars and here it seems i cant without installing something
<sarnold> do you mean the OS X style dock thing?
<zh1> mean left, top, right
<Logan> oh, Unity
<zh1> or bottom
<Logan> zh1: I think pointing you to http://askubuntu.com/questions/33605/can-i-move-the-unity-launcher is the best we can do
<Logan> it's by design that it sticks to that side
<Logan> there are some unofficial workarounds there
<Logan> you are always free to use another desktop environment if you don't like Unity
<zh1> i was never a fan of this design and noticed many users want to move unity
<zh1> Logan, i read that link already cause i found it when "googling"
<Logan> we can't give you a better answer than that
<Logan> and this channel is for Ubuntu development, not support
<zh1> ok
<ari-tczew> doko: thanks for ignoring bug 1487445
<ubottu> bug 1487445 in vtk (Ubuntu) "FTBFS: missing Build-Depends on libnetcdf-cxx-legacy-dev" [Medium,In progress] https://launchpad.net/bugs/1487445
<doko> ari-tczew, ?
<ari-tczew> doko: there was a patch submitted by LocutusOfBorg1 some days ago and I was on my way to sponsor it. You just uploaded your fix. :/
<doko> ari-tczew, well dropping the delta is clearly wrong
<ari-tczew> doko: ? He added a debdiff with the same change like you did.
<ari-tczew> who cares
<ari-tczew> but then I think dholbach's requests to focus on sponsoring is a bit pointless
<doko> ari-tczew, I've spent the last few days on getting some transitions done. I can't check for everything
<ari-tczew> doko: I really appreciate it. However, it's not a first case when a patch or a sync request to be sponsored
<ari-tczew> have been ignored.
<ari-tczew> that sponsors overview can we put in a trash, though
<ari-tczew> Anyway, I won't clearing such cases in community, please ignore my monologue.
<mterry> chrisccoulson, I want firefox 40 on wily...  :(
<sarnold> what does "not considered" mean? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<sarnold> it otherwise looks fine for migration..
<mterry> sarnold, it is ftbfs on powerpc
<sarnold> has it worked there lately?
<sarnold> I thought it's been ftbfs on ppc for a while
<mterry> sarnold, 38 did
<sarnold> hmm :) learn something every day..
<slangasek> and so did 39, per the listing there of the last successful powerpc build
<infinity> The powerpc FTBFS is an obvious -latomic missing, someone just needs to fix it instead of complaininig. :)
<doko> Riddell, cyphermox: https://launchpad.net/ubuntu/+source/plasma-workspace/4:5.4.0-0ubuntu1/+build/7851998
#ubuntu-devel 2015-09-01
<doko> infinity, any plans for glibc 2.22 for wily?
<infinity> doko: Yes.
<marlon> i look ubuntu sever to chat on
<pitti> Good morning
<StevenK> Can someone check why http://cloud-images.ubuntu.com/trusty/ doesn't have a current symlink? Every other release I've checked on cloud-images does have one.
<sarnold> utlemming,gaughen_, < StevenK> Can someone check why http://cloud-images.ubuntu.com/trusty/ doesn't have a current symlink? Every other release I've checked on cloud-images does have one.
<dholbach> good morning
<darkxst> cjwatson, thanks, noted, didnt realise that, but just asked since dholbach was piloting
<caribou> pitti: thanks for the upload. There are FTBS with i386 & powerPC I need to investigate
<bdrung_work> hi, do we have a packaging guide / wiki page that explains the versioning used in Ubuntu?
<bdrung_work> dholbach, ^
<pitti> caribou: en effet -- "buffer overflow detected" sounds bad
<dholbach> bdrung_work, http://packaging.ubuntu.com/html/debian-dir-overview.html#the-changelog
<pitti> caribou: armhf is also 32 bit, curious that it didn't affect that
<caribou> pitti: fwiw, it builds ok, locally on i386. Testing powerpc atm
<rbasak> bdrung_work: define "versioning used". Does https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/1411233 help you?
<ubottu> Launchpad bug 1411233 in Ubuntu Packaging Guide "Talk more about version strings" [Medium,Triaged]
<bdrung_work> dholbach, oh, that is quite minimalistic
<dholbach> yeah, I didn't have time to import the article yet :-/
<dholbach> but maybe somebody else can?
<bdrung_work> rbasak, yes, something like that
<bdrung_work> a search revealed this blog post, which is quite nice: http://www.ducea.com/2006/06/17/ubuntu-package-version-naming-explanation/
<rbasak> That looks good.
<pitti> infinity, Laney: with your release hat on, do you have an opinion about bug 1489702?
<ubottu> bug 1489702 in systemd (Ubuntu) "FFE: two small new features in networkd and machinectl" [Undecided,New] https://launchpad.net/bugs/1489702
<Laney> pitti: Will look in a bit, just cleaning up something else
<sitter> pitti: any thoughts on out-of-space errors on ppc64el test runs? can these be retried somehow? should we simply override them? http://autopkgtest.ubuntu.com/packages/u/umbrello/wily/ppc64el/ && http://autopkgtest.ubuntu.com/packages/k/kate4/wily/ppc64el
<pitti> sitter: thanks, I'll have a look; retrying won't give us much while /tmp/ keeps being too small for these large packages, but I'll move /tmp/ to the big data partition and try again
<sitter> lovely, thanks :)
<doko> caribou, rsyslog ftbfs
<caribou> doko: I know, working on it
<caribou> doko: for some reason, the i386 builds locally
<pitti> sitter: while reviewing regressions: http://autopkgtest.ubuntu.com/packages/g/gwenview/wily/amd64/ seems real
<caribou> doko: is it possible to rerun the i386 build to check for false positive ?
<pitti> sitter: bigger /tmp set up, I reran these two tests
<sitter> thanks
<caribou> pitti: ^^^
<pitti> caribou: yes, sure
<pitti> caribou: but it's not a false positive then, it'd be a race condition
<caribou> pitti: hmm, maybe
<pitti> caribou: re-ran
<caribou> pitti: it fails on a unit test, that never ran before
<caribou> pitti: on my local powerpc sbuild, it cannot seem to find gcc5
<caribou> pitti: wrong, it fails on gcc5, looking into it
<pitti> caribou: hm, but not on a local build?
<caribou> pitti: no that powerpc is on local build, I get different failure on PPA
<caribou> s/PPA/builder
<pitti> sitter: green again
<sitter> thanks pitti
<pitti> sitter: thanks for pointing out
<pitti> sitter: a bunch of valid candidates now \o/
<pitti> sitter: gwenview still needs sorting out, though
<sitter> pitti: yeah looking into that right now
<sitter> pitti: question related to that... if I define the needs-recommends restriction it won't actually install recommends of the build deps will it?
 * pitti double-checks
<pitti> (it's not meant to)
<pitti> sitter: correct
<sitter> in particular the tests are missing runtime stuff that should be pulled in via recommends of relevant libraries. alas since recommends are not installed for build deps that kinda renders the tests broken ^^
<pitti> sitter: that is, it won't install it for "build-needed" when building the package
<pitti> sitter: but it *will* install them if you have "Depends: @builddeps@"
<pitti> sitter: hm, I thought the tests are just those that run during package build anyway -- how come they build on the buildds then?
<pitti> sitter: or does the package build just build the tests, but not run them?
<sitter> .PHONY: override_dh_auto_test
<pitti> ah
<pitti> and then debian/tests build the package and just call the built tests
<pitti> so yeah, then "Depends: @" will just install all binary packagse and their depends/recommends; but if you need additional pacakges for tests only, they need to go there
<pitti> or you do "Depends: @, @builddeps@", but that would install a lot more than you'd need
 * sitter tries
<rbasak> pitti: I keep seeing bugs that involve init.d failures where the systemd wrapper means that we didn't get useful logging in the bug report. I think we discussed this and agreed it was a wishlist item maybe for apport. Do we have a bug on this?
<pitti> rbasak: we don't? shouldn't that be in JournalErrors.txt at least?
<rbasak> pitti: AFAICT, not all of the stderr from init.d ends up in the snippet that apport sends. Maybe it's filtering too much?
<rbasak> pitti: I want to see all of the stdout and stderr from init.d really.
<rbasak> pitti: if you think it should be doing that already I can point out a specific example when I next come across one.
<pitti> rbasak: that mostly depends on the init.d script; most of them redirect logging or double fork etc. (as sysvinit doesn't have a concept of logging)
<rbasak> pitti: I was prompted by bug 1490607 which isn't directly this issue I don't think.
<ubottu> bug 1490607 in postfix (Ubuntu) "Improve feedback of postfix systemd unit start failure" [Undecided,New] https://launchpad.net/bugs/1490607
<pitti> rbasak: i. e. the problem is mostly that init.d scripts are usualy written in a way to *not* show stdout/stderr..
<rbasak> pitti: I have no complaint if the init.d script does not output the failure reason when run by hand without systemd.
<pitti> rbasak: journalerrors> wow, this guy seriously needs to replace his hard disk :)
<pitti> Aug 31 13:12:52 hostname postfix/trivial-rewrite[25335]: warning: /etc/postfix/main.cf, line 118: overriding earlier entry: smtp_sasl_security_options=noanonymous
<pitti> Aug 31 13:12:52 hostname postfix/trivial-rewrite[25335]: fatal: /etc/mailname: file has 2 hard links
<rbasak> pitti: my feeling is that something regressed on this since the systemd switch though. I seem to get more bug reports through apport with init.d start failures with no explanation than before
<rbasak> pitti: but leave it with me. I'll find you a more concrete example when I next come across one.
<pitti> rbasak: this particular bug is just "my hard disk is totally screwed up", so it's uninteresting
<pitti> rbasak: for postfix specifically I doubt it, it only ever had an init.d script; for packages which *do* have an upstart job it's plausible as often the upstart job is simpler/more robust than the sysvinit script
<pitti> in particular, logging in sysvinit is a disaster (which was one of the reasons for the ever-growing number of people crying for something more modern)
<rbasak> Hmm. It could be because of losing the upstart job, good point.
<snikitin> Hi guys, I tried to compare hash sums of images from here http://cloud-images.ubuntu.com/trusty/current/ but image names in file with sums SHA256SUMS differ from actual images names. Is it ok?
<ogra_> infinity, ^^^ ?
<ogra_> snikitin, sounds like a bug
<rbasak> snikitin: I see files that are not listed, but no specific mismatches. Can you provide an example?
<snikitin> rbasak: For example file vivid-server-cloudimg-amd64-disk1.img. In SHA256SUMS it names like ubuntu-14.04-server-cloudimg-amd64-disk1.img rather than vivid-server-cloudimg-amd64-disk1.img
<snikitin> is it ok?
<rbasak> snikitin: the name listed in SHA256SUMS does still exist as a file you can download, no? So surely you can just use that one?
<rbasak> utlemming: ^^
<rbasak> utlemming: still maybe not great that SHA256SUMS doesn't include every listed name, maybe?
<Odd_Bloke> snikitin: rbasak: We had a problem with trusty daily images, so the latest is currently hot-symlinked to the latest release.
<Odd_Bloke> Which is why you're seeing weird things.
<Odd_Bloke> Because things are weird. ;)
<Odd_Bloke> A new trusty build which should fix things is in progress.
<Odd_Bloke> (vivid-server-cloudimg-amd64-disk1.img is a daily image name, ubuntu-14.04-server-cloudimg-amd64-disk1.img is a release image name)
<snikitin> Odd_Bloke: I just worried that in all ubuntu versions names in SHA256SUMS are tha same with real names, exept trusty. In OpenStack we got one failing job because of this, and I wanted to know is it normal, or it's a bug and you fixed it soon
<Odd_Bloke> snikitin: It's a bug which we're fixing now; the images prefixed with ubuntu-14.04 wouldn't normally exist for a daily.
<snikitin> Odd_Bloke: great! thank you for your halp
<snikitin> help*
<Odd_Bloke> snikitin: Happy to halp! ;)
<snikitin> :)
<pitti> wgrant: hey, how are you? can you please have a look at bug 1376296?
<ubottu> bug 1376296 in Launchpad itself "libusermetrics translations not imported into LP, and missing from langpack exports" [Undecided,New] https://launchpad.net/bugs/1376296
<LocutusOfBorg1> hi folks, is requestsync tool broken today?
<LocutusOfBorg1> requestsync gimp-help
<LocutusOfBorg1> W: Target release missing - assuming wily
<LocutusOfBorg1> E: 'gimp-help' doesn't appear to exist in Debian 'sid'
<LocutusOfBorg1> seems that is not finding sid
<LocutusOfBorg1> same for requestsync
<LocutusOfBorg1> and syncpackage
<LocutusOfBorg1> ubuntutools.lp.udtexceptions.PackageNotFoundException: 'flightcrew' doesn't appear to exist in Debian 'sid'
<wgrant> pitti: Hm, what's the confusion?
<wgrant> pitti: https://translations.launchpad.net/ubuntu/wily/+source/libusermetrics/+imports and https://translations.launchpad.net/ubuntu-rtm/15.04/+source/libusermetrics/+imports but have unapproved imports
<pitti> wgrant: it looks like libusermetrics builds a translations.tar.gz, but there isn't anythig in the import queue nor the distro translations
<wgrant> pitti: It looks like that package has never had its files approved.
<wgrant> Oh
<wgrant> You linked to the vivid import queue
<pitti> wgrant: aah! I looked at https://translations.launchpad.net/ubuntu/vivid/+source/libusermetrics/+imports
<pitti> wgrant: probably because LP says that vivid is the preferred translation target
<wgrant> pitti: Ah, I forget where that's set.
<pitti> wgrant: thanks, I'll approve them
<wgrant> https://translations.launchpad.net/ubuntu/+configure-translations
<wgrant> if you want to change it
<wgrant> pitti: But you'll still need to approve it on both ends
<pitti> right, done
<pitti> wgrant: thanks for pointing out
<wgrant> np
<caribou> pitti: regarding the rsyslog ftbs, it fails on a testbench tool that is (from upstream's own opinion) third grade citizen.
<caribou> pitti: now, I'm not even able to reproduce the failure in a PPA
<pitti> caribou: ah, so the crash is in the test itself, not rsyslog?
<pitti> caribou: if this is a new test, and known upstream, seems legit to disable that one?
<caribou> pitti: yes, the testbench runs ./tcpflood which is known not to be too good
<caribou> pitti: tcpflood is used in many tests, it is also the culprit on powerpc but in a different test
<caribou> pitti: I'm suspicious that it may run out of memory on the official builder, which would be why I cannot reproduce
<caribou> pitti: or it lies in a difference in builders used for PPA and the archive
<caribou> pitti: FYI, all the testbench tests are new, they weren't used in 7.4.4
<pitti> caribou: ack; could you look into disabling that problematic test without disabling the whole test suite completely? (that would be a shame)
<caribou> pitti: I'll have a  look at tests that use tcpflood (which is the programs that exist with the buffer overflow)
<caribou> pitti: otherwise, we may see other FTBS later also caused by tcpflood
<pitti> caribou: sounds good
<caribou> pitti: no luck, it's used mostly everywhere. Can we find the memory setup of the builders used for i386/powerpc ?
<caribou> pitti: if I can reproduce the buffer overflow, most probably I can fix it
<pitti> infinity: ^ do you know?
<pitti> caribou: you could try building it in a RAM limited container?
<caribou> pitti: k, will try that. Or I can run my kvm vm with very limited memory. I'll try this first
<pitti> lxc.cgroup.memory.limit_in_bytes = 1500M
<pitti> for example
<pitti> caribou: right, or that
<caribou> pitti: just that it's all setup already
<LocutusOfBorg1> doko, do you plan to sync llvm-3.7?
<ricotz> LocutusOfBorg1, it is not syncable
<LocutusOfBorg1> why ricotz ffe needed or merge issue?
<ricotz> ftbfs
<LocutusOfBorg1> ack, on i686?
<ricotz> LocutusOfBorg1, yes
<LocutusOfBorg1> actually 3.7 has never been built on i386 and powerpc
<ricotz> builds on debian though
<ricotz> it is needed for mesa 11, so all archs are needed
<ricotz> LocutusOfBorg1, the source builds, but the tests get stuck/fail
<LocutusOfBorg1> yes, I see
<LocutusOfBorg1> so maybe merge 3.7 final with testsuite disabled
<LocutusOfBorg1> and the conflict+replace stuff
<LocutusOfBorg1> the problem might be i586 vs i686?
<ricotz> LocutusOfBorg1, in case you want to look into it https://launchpad.net/~xorg-edgers/+archive/ubuntu/ppa/+sourcepub/5334022/+listing-archive-extra
<LocutusOfBorg1> well I was already looking at it :)
<tjaalton> doko: I hear you're doing rebuilds. I'm looking at migrating xcb-util..
<tjaalton> just fyi
<doko> tjaalton, the binNMUs are done
<tjaalton> doko: oh you did those already, sweet
<doko> tjaalton, "already" after three weeks
<tjaalton> heh, well I didn't notice them before today
 * Laney learns about git pushInsteadOf
<caribou> pitti: ok, I have a clearer view of the rsyslog ftbs :
<caribou> pitti: ./tcpflood fails on a FORTIFY_SOURCE error caused by a buffer overflow
<pitti> caribou: nice! you can reproduce?
<pitti> caribou: if it hits the stack protector the bug should be fairly well pin-pointed in gdb?
<caribou> pitti: no, it only happens on the archive builders, not on kvm or local sbuild
<ricotz> doko, hi, is libav -> ffmpeg on your list too?
<caribou> pitti: yes, but I need to reproduce it first
<caribou> pitti: there is something different with the archive builder that makes it fail
<pitti> caribou: did you try building against -proposed?
<cjwatson> caribou: try diffing your local sbuild log against the one produced by LP
<caribou> pitti: isn't that what sbuild do by default ?
<caribou> cjwatson: thanks will do
<cjwatson> that's often a good technique for spotting differences (though you have to weed out things that don't matter)
<cjwatson> caribou: sbuild may or may not build against -proposed depending on the schroot configuration
<pitti> caribou: depends how you configure it, but not usually
<caribou> pitti: ok, will check that too
<doko> ricotz, why should it be?
<ricotz> doko, while speaking of no-change rebuilds to transition to the ffmpeg libs, e.g. handbrake
<LocutusOfBorg1> dholbach, can I ask you a sync for gimp-help and flightcrew ?
<LocutusOfBorg1> they are patches merged in debian
<doko> ricotz, create a transition tracker and send a bug report or ask Laney
<Laney> Not just me, you can ask anyone in https://launchpad.net/~ubuntu-transition-trackers/+members#active
<sitter> pitti: gwenview fixed. thanks for pointing it out
<pitti> sitter: yay you
<dholbach> LocutusOfBorg1, flightcrew is still in incoming
<ricotz> doko, Laney, ok, I thought there was a tracker already, I am not familiar with the process though
<dholbach> LocutusOfBorg1, both are still in incoming......................
<LocutusOfBorg1> ok, I'll ping back then
<dholbach> LocutusOfBorg1, syncing gimp-help from Debian drops the -da package
<brendand> if my package foo depends on bar (>= 0.23) and the installed version of bar is 0.5 shouldn't foo get installed and bar be upgrade to 0.23?
<brendand> apt seems to be telling me bar cannot be installed
<cjwatson> brendand: That means that apt is trying but the combination is uninstallable for some other reason.  Try "apt-get install foo bar" to get it to drill down one more level
<LocutusOfBorg1> dholbach, I see, damn
<LocutusOfBorg1> bad changelog is bad
<LocutusOfBorg1> :(
<dholbach> I checked the diff
<LocutusOfBorg1> yes, me too now
<LocutusOfBorg1> I blindly trusted doko's upload
<rtg> doko, do you know if there is a fix in the pipeline for Wily gcc-5-powerpc64le-linux-gnu ? Still getting a couple of build errors in the kernel
<rtg> gcc: error: unrecognized argument in option '-mabi=elfv2'
<rtg> gcc: error: unrecognized command line option '-mlittle-endian'
<bdmurray> tkamppeter: Could you have a look at bug 1479267?
<ubottu> bug 1479267 in ghostscript (Ubuntu) "Brother MFC-L8650CDW cuts top of the page " [Medium,Triaged] https://launchpad.net/bugs/1479267
<octoquad> Greetings, is it possible to get dark theme support in for USC before UI freeze? https://bugs.launchpad.net/bugs/899878
<ubottu> Launchpad bug 899878 in Ubuntu GNOME "Software center have hardcoded colors and shows white font on white bg" [High,In progress]
<doko> cjwatson, Laney: any idea about https://launchpad.net/ubuntu/+source/oasis/0.4.4-2build2 ?
<doko> rtg, I didn't see anything change.
<doko> rtg, or is this the cross compiler?
<cjwatson> doko: no.  that looks like it should reproduce locally though
<rtg> doko, cross compiler
<tkamppeter> bdmurray, thanks, I will look.
<Laney> octoquad: Will look tomorrow on my patch pilot shift
<Laney> I had that tab open already but was away for the last few days, sorry for delay
<Laney> doko: nope, does it happen locally?
<Laney> oh, funny, cjw_atson just said that
<octoquad> Thanks Laney
<pitti> infinity, mdeslaur, slangasek, stgraber, kees: TB meeting reminder in 12 mins
<mdeslaur> pitti: ack, thanks
<doko> zyga, checkbox / plainbox ping ...
<zyga> doko: hey, thanks for pinging me
<zyga> doko: we've fixed all but one issues, we should give you a patch for wily tomorrow mid-day
<doko> zyga, ta
<doko> cjwatson, Laney: oasis build locally
<doko> pitti, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/armhf/k/kdepim/20150901_135519@/log.gz any idea how to investigate? build-deps install fine
<pitti> doko: in meeting now, will debug tomorrow
<pitti> doko: yes, I can shell into an affected container; probably some postinst/trigger failure, or cgmanager hiccup (that's what it was the last time)
<infinity> caribou: i386 builders for archive and PPA are literally identical.
<slangasek> (yaaaaaay)
<cjwatson> doko: sorry, I can't find the problem here either, but it seems far too many levels down to be an issue with the builders; probably just some as-yet-unidentified environmental difference
<brendand> cjwatson, it seems apt-get install foo bar just works, so i'm none the wiser
<cjwatson> brendand: can you give a real transcript?
<rbasak> infinity: ovs will "suddenly link" to dpdk, but I believe there will be a separate package in ovs that does it, so I think it meets the spirit of that requirement.
<brendand> cjwatson, http://paste.ubuntu.com/12246760/
<cjwatson> brendand: and 'apt-cache policy python3-plainbox' ?
<ricotz> doko, Laney, https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/1491048
<ubottu> Launchpad bug 1491048 in ffmpeg (Ubuntu) "Transition from libav" [Undecided,New]
<Laney> ricotz: would have been nice if you used archive versions
<Laney> but thanks
<ricotz> Laney, this would be unwise in case of failures ;)
<ricotz> there are two at least which are toolchain related afaics
<ricotz> Laney, I am going to repush the succeeded packages with archive versions later
<Laney> ricotz: ok thanks, won't look today anyway
<ricotz> so you can pocket-copy them, I assume that is what you want
<Laney> yeah
<Laney> don't have to mess around building the source package
<ricotz> ok, no need to rush
 * Laney goes climbing
<Laney> ttyl
<hallyn> mbiebl: hey - probably doesn't really matter, but sytemd installs in containers complain because they can't set file capabilities for systemd-detect-virt.
<hallyn> of course, implementing file caps for user namespaces is on my todo list,
<hallyn> but my todo list isn't a short one
<Logan> cjwatson: thanks for handling all of my ~ubuntu-archive requests! I don't think ddccontrol-db was actually synced in Bug 1407398, though
<ubottu> bug 1407398 in ddccontrol-db (Ubuntu) "please unblacklist ddccontrol-db and sync from Debian unstable" [Undecided,Fix released] https://launchpad.net/bugs/1407398
<doko> cyphermox, I assume you care about the installer ... http://people.canonical.com/~ubuntu-archive/nbs.html  could you look at maas-enlist-udeb
<mbiebl> Laney: hi
<mbiebl> oops, meant hallyn
<mbiebl> hallyn: we already ignore the exit code of setcap
<mbiebl> so install will not fail, you'll only get a warning message
<mbiebl> which I think is ok in this case
<hallyn> mbiebl: right, but it also means it doesn't get the caps it needs - what functions will fail in that case?
<mbiebl> hallyn: you won't be able to run systemd-detect-virt as unprivileged user
<mbiebl> not sure if this a huge concern for a container :-)
<hallyn> mbiebl: well a container is precisely where you might need it :)  but ok.
<hallyn> not much you can do about it until i fix it in the kernel;
<hallyn> and i prefer it this way to having duplicat setuid-root logic
<hallyn> mbiebl: thanks
<hallyn> (was mainly wondering whether this should change my priorities)
<Unit193> https://packages.qa.debian.org/s/screen/news/20150901T153110Z.html would likely be very good to sync to wily.
<mbiebl> hallyn: well, you might also want your script if you are *not* in a container
<mbiebl> and I assume if systemd-detect-virt has no caps, it would still return != 0
<mbiebl> so would work, in a sense :-)
<hallyn> mbiebl: heh, actually that's good enough :)
<hallyn> Unit193: agreed - saw the security notice last night
<mterry> tinoco, poke about bug 1409904.  So those two trusty patches are ready for upload?  Does tgt not need a patch?
<ubottu> bug 1409904 in tgt (Ubuntu Trusty) "Needed patches for InfiniBand Support: Flow Steering and Offload Support + Fixes" [Undecided,In progress] https://launchpad.net/bugs/1409904
<tinoco> mterry: tgt needs iser support (trusty)
<tinoco> mterry: https://launchpadlibrarian.net/213595717/trusty_tgt_1.0.43-0ubuntu5.debdiff
<tinoco> mterry: there are 3 patches for trusty (libibverbs, libmlx4 and tgt)
<mterry> tinoco, huh.  I see that on the file list for that bug, but not the comments
<tinoco> mterry: i may have hidden comments
<mterry> tinoco, so these don't have ABI breaks?
<tinoco> mterry: sorry, this was long standing bug with several discoveries
<tinoco> mterry: nope, we are only discarding support for 2.6.32 < kernels
<cjwatson> Logan: hmm?  https://launchpad.net/ubuntu/+source/ddccontrol-db/+publishinghistory
<tinoco> which does not break things.
<tinoco> mterry: my first impression was wrong.
<tinoco> good to go with this.
<Logan> cjwatson: whoops, I'm blind
<Logan> cjwatson: oh I know what happened - I saw that it built on Maverick, which confused me :P
<cjwatson> Logan: right, I had to copy it back from an older series with binaries, since it had already been built in the Ubuntu archive
<Logan> yep, it makes sense now
<Logan> thanks again!
<cjwatson> Logan: but it's just a database, don't expect it actually needs to be built again
<cjwatson> np
<Logan> I also think there probably needs to be a process removals run soon
<Logan> I've seen a decent number of packages that have no Ubuntu delta, were deleted from Debian, but are still in Wily
<cjwatson> both Steve and I have done some recentlyish
<Logan> ah okay
<cjwatson> there are some other constraints, like rdeps or seededness
<Logan> right
<cjwatson> it's unfortunately not very visible - p-r needs to be rewritten to be much less of a purely interactive tool
<brendand> cjwatson, http://paste.ubuntu.com/12248134/
<cjwatson> brendand: ok, next thing I'd try would be 'apt-get -oDebug::pkgProblemResolver=true install checkbox-converged-community' to see why it decided not to choose the resolution that involved installing python3-plainbox
<brendand> cjwatson, i think i see it now,  i'll try something and hopefully it will work
<brendand> cjwatson, i assume specifying both packages tells apt to damn its own judgement and just do what you say?
<cjwatson> brendand: depends on the exact nature of the problem, but it does apply a bit more force
<mterry> tinoco, one note: when doing an SRU, (I at least) favor a version number like ubuntu1.1 or ubuntu4.1 rather than ubuntu2 or ubuntu5 -- helps distinguish from a release that might be in current Ubuntu versions
<cjwatson> brendand: given that this operation involves removing a bunch of packages including ubuntu-desktop, I suspect you're in a situation where apt is trying to assess the relative harm caused and being more specific might tip the score over a threshold
<tinoco> mterry: yep, arges has already advised me on that. will do next time!
<tinoco> mterry: i wrongly relied on dch -i
<tinoco> mterry: tks
<mterry> danjared, so per https://code.launchpad.net/~noskcaj/ubuntu/wily/dell-dup/dh-python/+merge/264080 should a removal request for dell-dup happen?
<danjared> mthaddon: yes, that's fine. we're not using it, and it's probably just confusing to have it there if we're not using it at all. if we need it again, I can work on getting it readded, but we're working on some completely different stuff for firmware updates these days anyway
<TJ-> Is there a way to prevent systemd from creating generator targets for hot-plug disks? Currently it is causing very long delays at boot-time but I'm not sure at what point systemd decided those hot-plug devices should be added to the boot-time tasks
#ubuntu-devel 2015-09-02
<pitti> Good morning
<pitti> infinity: slangasek's bug 1491145 reminded me of debian bug 779559 again; is that still something you can/want to work on, or should I try?
<ubottu> bug 1491145 in dpkg (Ubuntu) "trigger tests for updated reverse test dependencies" [Medium,Triaged] https://launchpad.net/bugs/1491145
<ubottu> Debian bug 779559 in dpkg "dpkg-source: Add test dependencies to .dsc" [Wishlist,Open] http://bugs.debian.org/779559
<infinity> pitti: Ahh, oops.  I knew there was something I was forgetting.  I don't care where the patch comes from, now that we all agree on what the output should be.
<infinity> pitti: So, if you're keen to dive into the Perl, be my guest, it should be trivial (ab)use of some existing methods and a few lines of glue, IMO.
<pitti> infinity: I won't have much time for it either this week, just asking
<infinity> pitti: But yeah, it's on my TODO, just slightly forgotten, ish.
<pitti> but without having looked into it yet it doesn't sound particularly difficult?
<pitti> (I'll probably think otherwise after I've seen the Perl :) )
<infinity> pitti: Most of the dep parsing stuff is nicely broken out into reusable methods, ish.
<infinity> pitti: So, it really should just be "take control field X, apply dep parsing method Y, vomit into new control field Z".
<infinity> pitti: With a bit of extra open/read glue because it's another control file.  Though, dpkg-source might already read that now to set the Test: types.
<infinity> pitti: Anyhow, I'm going to sleep.  Remind me again if you don't get to it, and I will.
<dholbach> good morning
<caribou> infinity: pitti: well I'm able to reproduce the rsyslog build failure on a Trusty host with a Wily schroot but not on a Wily host & wily schroot
<pitti> caribou: ah, the buildds run a trusty or even precise kernels, so that might be it
<caribou> pitti: thanks to cjwatson's suggestion of diffing the build logs
<caribou> pitti: well now I can reproduce so I should be able to fix it
<Laney> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<doko> jamespage, libcommons-cli-java ping
<zyga> doko:
<zyga> doko: I'm working on the patch all morning, it should be ready soon (plainbox)
<cjwatson> pitti: almost entirely trusty, with the exception of the non-virtual armhf builders
<TJ-> Is there a way to prevent systemd from creating generator targets for hot-plug disks? Currently it is causing very long delays at boot-time but I'm not sure at what point systemd decided those hot-plug devices should be added to the boot-time tasks
<jamespage> doko, hullo
<doko> jamespage, could you have a look at libcommons-cli-java ping to de-mavenfy the package?
<jamespage> doko, I need to clear through the openstack milestone 2 blockages first, and then I can take a peek
<jamespage> doko, is it a new upstream version?
<jamespage> for other packages I've just reverted the debian folder to a previous ant based one
<doko> jamespage, was walking through the packages with ebourg which ones could be synced
<jamespage> anyone know if there is a problem with upload queue processing?
<cjwatson> jamespage: details?
<jamespage> hmm - maybe its just email notifications
<cjwatson> still details?
<jamespage> cjwatson, checking
<cjwatson> I made some changes to upload email notifications recently so I would rather like to know if there's a problem with them
<jamespage> cjwatson, did that involve adding some headers per chance?
<cjwatson> "some changes" -> completely refactored
<cjwatson> jamespage: yes, they now have X-Launchpad-Message-Rationale and X-Launchpad-Notification-Type
<jamespage> cjwatson, specifically I've done a few uploads this morning - python-mock, python-django-compressor, and a load of PPA uploads
<jamespage> cjwatson, I've not seen email notifications for them since...
<jamespage> 1930 ish yesterday
<jamespage> that's 'Accepted' notifcations
<cjwatson> jamespage: the logs claim to have mailed you about python-mock this morning
<cjwatson> jamespage: http://paste.ubuntu.com/12252145/
<cjwatson> jamespage: could you check that it hasn't been filtered off somewhere?
<jamespage> cjwatson, that's my suspicion
<jamespage> cjwatson, looking atm
<jamespage> cjwatson, do you happen to know the X-Launchpad-Message-Rationale they should have?
<jamespage> 'Changed-By'?
<cjwatson> jamespage: Probably "Requester"
<cjwatson> or possibly "Changed-By"
<jamespage> cjwatson, ah-ha - found them
<cjwatson> if you signed the upload that will take precedence and it should be "Requester"
<cjwatson> (which is slightly vague because that level of the code can't currently tell the difference between uploads and syncs - may change in future)
<jamespage> cjwatson, I see a requester tagged email for the upload, and then a changed-by for the proposed->release pockey migration
<cjwatson> Right
<cjwatson> Because you didn't request that copy
<cjwatson> Also, X-Launchpad-Notification-Type: package-upload
<jamespage> yes - thanks for the clarification
<cjwatson> It should be more filterable now, but it's true that some configurations may require tweaking
<doko> arges, please finish transitions if you start them (libecap). now hopefully done
<doko> arges, argh, no. squid3 needs an update
<rbasak> I was supposed to do a squid3 merge to fix that, but didn't manage it before feature freeze
<rbasak> I'd forgotten about the libecap complication
<cjwatson> jamespage: documented on https://help.launchpad.net/LaunchpadMessageRationale now
<LocutusOfBorg1> Laney, please ping me if you intend to do any virtualbox related work
<LocutusOfBorg1> I'm working on an MRE
<LocutusOfBorg1> https://titanpad.com/IVSgUZauQV
<Laney> LocutusOfBorg1: should I sponsor the lts thingy or not?
<LocutusOfBorg1> I don't know
<LocutusOfBorg1> should we really split the package an maintain two?
<LocutusOfBorg1> also I prefer to start from a virtualbox-lts-wily instead
<LocutusOfBorg1> but I guess all the effort is waiting for an MRE and debian bug 794466
<ubottu> Debian bug 794466 in src:virtualbox "Virtualbox might not be suitable for Stretch" [Critical,Open] http://bugs.debian.org/794466
<Laney> I don't know much about the LTS stack
<Laney> does every rdep of the renamed stuff need to be renamed too?
<Laney> Anyway, happy to wait if you want
<Laney> slangasek: bug #1429327 is in the queue but it looks like you're handling it, right?
<ubottu> bug 1429327 in multipath-tools (Ubuntu) "Boot from a unique, stable, multipath-dependent symlink" [Medium,In progress] https://launchpad.net/bugs/1429327
<Laney> (unsubscribed sponsors, feel free to re-add)
<LocutusOfBorg1> Laney, I guess so, but we can't maintain an lts-* virtualbox package at each release...
<ricotz> Laney, regarding https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/1491048 -- the ppa contains proper versioned source of the succeeded rebuilds
<Laney> ricotz: thanks!
<LocutusOfBorg1> I would appreciate a feedback from who uploaded the lts breaking-rdeps xserver-xorg-core
<ubottu> Launchpad bug 1491048 in ffmpeg (Ubuntu) "Transition from libav" [Undecided,New]
<Laney> LocutusOfBorg1: Maybe a thread on -devel is in order
<doko> diwic, pulseaudio has an unconditional b-d on trust-store
<tjaalton> LocutusOfBorg1: what broke?
<diwic> doko, and trust-store is not in main...?
<diwic> doko, oh, it is not :-/
<LocutusOfBorg1> tjaalton, bug 1424769
<ubottu> bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [Medium,Triaged] https://launchpad.net/bugs/1424769
<diwic> doko, thanks.
<tjaalton> LocutusOfBorg1: ah, so need renamed backports for lts-*
<LocutusOfBorg1> I have to upload a virtualbox-lts-{utopic,vivid,wily} and so on?
<tjaalton> utopic isn't supported anymore
<tjaalton> but yes
<Laney> tjaalton: could we do that more automatically?
<LocutusOfBorg1> and maintain all of them?
<tjaalton> LocutusOfBorg1: it's no different from stock $release
<Laney> or at least find out what gets broken as a start
<tjaalton> well this was all done before me
<LocutusOfBorg1> and specially people should be aware of a different vbox package
<tjaalton> dunno why virtualbox didn't get the love
<LocutusOfBorg1> well what does happen when an user has mesa-lts-utopic and switch to mesa-lts-vivid?
<LocutusOfBorg1> is that automatic? virtualbox gets removed, right?
<LocutusOfBorg1> he has to know about virtualbox-lts-wily
<LocutusOfBorg1> hoping somebody uploaded it together with the rest of the lts stack
<tjaalton> one does not "switch to mesa-foo"
<tjaalton> that's never supported
<LocutusOfBorg1> well the user notices a new mesa is available
<tjaalton> how exactly?
<LocutusOfBorg1> apt?
<LocutusOfBorg1> synaptic?
<Laney> it's new packages
<tjaalton> ooh, a new package
<LocutusOfBorg1> yes
<Laney> you would have to go looking for it
<tjaalton> it's not shown in updates
<Laney> but uninstallability is a real issue
<LocutusOfBorg1> somebody should upload the virtualbox new lts-wily package together with mesa-lts wily I guess
<tjaalton> yes
<tjaalton> sometime between nov-jan
<Laney> and -vivid for 14.04.3
<Laney> how can we tell which packages need this treatment?
<tjaalton> so why wasn't this an issue for precise lts backports?
<tjaalton> search for packages that provide xorg-vide-abi-foo
<tjaalton> -video
<tjaalton> err
<tjaalton> virtualbox-guest-x11 just Provides xorg-driver-video
<tjaalton> hm no
<tjaalton> the xserver provides the abi of course, drivers depend on it
<tjaalton> got that all wrong
<Laney> is it anything that depends on xorg-video-abi-XXX?
<tjaalton> right
<Laney> seems it is just virtualbox + xorg + drivers
<Laney> tjaalton: is there some documentation/process for the lts backports that we an add this to?
<tjaalton> no
<tjaalton> just scripts for renaming stuff
<Laney> can you take a note to add the r-deps check maybe? :)
<tjaalton> 14:31 < mlankhorst> no, we never did any virtualbox backport
<tjaalton> also, https://wiki.ubuntu.com/Kernel/LTSEnablementStack says that newer point-release are not (recommended) for virtual machines
<tjaalton> so dunno, i'd rather not support it tbh
<Laney> I think that probably means as guest
<Laney> it's not reasonable to expect people to consider if they might ever want to install virtualbox when originally installing the LTS
<tjaalton> that's where you need the package, not on host
<doko> barry, restored zope.security changes, needed for schooltool
<Laney> tjaalton: Oh right, that's where the broken package is - meh, this sucks as an experience though
<Laney> https://ubuntu.com/download/desktop is all "get 14.04.3"
<diwic> doko, tvoss is going to work on getting trust-store into main
<diwic> doko, then we can redo the build
<doko> diwic, tvoss: this is fine too, but not the problem. trust-store isn't built on all archs
<diwic> doko, but it is not a build dependency on all archs, is it?
 * diwic checks
<tvoss> diwic, just let me know what you want me to do :)
<diwic> doko, libtrust-store-dev is only listed as a build-dep for armhf, i386, and amd64
<diwic> doko, and I believe trust-store builds on all those three, right?
<doko> diwic, tvoss: my bad ... so yes, starting writing MIRs for trust-store and all its dependencies
<Laney> cyphermox: are you handling bug #1432062? i.e. can I remove sponsors?
<ubottu> bug 1432062 in multipath-tools (Ubuntu) "multipath-tools-boot: support booting without user_friendly_names on devices with spaces in identifiers" [Medium,Confirmed] https://launchpad.net/bugs/1432062
<TJ-> Is there a way to prevent systemd from creating generator targets for hot-plug disks? Currently it is causing very long delays at boot-time but I'm not sure at what point systemd decided those hot-plug devices should be added to the boot-time tasks, or how to safely delete them
<tjaalton> LocutusOfBorg1: are you willing to test a lts-vivid build of vbox?
<LocutusOfBorg1> tjaalton, I'm uploading it right now on my ppa
<tjaalton> erm, the debdiff should look something like http://sprunge.us/LUTL
<LocutusOfBorg1> tjaalton, yes sure, it is basically renaming files
<tjaalton> but if you miss anything it's gonna fail, this was done with a script
<LocutusOfBorg1> actually the packaging changes not too much, so I applied the debdiff for utopic and it applied almost cleanly
<LocutusOfBorg1> after a sed to vivid
<LocutusOfBorg1> let's see the upload how it goes
<tjaalton> vbox build-depends on gcc-4.9? that won't work
<tjaalton> heh, and libglu1-mesa-dev which isn't coinstallable with the backports
<tjaalton> so no it's not going to work
<Laney> doko: kodi needed FFe, also there was a sponsor bug to close, please check before syncing
<LocutusOfBorg1> tjaalton, yes, gcc-4.9 was forced to avoid use of gcc-5 in Debian
<LocutusOfBorg1> for glu1-mesa-dev let me test once it is built :)
<tjaalton> does trusty have gcc-4.9? it didn't build here because of it
<LocutusOfBorg1> tjaalton, the problem was gcc-5 too new, so we forced gcc-4.9
<caribou> pitti: I think I found the fix for rsyslog's FTBS.
<LocutusOfBorg1> any compiler < 4.9 is fine
<caribou> pitti: How should I push the fix ? debdiff or MP ?
<tjaalton> LocutusOfBorg1: so a backport can't be reliably scripted
<LocutusOfBorg1> well not when gcc has a major release
<pitti> caribou: I'd prefer a debdiff, much easier (on the original sponsoring bug is fine, or email, or pastebin -- whatever you prefer)
<pitti> caribou: and nice work!
<caribou> pitti: I'll push a debdiff on the merge bug
<LocutusOfBorg1> the problem was a bug in gcc-5 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693 fixed here https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=218248
<ubottu> gcc.gnu.org bug 65693 in rtl-optimization "[4.8/4.9 Regression] ICE in assign_by_spills, at lra-assigns.c:1419" [Normal,Resolved: fixed]
<caribou> pitti: was rather nasty : tcpflood.c uses rand() + SomeValue and in some cases this calculation wraps to a negative value
<caribou> when the result of rand() is close to RAND_MAX
<caribou> and the result > 32 bits
<caribou> pitti: I'm also pushing the fix upstream
<caribou> pitti: so reproducing it is not systematic as it depends on the random value
<Laney> ricotz: karlyriceditor kino have ricotz1 versions too still
<pitti> Riddell: so doko and I just untangled (at least one aspect of) the akonadi uninstallability
<ricotz> Laney, repushed, seems launchpad lost them somehow
<Laney> ricotz: thanks, copying the first lot now
<pitti> Riddell: https://launchpad.net/ubuntu/+source/kdepim/4:15.08.0-0ubuntu1 drops knode (i. e. NBS), but knode depends on a lot of NBS/old/uninstallable libraries
<pitti> Riddell: if dropping knode was intentional, the kdepimlibs binary needs to drop its Depends: knode
<doko> pitti, wait a moment until sitter appears, or join #kubuntu-devel
<pitti> Riddell: is that intentional?
<sitter> I am here :P
<pitti> sitter: hello
<ricotz> Laney, libde265 isn't listed in the transition page, I forgot some regex-name-tweaks
<pitti> sitter: so either the knode binary needs to get back, or kdepim needs to drop its depends: to it
<Laney> ricotz: I just copied everything built in the ppa
<caribou> pitti: debdiff is now on LP: #1464201
<ubottu> Launchpad bug 1464201 in rsyslog (Ubuntu) "Please merge rsyslog 8.12.0-1 (main) from Debian unstable (main)" [Wishlist,Fix committed] https://launchpad.net/bugs/1464201
<Laney> assuming it works
<ricotz> Laney, ok, expect the failed one of course ;)
<Laney> yes
<pitti> sitter: same for kaddressbook-mobile, AFAICS
<doko> pitti, already dropped in 15.08.0-0ubuntu2
<ricotz> Laney, I might propose another transition for "libav-tools"
<pitti> . o O { there once was a time when changelogs documented such major changes.. }
<doko> Laney, does this ffmpeg stuff interfer with kde?
<pitti> doko: no, http://launchpadlibrarian.net/216056388/kdepim_4%3A15.08.0-0ubuntu1_4%3A15.08.0-0ubuntu2.diff.gz does no such thing
<Laney> no we still have the old binaries
<ricotz> doko, kde got silently transitioned already
<sitter> pitti, doko: ubuntu1 shouldhn't have a reference to either of those packages
<doko> ricotz, no
<Laney> ok there we go, seems the copies happened
<ricotz> doko, yes
<sitter> hm
 * Laney goes to lunch
<sitter> pitti: the kdepim*libs* package you say?
<Laney> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> sitter, doko: oh, ok; well, then *something* else is missing :/
<doko> ricotz, no or else pitti or sitter would talk about it
<ricotz> http://people.canonical.com/~ubuntu-archive/transitions/html/ffmpeg.html
<ricotz> look at the good ones
<sitter> pitti: libakonadiprotocolinternals1 is missing
<ricotz> of course this only tracks dependencies, runtime deps are not considered like apps using "libav-tools"
<sitter> due to reappear through the new akonadi1 source though which is building now
<Laney> ricotz: will you look at the ftbfs?
<pitti> sitter: yeah, I figure that's NBS as well, I didn't wade through all of the rdependencies yet (there's lots of transitions at the same time..)
<pitti> sitter: ah, so libakonadiprotocolinternals1 will come back?
<sitter> yep
<ricotz> Laney, they are toolchain and qt related, so currently not
<sitter> doko: regarding ffmpeg off the top of my head we only have one package that directly links to ffmpeg all other stuff is abstracted through phonon/gstreamer/libvlc
<ricotz> Laney, will the transition page update itself?
<Laney> yes
<ricotz> ok
<sitter> doko, ricotz: only ffmpegthumbs should have needed a rebuild on the kde side of things and that apparently picked it up as part of the kde applications 15.08 landing https://launchpad.net/ubuntu/+source/ffmpegthumbs/4:15.08.0-0ubuntu1/
<ricotz> sitter, and kfilemetadata?
<sitter> also seems built against ffmpeg https://launchpadlibrarian.net/213741522/buildlog_ubuntu-wily-amd64.kfilemetadata_4%3A4.14.2-0ubuntu2_BUILDING.txt.gz
<ricotz> sitter, right, just saying there are more ;)
<sitter> ah yeah, I forgot about that bugger ^^
<ricotz> sitter, looking at apps using "libav-tools" aka avconv is needed too
<sitter> that list should be slightly longer
<sitter> ricotz: what do we need to do to them?
<ricotz> exactly
<pitti> caribou: uploaded, cheers!
<caribou> pitti: thanks!
<ricotz> sitter, make them use the "ffmpeg" package and its ffmpeg binary
<caribou> pitti: let's cross finger & hope it builds :-)
<doko> ricotz, sitter: not before we get the current migration done
<sitter> I'll send a mail to the kubuntu list, lest we forget
<barry> doko: thanks
<cyphermox> good morning!
<cyphermox> Laney: fixed up bug 1432062.
<ubottu> bug 1432062 in multipath-tools (Ubuntu) "multipath-tools-boot: support booting without user_friendly_names on devices with spaces in identifiers" [Medium,Confirmed] https://launchpad.net/bugs/1432062
<pitti> caribou: oh noes
<pitti> read value 23, but expected value 22
<pitti> caribou: I pretend I didn't see that and just retry
<caribou> pitti: can be a race condition, his testbench is subjec to that
<caribou> pitti: it builds fine on i386, want me to retry here ?
<pitti> caribou: that was on amd64 this time; I guess/hope it'll build the second time
<pitti> caribou: I guess the tests are still quite new and need to mature a bit
<caribou> pitti: I'll keep an eye on this
<caribou> pitti: indeed. The upstream maintainer does agree & I know that the debian maintainer is also closely working with him on that
<caribou> pitti: I just sent the DM my fix
<pitti> caribou: say hello to mbiebl_ from me :)
<caribou> pitti: will do :)
<caribou> pitti: \o/ it built
<ricotz> doko, does this looks fine to you http://pastebin.ubuntu.com/12253274/
<Odd_Bloke> arges: We've identified a fairly important regression caused by the last set of cloud-init uploads, and I have a fix ready to be uploaded by someone, but another version has just hit {t,v}-proposed; what's the correct way of handling this?
<arges> Odd_Bloke: well I assume your fixes are a superset of the previous changes, then we can upload over the current -proposed version
<Odd_Bloke> arges: Should I just ask whoever ends up doing my upload to pull from -proposed, apply my debdiff and then upload?
<arges> Odd_Bloke: Just make sure we don't drop fixes that are already there. Does the current version in -proposed cause the regression?
<Odd_Bloke> arges: Nope, it's completely orthogonal.
<Odd_Bloke> The version that got released from -proposed last week causes the regression.
<Odd_Bloke> And we now have a new test case for changes to the Azure bits of the code. :p
<arges> Odd_Bloke: yea so make sure the new upload contains the fixes in -proposed as well. That should be sufficient
<Odd_Bloke> OK, cool.
<Odd_Bloke> arges: Thanks. :)
<arges> Odd_Bloke: no problem
<revolve> Hello there, I'm having a problem with redhat cluster manager in 12.04, it's producing this error: Starting cman... /usr/lib/lcrso/service_amf.lcrso: open failed: /usr/lib/lcrso/service_amf.lcrso: undefined symbol: logsys_rec_end
<revolve> I've also built it and its dependencies from src, experienced the same thing, and replaced them with the version from the repos again
<Logan> Laney: <3
<rbasak> revolve: this is a development channel. Try #ubuntu or #ubuntu-server. When you do it might also be useful to state which package you're having a problem with.
<revolve> thanks
<Laney> hey Logan!
<Logan> thanks for all the syncs :P
<Laney> cyphermox: thx
<slangasek> Laney: sorry, bug #1429327 - which queue?  I'm not handling anything with respect to that at the moment
<ubottu> bug 1429327 in multipath-tools (Ubuntu) "Boot from a unique, stable, multipath-dependent symlink" [Medium,In progress] https://launchpad.net/bugs/1429327
<infinity> pitti: Is the weird "skip everything, then pass" mode in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/ppc64el/n/nvidia-graphics-drivers-352-updates/20150902_105426@/log.gz a behaviour of autopkgtest or the nvidia tests themselves?
<Laney> slangasek: the ~ubuntu-sponsors queue
<infinity> pitti: Seems weird that's not a failure or, ideally, a new "skipped" state.
<pitti> infinity: in between, it's from the dkms package's generalized dkms testing script
<infinity> pitti: (Only noticed because I had to re-run a ppc64el nvidia test due to a different "failure", and I was curious how nvidia could ever regress on ppc64el in the first place :P)
<pitti> infinity: we don't build it on ppc64el, so none of the binaries  works
<pitti> infinity: ah, funny; I just re-kicked that test too
<pitti> (temp failure resolving ports.u.c.)
<infinity> pitti: Right, none of the binaries available should lead to a "skip", I would think, but I guess skip==success is alright for now, just surprising.
<infinity> pitti: Is there blocking serialisation on retries, or did we just start two jobs? :)
<pitti> infinity: we started two
<infinity> Go us.
<pitti> infinity: sorry to wolfe for wasting a whopping 3 minutes of their time
<infinity> pitti: Yeah, not a big deal for this no-op test. :)
<slangasek> Laney: ah, yes I don't think that belongs in the sponsors queue
<infinity> pitti: But maybe some locking would be in order, somewhere down the todo after in-progress UI feedback of some sort.
<pitti> infinity: so, the more interesting thing here would be to auto-retry on DNS resolution glitches
<infinity> Or maybe before it.
<LocutusOfBorg1> dholbach, now the syncpackage should work
<LocutusOfBorg1> syncpackage -f -s mapreri -V 0.7.2+dfsg-2 flightcrew && syncpackage -f -s mapreri -V 0.8.7+dfsg-2 sigil
<LocutusOfBorg1> :)
<infinity> pitti: Optimising for network issues (especially in our own DC) leaves a bad taste in my mouth.
<pitti> infinity: right, if/once we expose the pending queues, this will be much simpler
<infinity> pitti: But if this is generic code that's also making its way back to Debian, I agree, since their distributed network is much less reliable than ours is (or should be).
<pitti> infinity: I already have the usual apt-get update || { sleep 15; apt-get update } loop for update, due to the dreaded Hash Sum Mismatches, but not for dist-upgrade or install
<dholbach> LocutusOfBorg1, aren't the two packages from yesterday synced already?
<pitti> infinity: yeah, hopefully less of an issue once ppc64el moves into scalingstack
<dholbach> LocutusOfBorg1, but I'm busy right now - just about to join a call
<infinity> pitti: Yeah.  apt 1.1 will save us on the mismatch thing.  Not that we'll be backporting that to << 16.04, though.
<pitti> infinity: cjwatson's LP report today sounded like this might actually happen soon
<LocutusOfBorg1> dholbach, no problem, I remembered they were in incoming
<infinity> pitti: Though, the *other* mismatch bug (Translations-specific) should be fixed once IS rolls out my trivial mirror change.
<dholbach> right - yeah, I think they're synced and in wily now :)
<infinity> pitti: So, you'll just be left with that tiny "I downloaded Release before the dists switch and Packages after" race window.
<infinity> Which, I realise, is a very visible window at scale. :/
<pitti> infinity: yeah, it seems everyone (autopkgtest, launchpad buildd, etc.) uses that same "try again after sleep" approach (I got it from Colin)
<infinity> pitti: Yup, it's gross, but we know we don't pulse more than every 5m (realistically, every 15 or so), so the odds of hitting the same race twice in a row are pretty slim.  The sleep is entirely unnecessary, though.
<infinity> pitti: Given that the reason it fails is because you're on a new dists tree halfway through "apt-get update", you know the second run will also be on the new dists tree, unless you sleep too long.  So don't sleep at all, IMO.
<infinity> pitti: So, you can optimise out that waste 15s, if you like.
<infinity> s/waste/wasted/
<pitti> infinity: ah, good point
<infinity> pitti: Though, you have an extra fun problem, in that you use archive/ports instead of ftpmaster, so you could concievably hit the race on mirror1, retry, and hit the race on mirror2 because it's a few seconds behind. :P
<infinity> pitti: Arguably, you should just use ftpmaster.
<pitti> infinity: yeah, I'm going to for armhf; for ppc64el that needs to go via proxy, but should still be better than the mirror hopefully
<pitti> infinity: the cloud instances already use ftpmaster.internal
<pitti> just didn't do the magic for the LXC boxes yes
<pitti> yet
<pitti> (bug 1490899)
<ubottu> bug 1490899 in Auto Package Testing "armhf/ppc64el tests might use earlier binary packages than britney sees" [High,In progress] https://launchpad.net/bugs/1490899
<infinity> pitti: Ahh, kay, if scalingstack is using ftpmaster, than I'll just assume that's the way forward.
<infinity> pitti: The other (disgusting) option I had, if there were concerns of CPU/bandwidth pressure on pepo, would be to break your resolver. ;)
<pitti> infinity: pepo?
<infinity> pitti: host archive.ubuntu.com > chroot/etc/hosts
<infinity> pitti: pepo == ftpmaster
<pitti> ah
<infinity> pitti: If there ever is a concern, the resolver-breaking approach would work, so you still round-robin between builds but guarantee a consistent single-host per build.
<infinity> pitti: But also ew. ;)
<mterry> arges, thanks for fixing my tgt version for trusty
<arges> mterry: no problem! glad that bug finally got fixed
<ricotz> Laney, could you copy the 3 remaining packages: fuse-emulator-utils, karlyriceditor, kino
<Laney> ricotz: I don't see fuse-emulator-utils
<Laney> but for the rest ok
<ricotz> Laney, ah sorry, regarding bino: http://pastebin.ubuntu.com/12253274/
<mapreri> dholbach: actually sigil ain't synced yet (uploaded in debian only this morning)
<dholbach> mapreri, yep, sorry - I was commenting on flightcrew and gimp-help which LocutusOfBorg1 asked me to sync yesterday evening
<mapreri> dholbach: well, now if you sync sigil you should add -b 1491459
<mapreri> :)
<dholbach> no, I won't get around to it today
<dholbach> I'm still in a call and need to run afterwards
<mapreri> i don't really care about the -s
<mapreri> fine for me, whenever before wily release ;P
<doko> pitti, autopkgtest for kde4pimlibs in progress for some hours on armhf ... :-/
<ricotz> slangasek, hi, could you take care of https://code.launchpad.net/~ricotz/ubuntu-transition-tracker/ffmpeg/+merge/269963
<doko> barry, something already installs python3.5
<doko> barry, this is plainbox, but when built locally it doesn't have this dep
<infinity> doko: I assume it's the usual "install_scripts sets shebang incorrectly" misfeature.
<infinity> doko: So, when the last install_scripts is the 3.5 one, you get python3.5 as the shebang.
<doko> otoh, we want python3.5 in the end ;p
<infinity> doko: dh_python3 --shebang=/usr/bin/python3 worked around it last time I saw this.
<infinity> doko: We don't ever want versioned shebangs, IMO.
<infinity> (unless something actually only works with that version)
<doko> infinity, something else, can somebody other than pitti manage autopkg tests?
<infinity> doko: Define "manage".
<doko> infinity, http://autopkgtest.ubuntu.com/packages/k/kde4pimlibs/wily/armhf/ (triggered by akonadi1) Test in progress for 5h
<infinity> doko: I'm not sure any of us know how the infra works yet to play with it if it explodes, but that should be coming along.  As for retrying tests, a select few of us can do that, but work's in progress to open it up.
<infinity> doko: Oh, stalled tests, I can't do much about, but I can retry it.  Maybe it's not stalled, but lost. :P
<infinity> (It's on the TODO to make the in-progress stuff less opaque too)
<doko> infinity, it will fail, and I can do that too
<doko> infinity, can you set it to ignore? or jibel ?
<infinity> I can ignore it for promotion.
<doko> would be nice to see what britney thinks then ...
<doko> ohh mehh, rtg limiting the list of architectures for packages ...
<infinity> doko: Not really.
<doko> ?
<infinity> doko: All the other binaries in that package were already arch-restricted.
<infinity> doko: For some reason, the -dev was arch:any, it was just a bug.
<infinity> Given the library was arch-restricted, having the -dev not match made no sense. :P
<doko> no
<doko> Package: mstflint
<doko> Architecture: linux-any
<infinity> Oh, I thought you were talking about numactl
<infinity> Bah, and he *just* left IRC.
<infinity> And that's even reverting a change I made.  Excellent. :P
<doko> sent email
<doko> looks like the hint was good enough, the whole mess seems to migrate
<doko> jamespage, what's the status of jenkins? there are still packages depending on jenkins in wily. remove these? otoh, why not keep jenkins in -proposed and file a block-proposed issue?
<barry> lifeless: ping
<slangasek> ricotz: done, with modifications
<lifeless> barry: pong
<barry> lifeless: hi.  i was looking at pyjunitxml.  i see debuntu is a bit behind upstream, and i was also wondering if 0.7 is compatible with py3.5
<lifeless> barry: I haven't specifically tested
<lifeless> barry: but if its not it should get fixed :)
<barry> lifeless: ok! :)  i'm about to do a test build with 0.7...
<lifeless> hmm, I need to move it over to git too
<lifeless> long tail of projects to migrate
<barry> lifeless: probably so
<barry> i hear ya there :)
<barry> lifeless: 6 test failures in 3.5.  i'll file a bug
<lifeless> barry: all test-only issues
<lifeless> barry: qualname stuff
<barry> lifeless: hard to say from the output here
<lifeless> barry: I just reproduced and checked
<lifeless> - <testcase classname="junitxml.tests.test_junitxml.Succeeds" name="test_me" time="0.000">
<barry> lifeless: ah
<lifeless> + <testcase classname="junitxml.tests.test_junitxml.TestJUnitXmlResult.test_unexpected_success_test.&lt;locals>.
<barry> yep
<lifeless> thats an inner class showing pu
<lifeless> up
<barry> ack.  should i file a bug?  i'd like to be able to track 3.5 compat since this is a seeded package
<lifeless> sure
<lifeless> I won't get to it today
<barry> lifeless: no worries.  i am eod.
<barry> lifeless: LP: #1491635
<ubottu> Launchpad bug 1491635 in pyjunitxml "Test failures (and FTBFS) in Wily with Python 3.5" [Undecided,New] https://launchpad.net/bugs/1491635
<barry> lifeless: thanks.  ttyl.
<lifeless> barry: ciao :)
<doko> infinity, user-mode-linux needs more changes than bumping the linux version
<slangasek> uml still exists?
<doko> yeah, some nerd is till updating
<lifeless> doko: nerd?
<doko> go away
<lifeless> wow, this isn't the Ubuntu-devel that I remember.
<doko> wrong channel
<lifeless> doko: I agree - its the wrong channel for aggressive and insulting behaviour. I'm not sure how best to put this - but I think your last three messages are really quite far outside the Ubuntu CoC which still applies to the best of my knowledge.
#ubuntu-devel 2015-09-03
<smoser> ugh.
<smoser> hey, my core dev mempership expired today
<smoser> can i get it fixed ?
<pitti> doko: kde4pimlibs 5 h? it ran for 2:30 h, which is fairly normal
<pitti> oh, you mean it was waiting for 5 h?
<pitti> doko: wrt. your question of "someone else"> the cloud stuff can be handled by infinity, slangasek, stgraber, and Laney (I gave training to Laney); the most common admin tasks are documented on prod-ues-proposed-migration
<pitti> doko: err, documented on https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration
<pitti> doko: armhf and ppc64 are still kind of "step kinds" from the old infra, waiting  to move to scaling stack; happy to show you (or some one else) about admin
<pitti> dpm: hey David! Can we please have http://people.canonical.com/~dpm/data/ubuntu-l10n/ for RTM 15.04?
<dpm> morning pitti
 * dpm files RT
<pitti> dpm: ah, that's something for IS? thanks
<dpm> yeah
<pitti> dpm: you can drop rtm 14.09 btw, it's obsolete
<pitti> dpm: (and utopic too)
<dpm> ack
<dholbach> good morning
<didrocks> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
 * dholbach hugs didrocks
 * didrocks hugs dholbach back
<Laney> pitti: I don't think I would have known how to debug a stuck "in progress", if that's what it was
<pitti> Laney: you could have looked at the queue length
<Laney> yeah
<pitti> Laney: we have 8 armhf runners, any number of requests that's larger than that will have to wait
<Laney> so I could have said that it looks like it might be waiting
<pitti> Laney: http://autopkgtest.ubuntu.com/packages/k/kde4pimlibs/wily/armhf/ looks like it took its usual time (2:30)
<Laney> would it be hard to have a separate queued state?
<pitti> it started at 20:56:30 UTC, not sure when britney requested it (could dig out of the logs)
<pitti> Laney: not easy right now; we'd need a way to export what's currently running from all the workers
<pitti> Laney: rabbitmq should know this (i. e. which are being processed and which are waiting), but we don't export the queue status right now
<pitti> the rabbit management plugin has quite some nice stuff, this sounds like a good place to start
<pitti> Laney: or the other way round, you can get access to the armhf runners, and  then just check what's currently running; want to?
<pitti> infinity: FYI, I gave you access to the cyclops and wolfe boxes, in case you want to peek at them (or reboot, restart worker, or what not); I added some documentation to https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration
<infinity> pitti: Mmkay.  That's temporarily helpful, but I'm hoping we can get more to a self-service model, like lp-buildd.
<pitti> infinity: yes, absolutely; this is for administration, not for developers
<infinity> (Which, granted, it took us 8 years to build a user-accessible "cancel" function but...)
<pitti> (i. e. when the boxes lock up or what not)
<infinity> pitti: Sure, point being that once this is all in scalingstack, an "admin" and a "user" should look almost identical, minus a tiny bit of glue.
<pitti> infinity: it's still the plan to export the queues and show them in debci
<pitti> infinity: yes, once armhf/ppc64el work in scalingstack all these external workers will just disappear
<pitti> until then, we have to make-do
 * infinity nods.
<infinity> pitti: So, for the scalingstack arches, do we have a clean way to cancel a job?
<infinity> pitti: May as well work on the utopia on x86, and be happy we get it all for free when the other arches catch up.
<pitti> infinity: clean, yes (kill the adt-run process); "easily accessible", no; and I'm not even sure we should make this
<infinity> pitti: Why not?
<pitti> I mean, if you kill adt-run, it'll just be re-run immediately
<infinity> pitti: It's just a build job like any other.
<infinity> pitti: Killing should be from the master/queue, not the slave. ;)
<pitti> infinity: what's your use case? i. e. who would want to do this and when?
<infinity> pitti: ie: master is told "make it die", it tries to fetch current logs, if succeed, kill remote VM, if timeout, kill remote VM, either way, log job as cancelled.
<pitti> infinity: master is britney?
<infinity> pitti: The same use-case as killing a package build.  Sometimes you don't want it to run.  Sometimes it's hung.  Sometimes you're freeing up resources.  Sometimes you know it's going to fail and why waste 8h, etc, etc.
<pitti> infinity: if it's hung, the kill will work right now (but it'll be immediately re-picked up by some worker, and re-run)
<infinity> pitti: master is your queue.  britney is just a fire-and-forget job creation client.
<pitti> ah
<pitti> right, removing it from the queue and killing the running job would work
<infinity> pitti: In the LP sense, britney would be like creating package build records on upload.  Your queue is buildd-manager (and its SQL tables), which is where state lives.
<infinity> And slaves should be completely stupid.  Easily murdered at will.  Not with killing a process, probably, but just by hard resetting VMs.
<infinity> (Though having the kill fallback is nice for non-VM runners, as we also do in lp-buildd)
<infinity> Or, rather, lp-buildd tries a "clean" kill, and if that times out *and* the builder is a VM, buildd-manager says "ah, screw it", and resets hard.
<infinity> But we also reset VMs between all builds for security/sanity reasons too.  Not sure if you're doing that yet in scalingstack autopackagtest, but you probably should be.
<infinity> Once you're always resetting VMs anyway, it starts looking like the hammer for every nail, cause it's simple. :P
<infinity> pitti: Anyhow, all of this also needs a sane view of the queue in general, before queue manipulation is a thing.
<infinity> pitti: So, a, then b.
<infinity> Oh, and A, section 2, which is that we need a view into in-progress jobs, or "is it hung?" is a question no one can answer without a shell.
<pitti> infinity: every test always gets a brand new VM
<pitti> infinity: i. e. with nova boot, and nova delete at the end
<infinity> pitti: Excellent, good.  I expected that, but wasn't sure.
<pitti> tests have full root, and can break the testbed in unknown and interesting ways; there's nothign to salvage
<pitti> infinity: right, that's part of the "show queue in debci" thingy
<pitti> to see which are running, and which are queued
<infinity> pitti: Kay, so queue+logtail, ideally.
<infinity> pitti: queue is interesting info, but without a logtail, it's still a guessing game.
<infinity> "Job was started 3h ago, and...?"
<infinity> (FWIW, this is the thing I hate the absolute most about buildd.debian.org after the last decade of Soyuz usage, that tail is way more useful than we thought it was when implementing it as a silly, shiny feature)
<pitti> undoubtedly :) (unfortunately also rather involved to implement)
<infinity> pitti: Do the slaves have a listener of any sort, or do you do all your state polling via ssh/scp?
<pitti> infinity: no ssh involved, it's just AMQP for the requests, and the slaves put the results directly into swift
<pitti> loose coupling
<pitti> infinity: i. e. they listen to AMQP queues
<infinity> pitti: Ahh, kay, so the slave is returning bits to swift?
<pitti> infinity: we can implement tailing via AMQP (just send out the log tail every 30 s to a broadcast queue or so)
<infinity> pitti: So, one could just jam a logtail into swift as well.
<pitti> nah, not into swift
<pitti> seems easiest to use a broadcasting AMQP queue for that
<pitti> then we don't need any new auth/firewall holes/host name hardcoding anywhere
<infinity> Fair enough, I don't speak AMQP.
<pitti> infinity: it's more or less just a queue which you can feed requests into, and someone else picks out a request (with lots of routing options, but an unbreakable FIFO is the simplest use case)
<pitti> i. e. what we don't want is britney to do "ssh armhfworker1.canonical.com", as that is brittle and not scalable in so many ways
<infinity> pitti: Right.  But it handles large messages fine, then?
<pitti> so britney puts a test request for "linux" into some "wily-amd64" queue, and whichever worker listens to that queue can process it
<pitti> infinity: FSVO large -- the messages are mostly bound by memory; so they shouldn't exceed 50 MB or so
<pitti> but we are speaking about a  log tail of maybe 1 kB or so
<infinity> pitti: Oh, sure, a logtail should never be more than a few dozen kB, or you're doing it wrong.
<infinity> (or less, indeed)
<pitti> infinity: so an idea is that every release-arch queue could have an accompanying release-arch-logtail queue which works in teh other direction; i. e. the workers put the log tail into these every n seconds
<pitti> and whoever bothers to listen can show them
<pitti> this queue would be configured to be in this kind of "lossy" mode, as opposed to the request queues which never lose anything
<pitti> infinity: heh, seems http://notes.variogr.am/post/143623387/broadcasting-your-logs-with-rabbitmq-and-python does pretty much that
<pitti> infinity: so maybe implementing this should even be A1 -- once we have a page with all logtails of all currently running tests, then this implies knowing which tests are running; and everything on excuses.html which is "in progress" but not running is then queued
<Riddell> pitti: KDE mostly cleared from excuses, rocs is failing on ppc64el with an unknown error, worth trying again? http://autopkgtest.ubuntu.com/packages/r/rocs/wily/ppc64el/
<pitti> error writing to /tmp/ccPiwlDE.s: Cannot allocate memory
<pitti> Riddell: yes, worth retrying; done
 * pitti looks at bluez-qt
<pitti> Temporary failure resolving 'ports.ubuntu.com' - sigh, retrying
<cjwatson> smoser: ~developer-membership-board should be able to fix that up quickly.  did you miss the expiration warning mails?
<infinity> cjwatson: It got sorted.  And yes, he missed all the emails.
<sitter> pitti: can we somehow dump arbitrary files into the artifacts tarball? namely upon ACC failure it would be handy to have the ACC headers and so forth artifacted
<cjwatson> smoser: Would it have helped if those mails were more filterable?  Since I have a branch in progress for that ...
<pitti> sitter: yes, absolutely; see https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html , your test can put anything into the $ADT_ARTIFACTS dir, and it'll appear in the "artifacts.tar.gz" from autopkgtest.u.c.
<sitter> groovy thanks
<pitti> Riddell: ack, rocs happy again
<Riddell> awooga
<mapreri> dholbach: thanks :)
<didrocks> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<diwic> doko, so, I *think* trust-store should be in main now, because it says so in launchpad, so I retried the pulseaudio build, but it didn't seem to help
<cjwatson> You're reading the wrong bit of the LP UI.
<cjwatson> "Component:" on https://launchpad.net/ubuntu/+source/trust-store just means the package defaults, as indicated by the small print there (sorry ...).  The actual published location is per-series below.
<doko> didrocks, what cjwatson said, still in universe
<cjwatson> Also pulseaudio will retry automatically once trust-store is actually in main.
<diwic> doko, cjwatson, ok, thanks
<doko> but I find this ui confusing too
<didrocks> phew, for a sec, I didn't get the context ;)
<cjwatson> It's tempting to just delete the Component field there.
<cjwatson> https://bugs.launchpad.net/launchpad/+bug/521722 ends up suggesting that too
<ubottu> Launchpad bug 521722 in Launchpad itself "Display of Component on distro source summary page may be wrong (but we know the right value)" [Low,Triaged]
<cjwatson> diwic: would it have been less confusing if the Component:* field there were simply absent?  there's then the per-series bit below that says "release (universe)" etc.
<infinity> cjwatson: I'm inclined to agree that the .dsc component is completely useless and should just not be shown.
<infinity> cjwatson: The other option is "show component of the proposed>updates>security>release pocket in the devel series", but that's really not useful.  About as not useful as the package list from the current stable. ;)
<cjwatson> Also misleading in a different way, because we don't know what you care about (latest, or LTS, or ...)
<infinity> Basically, the whole top half of that page is useless.
<cjwatson> It makes a slight difference whether it's contrib or non-free for Debian stuff imported into multiverse, but really not a lot and not +index-worthy.
<infinity> cjwatson: I'd argue that what most people looking at that page care about is the package list from the devel series, but I'd be just as happy with not showing it there at all, since it's not clear which series it's from.
<cjwatson> Yeah, it needs a total rework, but it seems worth dealing with the bits that are actually bleeding (.dsc component).
<cjwatson> Since that's a five-line change.
<infinity> cjwatson: anyhow, yes, agreed.  Package list is a bigger debate (perhaps), I think consensus that .dsc component is useless and confusing is pretty much unanimous.
<cjwatson> OK, I'll nuke it
<cjwatson> But first, shopping
<diwic> cjwatson, thanks for asking. I'm not familiar with the internals of main vs universe and how things are promoted/demoted, but I suppose if not all the binary packages are in the same as the source package, then yes, it's a bit confusing
<infinity> cjwatson: Curiously, somtimes it's correct...
<infinity> cjwatson: I wonder if that's just historical data versus new.
<cjwatson> diwic: Well, that and the fact that the source isn't in main either; the "Component:" at the top is extracted from the source package and has nothing to do with actual publication other than setting defaults
<cjwatson> Which is utterly mysterious to most people
<infinity> cjwatson: Could it be that historical data was ginaed from Ubuntu and older packages get it "right" by accident or something?
<cjwatson> infinity: The package list?
<infinity> cjwatson: (see, eg: poppassd, which is 'main' per .dsc, but 'universe' on the offending page)
<infinity> cjwatson: No, the component.
<infinity> cjwatson: So, it's not even consistently wrong. :P
<smoser> cjwatson, i wish i had a good excuse. but only excuse is "so much mail stuff gets lost". maybe it could have pinged me on irc.
<infinity> smoser: I'd say rejecting your uploads is a fair last resort to the mail going missing.
<cjwatson> infinity: Probably something to do with one being a direct upload and the other being copied from SPRs created by gina, indeed, but meh, too twisty for me to really want to totally track down.
<cjwatson> infinity: Oh, in fact, I expect it's because trust-store's initial upload was to a PPA.
<cjwatson> infinity: Which only has main.
<infinity> cjwatson: Ahh, could be.
<smoser> infinity, it definitely got my attention :)
<infinity> cjwatson: All very confusing anyway.  Purge with fire.
<cjwatson> Yeah.
<cjwatson> infinity: Though you're right that it's weirdly inconsistent - compare poppassd and makepasswd
<infinity> cjwatson: But makepasswd has been synced recently, the last poppassd was lucid, the consistency is probably a historical thing.
<cjwatson> I guess that could just be because something in gina has changed since 2010.
<cjwatson> Right.
<infinity> cjwatson: Also, kinda not caring anymore.
<cjwatson> :-)
<infinity> cjwatson: Anything that deletes some code and cleans up a bad UI can't possibly be wrong.
<rbasak> Hash Sum Aaargh!
 * pitti tosses an apt 1.1 to rbasak and pats him
<barry> pitti: ubuntu-drivers-common \o/ - thanks :)
<pitti> barry: yw :)
<smoser> anyone generally oauth knowledgable that could help me ...
<smoser> currently i  have some code that is logging a oauth request and its headers.
<smoser> like : http://paste.ubuntu.com/12263581/
<smoser> i'm wondering is there anything there that i shoudl redact from the log ?  is is token or consumer key needed to be masked out. Its easy enough to do it, but if they're not sensitive (note, there is no token_key or token_secret) then they're quite likely useful for debugging
<ricotz> stgraber, hi, pastebinit could you use a little tweak to deal with paste.debian.net forcing https
<octoquad> didrocks & Laney thanks for merging my MP for USC :)
<didrocks> thanks you octoquad for your MP! :)
<octoquad> I'm curious, what's the plan for USC and Snappy?
<didrocks> ogra_: ^
<stgraber> ricotz: patches are welcome :) not that I've touched pastebinit in over a year, I should probably do another release soon-ish :)
<doko> mitya57, will you still merge python-sphinx?
<ogra_> didrocks, no idea, i'm not a software center person :)
<didrocks> ogra_: you are the snappy one though :p
<ogra_> i would guwss the snappy store will replace it at some point
<ogra_> well, the "snappy scope" actually
<ogra_> which isnt much different from the click scope on the phone afaik
<ogra_> didrocks, i think kyrofa works on that iirc
<didrocks> nice :)
<octoquad> cool, thanks ogra_
<ricotz> stgraber, https://paste.debian.net/plain/310262 ;)
<infinity> in 103
<kyrofa> didrocks, ogra_ is right. Demo is here: https://www.youtube.com/watch?v=17nVOHrCh7Y&feature=youtu.be
<didrocks> I guess that's for octoquad ^
<octoquad> watching already :P
<Laney> kyrofa: you have a good narrating voice
<octoquad> nice, remember to add dark theme support hey :P
 * Laney wants to buy whatever it is you are selling
<kyrofa> Laney, haha, thanks!
<Laney> a box of air? i'll have ten!
<ogra_> Laney, and if you take them all at once you get a discount !!
<Laney> $100 each, 10 for the low low price of $1050
<ogra_> $1049 with friendship bonus, others pay more !
<didrocks> (without shipping)
<stgraber> ricotz: pushed to trunk
<dobey> hmm
<dobey> noooooo
<dobey> sigh
<doko> barry, did you file bug reports for the python3.5 ftbfs?
<dobey> didrocks: well that was rude :(
<didrocks> dobey: hum? what about?
<dobey> didrocks: pushing stuff directly to lp:software-center like that
<didrocks> dobey: seems Tarmac was down for 8 hours, nobody is reviewing USC merge for ages, Laney told we were ok to push directly after build
<dobey> there is no tarmac for software-center
<dobey> it is not ok to push directly to trunk
<didrocks> is the procedure for it documented?
<didrocks> I may have missed it, but tried to look
<dobey> i have been meaning to switch it over to the CI train, yes; but i haven't gotten around to it yet
<dobey> but anyway, those two branches shouldn't have been merged anyway, since they don't meet the requirement of contributor agreement
<didrocks> so, you are maintaining USC? We keep get us (desktop team) pinged about it because nobody is taking care of MP
<dobey> well, you can ship distro patches until they get merged if you want
<didrocks> dobey: so if you are taking again some time for looking at this project, please unmerge them (also, I saw that most of people just distro-patch it and it hadn't a release for almost 2 years) and get it in line
<dobey> as i've told to do in the past
<didrocks> dobey: yeah, let's do that
<didrocks> octoquad: reopening MP ^
<octoquad> didrocks, np
<didrocks> dobey: let me rewind trunk
<dobey> if desktop team wants to take over ownership of it, i'm fine with that too. i really don't want to deal with it. but patience is appreciated
<didrocks> dobey: no, it's just that it's been weeks/months that we are pinged about USC issues
<didrocks> but we do prefer you, as you have more expertise on it looking at things if possible :)
<dobey> well we don't ship it on the phone, snappy, or server
<didrocks> we do have a desktop product we ship every 6 months though
<dobey> i wouldn't say i have more expertise about it.
<dobey> it got dumped in my lap a few years ago
<didrocks> you were not agile enough to avoid it it seems :p
<dobey> yes, and unfortunately the ubuntu.iso includes software-center
<dobey> well it made sense at the time
<didrocks> dobey: trunk rewinded, reopening MP in a sec
<dobey> since we were the "ubuntu one" team at the time, and software-center fit fairly well under that
<dobey> software-center doesn't really fit well under the scope of "unity api" though
<dobey> anyway
<didrocks> dobey: indeed, so all done now, if you have some time to give a look, that would be great!
<didrocks> dobey: let's keep the distro patches for now
<octoquad> doby didrocks what will happen to the mp now? will it still make it for ui freeze?
<didrocks> octoquad: it's still in wily
<didrocks> octoquad: just not in software-center trunk
<didrocks> (in distro as distro-patches)
<octoquad> I see. Thanks for clearing that up.
<didrocks> yw!
<dobey> octoquad: you need to sign the contributor agreement, before your changes can land
<octoquad> where do I find that dobey?
<dobey> octoquad: http://www.ubuntu.com/legal/contributors
<octoquad> but, does it really matter? The future of USC might come to an end soon right?
<octoquad> ta dobey
<dobey> it's been coming to an end soon for three years, so i wouldn't put too much stock in "soon" right now :)
<octoquad> dobey, hehe
<dobey> the sooner it goes away, the happier i'll be though (as will anyone who wants to get rid of python2 from the ISO)
<jcastro> dobey: if no one is maintaining that stuff then your team could at least let people know
<jcastro> this whole black-hole business won't help anyone
<octoquad> didrocks, will that fix also be available in xx?
<dobey> jcastro: it's in "maintenance" mode
<jcastro> it's like you guys keep dropping projects but not telling anyone, how are people supposed to contribute?
<dobey> we aren't dropping projects
<didrocks> octoquad: the fix will stay until someone remove the distro-patch
<didrocks> octoquad: so the default is "yes" :)
<octoquad> didrocks, ok. What's a distro-patch, I'm relatively new to contributing
<jcastro> is there a different definition for not responding to pings or MPs from people other than dropping?
<dobey> we should just call 16.04 "dos equis"
<jcastro> "maintenance" isn't the word most people would use
<didrocks> octoquad: a patch applied to the package in a distro that isn't in upstream trunk
<didrocks> octoquad: so basically "only on ubuntu" in this case
<dobey> jcastro: don't add more confusion to the issue, please. i have responded to pings
<octoquad> didrocks, aaah, thanks :)
<didrocks> octoquad: yw ;)
<octoquad> bbl
<dobey> didrocks: anyway, if your team is getting too many pings about software-center, and think it needs more attention/priority for a bit, then get your PM to bring it up in the unity api stakeholders meeting
<didrocks> dobey: or get your team doing their patch pilot shift for people with upload rights and they will see them?
<dobey> didrocks: our team doesn't have a patch pilot shift
<mitya57> doko, not in this cycle
<didrocks> I thought everyone with upload rights had some
<doko> mitya57, just because we have some dep-waits
<dobey> and i'm the only one with any upload rights, and it's only like 2 or 3 packages i have upload rights for :-/
<mitya57> doko, I will merge it in the beginning of wily+1, but I can look at the dep-waits now
<didrocks> dobey: so maybe look at the shifts on the list for those 2-3 packages? That would make dholbach even happier :p
<didrocks> and will fix that issue
<doko> mitya57, ta
<dobey> didrocks: CI train has basically eliminated any need for people to get upload rights too
<didrocks> yeah
<mitya57> doko, though this is strange as sphinx 1.3 arrived in main just a couple of days before the import freeze
<mitya57> You probably need to blame those who synced those packages
<hallyn> pitti: stgraber: want to get http://paste.ubuntu.com/12264542/ into systemd in the archive.  i could just push, but i assume pitti  is in the middle of some changes so don't want to cause a mess :)
<doko> mitya57, can't see who synced it: https://launchpad.net/ubuntu/+source/routes and no email to changes email. https://launchpad.net/ubuntu/+source/routes/+publishinghistory
<doko> probably I should just remove it, unstable already has a newer version
<mitya57> oh yes, routes was uploaded by p1otr on the same day I uploaded 1.3 to unstable
<mitya57> Can we just remove 2.2-1 from -proposed and let it be autosynced again when wily+1 opens?
<doko> I'll do it
<mitya57> Thx
<tdaitx> tjaalton, hi! I have been taking a look at a few FTBFS for armhf... a few of those are caused by GLsizeiptr type being khronos_ssize_t on GLES* and a ptrdiff_t in glext (and GLEW), on armhf ptrdiff_t  is a signed int while khronos_ssize_t is a signed long int - a similar problem happens to GLintptr, do you know of any reason for that mismatch? I was wondering if there anything preventing khronos_ssize_t to be set to ptrdiff_t
<tdaitx> (I build mesa fine that way, have yet to build reverse deps)
<tdaitx> tjaalton, since you are a mesa maintainer, you might have come across a discussion on this (I haven't been able to find anything so far)
<tjaalton> tdaitx: huh, no idea.. first time i hear about it
<tdaitx> heh, ok, then it might be fixable =)
<to10fcm> hey guys, i am getting this error running different binaries on my system: "relocation error: /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4: symbol _ZTVNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference"
<to10fcm> any ideas on how to fix? i saw a reference to it and GCC5 in a log for this chan (http://irclogs.ubuntu.com/2015/07/17/%23ubuntu-devel.txt) so I thought I'd come here to ask first
<to10fcm> brb restating
<smoser> infinity, could you look at https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1491111
<ubottu> Launchpad bug 1491111 in bcache-tools (Ubuntu Trusty) "add bcache-tools to trusty archive" [High,Confirmed]
<smoser> it seems like something you've helped me with before. and seems to fit in with pitti's SRU stuff https://lists.ubuntu.com/archives/technical-board/2015-September/002154.html
<doko> infinity, could you provide a glibc 2.22 test build in a ppa? then I could include it in the test rebuild
<sarnold> to10fcm: what are you trying to do? I think you'd want either all the libraries and executable to be compiled with gcc <5 or gcc >5, but mixing the two would lead to problems, probably of the sort you tripped on
<doko> barry, fyi, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-ppc64el-20150902-wily.html was built with 3.5 as the default
<barry> doko: cool, thanks
<to10fcm> sarnold, I just want to run dolphin. I have kubuntu installed and I did apt-get update && apt-get upgrade and I'm on 15.10 dev preview and dolphin errors out with this error:
<to10fcm> dolphin: relocation error: /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4: symbol _ZTVNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference
<doko> to10fcm, dpkg -l dolphin ?
<to10fcm> ii  dolphin                              4:15.04.2-0ubuntu1      amd64                   file manager
<doko> to10fcm, should be 4:15.08.0-0ubuntu1
<doko> is your mirror up to date?
<doko> did you run apt-get dist-upgrade?
<to10fcm> a while back when i upgraded to 15.10 dev preview. i guess i can do it again and see if i get upgraded to some newer version
<TJ-> Anyone got 2 bluetooth adapters working? I'm finding that bluetoothd/bluetoothctl only see hci0 whereas 'hcitool dev' sees all adapters. I'd like to get confirmation that others get the same result
<doko> to10fcm, you have to run the complete apt-get update && apt-get dist-upgrade
<doko> TJ-, any news about your openjdk-8 backport?
<TJ-> doko: I've not had chance to look at it recently. I didn't find any problems with the limited testing I could do, but I didn't have time to do testing against tomcat/jboss etc.
<doko> ta
<to10fcm> doko, will do. brb after restart to tell u how it went lol
<TJ-> I've not had a stable working environment for a while now either. Hit so may bugs on 15.10 I'm about 5 years behind
<doko> TJ-, anything compiler specific?
<TJ-> doko: No ... almost exclusively upstream's tearing out existing functionality in 'new' releases and breaking existing functionality
<TJ-> e.g. systemd-cryptsetup *won't* support keyscripts; bluez not providing a simple agent nor PinCode Pairing, A2DP (punted to gstreamer/pulseaudio), headset profiles HCF/HSP (punted to ofono), LMV pvs not recognising metadata ... the list goes on!
<doko> TJ-, bug reports, or pester pitti about systemd, and seb128 about bluez
<lamont> wily dist-upgrade, now I have nopanel/launcher/etc...  hints on what more I need to have installed?
<TJ-> Yeah, reports are in. I've been attempting to figure out fixes or workarounds but some of them are far too big for simple patches.
<TJ-> pitti: is aware of, and just as frustrated, about the systemd-cryptsetup issue. Nothing we can do to fix it though. Upstream want a major new generic API implementing. I've suggested we disable systemd-cryptsetup and use the 'legacy' cryptsetup init scripts which do the job perfectly (and are still used in the initrd)
<doko> lamont, working here ...
<lamont> it helps when ubuntu-desktop hasn't been removed (apt-get  install -f)
<lamont> testing now
<lamont> much happier
<lamont> (u-d brogut back in unity, compiz, compiz-gnome, et. al.
<lamont> :(
 * lamont goes back to selep
<to10fcm> whoever was helpiing me, thank you!
<sarnold> to10fcm: excellent :)
<doko> infinity, https://launchpad.net/ubuntu/+source/pytango/8.1.5-1build3
<doko> could you have a look at the image, where the c++ alternative points to? looks very much this is still pointing to g++-4.9
<Unit193> sarnold: Hiya, know much about openssl's interaction as a library with other applications?
<sarnold> Unit193: hey :) I'm going to guess "no", but keep going.. I might get lucky :)
<Unit193> Maybe I should take this to #ubuntu-server.
<tdaitx> doko, gcc 4.7 FTBFS on ppc64el due to the gcc-as-needed.patch trying to apply to a non existing aarch64-linux.h, for the aarch64 to exist I would need to enable with_linaro_branch, is that ok?
<tdaitx> doko, or should I separate the aarch64-linux.h part from gcc-as-needed.diff and apply it only when with_linaro_branch is valid?
<doko> tdaitx, ignore it. 4.8 is the first version to build there
<tdaitx> oh, ok
 * tdaitx moving to the next FTBFS package...
<slangasek> mdeslaur: edk2 updated in Debian unstable; will sync it to wily when I think of it again
<slangasek> mdeslaur: which I guess actually requires a round-trip through binary new hmm
<tdaitx> slangasek, seems like someone else unblocked sssd for the build, the dependencies it was waiting for are done and it builds fine locally
<tdaitx> slangasek, same for pulseaudio, libtrust-store-dev is available as well, so a rebuild should go fine
<slangasek> tdaitx: the build-dependencies of sssd exist but are not in main
<slangasek> tdaitx: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed
<tdaitx> slangasek, in this case, how exactly can I help?
<slangasek> tdaitx: you can follow https://wiki.ubuntu.com/MainInclusionProcess
<slangasek> tdaitx: be sure to check for existing bugs for the dependencies in question, to avoid duplication
#ubuntu-devel 2015-09-04
<mdeslaur> slangasek: thanks
<pitti> Good morning
<pitti> TJ-: we could add support for keyscripts, it's "just" a matter of doing it
<TJ-> pitti: presumably not in the way upstream wants it done?
<pitti> TJ-: I don't remember right now how they want it done; but at least noninteractive key scripts shouldn't be so hard
<pitti> interactive ones will be of course, but I suppose the purpose of keyscripts is to be not interactive?
<TJ-> It can be either; sometimes in order to 'find' a key-file on some external device
<TJ-> Other times it might be to avoid the default keyboard input if it isn't trusted
<TJ-> I was reading the mailing-list threads, and Lennart expressed a desire to wait until a generic API can be put in place that uses the kernel keyring, and there was mention of a FreeDesktop API for PasswordAgents. I've added a reference to that discussion to bug #1451032
<ubottu> bug 1451032 in systemd (Ubuntu) "keyscript option in crypttab not implemented" [Medium,Triaged] https://launchpad.net/bugs/1451032
<dholbach> good morning
<alkisg> Hi, in Wily there's an ifup@.service which unconditionally runs ExecStop=ifdown %I.
<alkisg> Previously, init.d/networking and init/networking.conf cared so that ifdown wasn't run if a network file system, or a network swap, were active
<alkisg> This affects us in the LTSP project. I can work around it, but possibly other projects will be affected as well.
<alkisg> So, what would be the proper way to hanlde it? To file a bug report against systemd in Ubuntu?
<alkisg> Also, when systemd calls sysvinit services, it doesn't set $RUNLEVEL. Some of the Ubuntu services do use that environment variable. Should I file another bug report for that?
<pitti> alkisg: please file bugs against these services, yes; there is no concept of runlevel outside of sysvinit itself
<pitti> I think upstart might have some emulation of it, but the whole concept has gone for a long time
<alkisg> pitti: thanks, and what should I do about my first question?
<alkisg> I.e. does systemd in ubuntu care about not running ifdown when the network is in use by file systems, like the networking service did?
<pitti> alkisg: no, but this is a bit backwards
<pitti> alkisg: ifup@.service gets stopped when the interface disappears
<pitti> i. e. it calls ifdown to clean up ifupdown's state after a hot-unplug event
<pitti> alkisg: but I might miss something there, can you please file a bug with the details and the journal so that we have the data there and can discuss?
<alkisg> pitti, what I'm experiencing is, if I remove the ExecStop=ifdown line, then the interface stays around and is up and everything terminates correctly
<pitti> alkisg: ah, I guess it might also be stopped during shutdown, yes; that sounds like some missing dependencies
<pitti> alkisg: ah, so that was the previous workaround for not having proper dependencies, good to know :)
<alkisg> Ah so the desired solution there would be to fix the dependencies so that ifup doesn't stop when the network filesystem is still needed?
<pitti> no, that network-using services are stopped before tearing down the network
<pitti> in particular, they should have After=network.target; most stuff should already have it, but it seems there are some missing bits?
<alkisg> pitti, systemd says it supports the case of a networked root file system, as long as the network interface is brought up in the initramfs, and cleaned up there in the end
<alkisg> They chain back to the initramfs for clean up
<alkisg> But, ifdown must not be called and the network file systems must not be unmounted until the initramfs is called again
<pitti> alkisg: we don't go back to the initramfs on shutdown
<pitti> alkisg: I think dracut does that (or can do that), but we don't use that yet
<alkisg> I know, I don't expect to have it solved properly soonish, but whatever we fix now should be in that ^ way, right?
<alkisg> I.e., the interfaces should stay up, not be brought down...
<pitti> alkisg: ack, so please file a bug; if you already know how upstart worked around that (i. e. what it test to see whether or not to shut down stuff), please link to that, to save some searching (if not, I'll find it somewhere)
<alkisg> Sure, it's check_network_file_systems in /lib/lsb/init-functions
<alkisg> Called by init.d/networking and init/networking.conf
<pitti> alkisg: but then you keep processes like dhclient around which prevent proper unmounting of / and thus a clean shutdown
<alkisg> Thanks, I'll file a bug report
<alkisg> dhclient is supposed to be ran from the initramfs, if at all needed
<pitti> Laney: do you have any concerns about bug 1492129?
<ubottu> bug 1492129 in systemd (Ubuntu) "FFE: integrate networkd with /etc/network/if-*.d/ scripts and resolvconf" [Wishlist,New] https://launchpad.net/bugs/1492129
<Laney> pitti: I don't feel very confident in reviewing the actual change (I guess mbiebl or someone did though) but if it's genuinely opt-in then no
<pitti> Laney: yes, it's out of the question to use this by default for wily (maybe snappy will consider it, but we haven't talked about it yet)
<pitti> Laney: yeah, it's just a bureaucrazy, but I didn't feel like just slipping this in as it kind of is a new feature
<pitti> (unless you consider missing integration with if-up.d/ a bug..)
<Laney> pitti: what's the resolved integration going to be?
<Laney> resolvconf*
<sidi> I'm trying to force a package in my PPA to autoreconf before it configures, or else it wont be able to build
<sidi> i've put this in my rules: http://bazaar.launchpad.net/~ucl-cs-study-devs/activityfinder/xfwm4-4.11.1-2ubuntu2/view/head:/debian/rules but it still wont call xdt-autogen
<sidi> what am i doing wrong?
<doko> apw, not sure if you or somebody else complained about th eppc64el cross compiler. but it's not updated
<apw> doko, i think it was rtg who complained first, though i have noticed it is behind, and has the same -m issue that the main one did
<doko> pitti, can we override all the gcc-5 triggered tests, to start the test rebuild?
<doko> apw, ahh, ok. I assume rtg is doing some +1 maintenance. please could he avoid to change 'any' packages to arch specific ones?
<apw> doko, i am not sure, i don't think he was fixing anything just notcing we couldn't pre-test cross
<cjwatson> sidi: You've written "--with-autoreconf" when it should be "--with=autoreconf".
<cjwatson> sidi: Also I would advise against having debhelper override rules depend on anything because I think it gets rather confusing; I'd just write "override_dh_auto_configure:" rather than "override_dh_auto_configure: override_dh_autoreconf".
<cjwatson> (You could easily end up with multiple autoreconf runs your way, because make doesn't know when override_dh_autoreconf is done unless it's part of the same make run ...)
<sidi> cjwatson, to be honest i've been testing various things at this stage... will fix the with line and see if it works!
<sidi> if i get at least one autoreconf run i'm happy... i added dependencies and they're not picked up right now
<cjwatson> cyphermox: FYI I'm merging wily's grub2 into unstable
<jamespage> doko, libcommons-cli-java uploaded without maven
<doko> jamespage, cool, thanks
<jamespage> doko, probably a useful template for reverts going forard
<jamespage> doko, http://launchpadlibrarian.net/216361477/libcommons-cli-java_1.3.1-2_1.3.1-2ubuntu1.diff.gz
<doko> jamespage, I was looking at the dovecot merge, neglected for the 18 months ... debian dropped the ssl cert support between 2.2.13-5 and 2.2.13-8. do you have any suggestion how to handle that in ubuntu?
<pitti> doko: absolutely; I usually do, just wanted to wait a bit until the queue settles down
<pitti> doko: hint updated
 * pitti hints apparmor as well, another victim of NetworkManager
<pitti> Laney: resolvconf> I don't know yet for sure; the BP has some ideas
<pitti> Laney: I adjusted bug 1492129, let's handle resolvconf separately then
<ubottu> bug 1492129 in systemd (Ubuntu) "FFE: integrate networkd with /etc/network/if-*.d/ scripts" [Wishlist,Confirmed] https://launchpad.net/bugs/1492129
<Laney> pitti: OK, I was going to pre-ACK but wanted some idea of what it would be first. :)
<tjaalton> tdaitx: there's already a MIR for uid/nss-wrapper
<tdaitx> tjaalton, I saw it, thanks =)
<tjaalton> and unorphaned in debian now, so moving to main should be ok
<tnkhanh> hi where can I talk about wily?
<dobey> tnkhanh: if you want support, #ubuntu is the channel for you
<tnkhanh> dobey: ok thanks
<ogra_> i think there is a special channel for support for  unreleased versions ... but the guys in #ubuntu can tell you
<Laney> #ubuntu+1
<ogra_> ah, right
<Sweet5hark> stgraber: soo seb128 is on vacation and as I consider to reapply for package upload rights, I wonder if you could review and sponsor this: http://people.canonical.com/~bjoern/wily/5.0.1/libreoffice_5.0.1-0ubuntu1_source.changes and http://people.canonical.com/~bjoern/wily/5.0.1/libreoffice-l10n_5.0.1-0ubuntu1_source.changes
<Sweet5hark> stgraber: sponsoring blocks of course on bug 1491964, but as we are late in the game and reviewing libreoffice takes a while, its probably better not to wait on the greenlight from ubuntu-release with reviewing
<ubottu> bug 1491964 in libreoffice (Ubuntu) "[FFE] LibreOffice 5.0.x for wily" [Undecided,Confirmed] https://launchpad.net/bugs/1491964
<Sweet5hark> stgraber: note that this upload needs uploads for writer2latex and nlpsolver along with it, if you would want to review those too, just tell me ...
<doko> barry, https://bugs.launchpad.net/ubuntu/+source/kubuntu-driver-manager/+bug/1474539 is not Python specific
<ubottu> Launchpad bug 1474539 in shiboken (Ubuntu Wily) "FTBFS with Python 3.5" [High,New]
<barry> doko: doesn't matter.  still a ftbfs, and just piggybacking on existing bug
<infinity> pitti: Around?
<smoser> stgraber, around ?
<stgraber> smoser: yeah
<smoser>  http://paste.ubuntu.com/12275296/
<smoser> we're writing a /etc/network/interfaces like that.
<smoser> and it doesnt want to come all the way up on 'auto'
<smoser> (i'm  pretty sure that the hwaddress are not needed on the eth* but removing them d oesnt cause a problem)
<rharper> smoser: well, it does come all the way up; but only after quite some time
<smoser> ifupdown never thinks its up
<smoser> that is on trusty
<rharper> right
<stgraber> I'm not seeing anything wrong with this config, though I've never used active-backup...
<stgraber> smoser: I'd suggest you wipe /var/log/upstart/*, then reboot and look for any networking related /var/log/upstart logfile
<smoser> yeah, there is such things there.
<smoser> stgraber, http://paste.ubuntu.com/12275511/
<smoser> maybe that helps a bit. after a boot, nothing touched manually
<smoser> remember / know that cloud-init is forcing a bottleneck in boot on
<stgraber> smoser: so the "file exists" error usually indicates that the interface already had an IP or route on it
<smoser>  start on mounted MOUNTPOINT=/ and stopped cloud-init-local
<stgraber> smoser: unsure what the I/O error is though, never seen that one before
<stgraber> smoser: oh, of course
<smoser> that'd be toolate anyway though
<stgraber> smoser: sorry I didn't see it before, your config is wrong
<smoser> ie, 'networking' shoudlnt bring anything up
<stgraber> smoser: you can't have two interfaces defining a gateway
<smoser> what 2 interfaces do that ?
<stgraber> eth0 and bond0
<smoser> hm.
<smoser> well in that case, how would you tell dhcp to not respect the gateway that it got ?
<stgraber> you'd have to change /etc/dhclient.conf I suspect
<smoser> and in the event of multipe ncs doing dhcp, how would that not be a problem. ie, i connect 2 nics to the 'usernet' in qemu
<smoser> (or lxc if you'd rather)
<smoser> and tell them to dhcp
<smoser> wouldnt 'that inherently cause the same "multiple gateway" problem ?
<stgraber> it would
<stgraber> and there's nothing ifupdown can do about it, the kernel won't let you have two default gateway with the same priority
<stgraber> it's also not something ifupdown can detect since whether you get a gateway or not depends on your dhcp client config and your dhcp server config
<smoser> right.
<smoser> rharper, ^
<stgraber> you could have a dozen interfaces setup with dhcp and not run into that problem if their dhcp server wasn't pushing a default gateway
<rharper> I'm dropping the extra gateway from the configuration;  if we do support that we'll have to do it via post-up scripts
<rharper> you have to set metric IIUC
<smoser> rharper, just commenting that out does solve the problem
<rharper> yeah
<smoser> its really quite painful
<rharper> yes, yes it is
<smoser> in as stgraber pointed out its an invalid config
<smoser> but if you plugged eth0 into adifferent network, it might not be :)
<rharper> or if you didn't get gateway back in dhcp response
<smoser> rharper, http://ubuntuforums.org/showthread.php?t=2208119
<smoser> we could potentially do something in a script in /etc/dhclient/dhclient-enter-hooks.d
<smoser> that looked at the interfaces, and only listened to gateway if no other auto had a gateway
<rharper> but how do we know they want that
<rharper> the dhcp server configuration is out of our scope
<smoser> or i guess since when you're rendering things, you know this.
<rharper> it may have it one day and not another
<rharper> we don't know if dhcp will return a gateway
<rharper> and we don't know which route they'd prefer (explict one)
<smoser> rharper, well, in your case its easy
<smoser> your networking ocnfig that you're supplied is definitive and says that the gateway is on the bond.
<smoser> so it should ignore anything else.
<rharper> I don't think so
<smoser> how so?
<smoser> the config says the gateway is on that device.
<rharper> at least it's not clear to me that we should do that; vs. saying bond has gateway is invalid when you also have a dhcp configuration
<rharper> a gateway
<rharper> you can have more than one, but must supply metric information
<rharper> I want to step back and query folks who have existing configurations and validate those;  if we need to emit some sort of dhcp ignore new gateway if we've defined one; then we can do that
<rharper> but it's more complicated than saying folks need to give us working input to begin with;
<rharper> until today; it wasn't obvious to me that you couldn't put in more than one gateway (as I expose my lack of networking-fu to the channel)
<rharper> retrospectively it seems obvious
<smoser> right.
<smoser> but your case is very simplified.
<Sweet5hark> stgraber: did you see the backlog?
<stgraber> Sweet5hark: oh, yeah, sorry, forgot to respond. I'm currently behind on a bunch of NEW reviews and am only around for a day or so next week due to travel, so unless you're fine waiting until after the 15th of September, I won't really be able to help you :(
<Sweet5hark> stgraber: do you have someone in mind from the dmb who might step in with a review?
<stgraber> Sweet5hark: as far as people being around on IRC lately, I can think of Laney and cyphermox but I have honestly no idea how busy they are these days :(
<Sweet5hark> stgraber: kk, thanks
<cyphermox> Sweet5hark: I can do reviews of stuff but I can't help you with NEW so much if it's to review things already in the queue
<stgraber> cyphermox: my understanding is that it's a packaging + sponsor review of libreoffice by a DMB member in preparation for Sweet5hark re-applying for PPU of libreoffice
<stgraber> *packaging review + sponsor
<cyphermox> yeah, that's fine
<cyphermox> except for the obvious "omg I'm uploading libreoffice"
<cyphermox> :)
<mterry_> bdmurray, ~sssd has committed to caring for nss-wrapper and uid-wrapper, FYI
<bdmurray> mterry_: that's a lot of s'es
<mterry_> bdmurray, :)
<slangasek> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: slangasek
<doko> mterry_, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg is your friend ;)
<mterry_> doko, I usually use check-mir
<mterry_> Just forgot  :(
<Umeaboy> Hi!
<Umeaboy> Any kernel devs here?
<Umeaboy> I know that the PPA on Launchpad is for Testing of the kernel, but I wonder when 4.1 will be released as an update to 15.04.
<Umeaboy> I have a driver issue with nouveau that I think is fixed in 4.1.
<Umeaboy> And YES I have installed nvidia-prime for my Optimus as well.
<Umeaboy> Sometimes Ubuntu 15.04 won't get to boot screen.
<Umeaboy> It just halts.
<infinity> Umeaboy: Never.
<infinity> Umeaboy: We don't update to new major kernel versions in stable releases (except for hardware enablement stacks on LTSes, which 15.04 is not)
<Umeaboy> infinity: Right.
<Umeaboy> Can I use the official tar from kernel.org and build the necessary packages then?
<infinity> I wouldn't recommend it.
<Umeaboy> I have little to no experience with building debs.
<Umeaboy> rpms YES.
<infinity> You can install the wily kernel on vivid, if you really want to go that route.
<Umeaboy> infinity: OK. Is there a changelog for it?
<sarnold> the kernel-package package provides some tools to help build debs from upstream kernels
<infinity> Yes, but upstream kernels lack all the Ubuntu sauce, which may not be what people really want.
<sarnold> *nod*
<Umeaboy> So, I have Hybrid Graphics.
<Umeaboy> One Intel and one Nvidia GeForce GTX 850M
<infinity> Umeaboy: There's a changelog: http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_4.2.0-7.7/changelog
<Umeaboy> The package nvidia-prime IS installed.
<infinity> Umeaboy: If you're experiencing an issue, though, filing a bug might be nice, too.  This isn't a support channel.
<infinity> Umeaboy: "ubuntu-bug linux"
<Umeaboy> Doesn't seem like it's solved.
<infinity> Umeaboy: You installed it to test?  Or you're just guessing from the changelog?
<infinity> Umeaboy: The changelog would be tens of thousands of lines if it listed every commit from 3.19 to 4.2
<Unit193> Does apport not actually file bugs now?
<sarnold> Unit193: it does, but not consistently, I'm not sure when it does vs when it just submits errors to the error tracker
<Unit193> Nice.
<Unit193> Thanks.
<Unit193> sarnold: Could be it was already filed (found it under a different package than I first expected.)
<Unit193> Found two debian bugs and an Ubuntu one.
<sarnold> Unit193: heh, that's almost worse than finding no bugs..
<Unit193> sarnold: Recent!  All filed today or yesterday!  There's hope still.
<sarnold> oh! :) hooray
<Unit193> (To be complete, lp 1492394)
<ubottu> Launchpad bug 1492394 in python-service-identity (Ubuntu) "TypeError: attributes() got an unexpected keyword argument 'apply_with_init'" [Critical,Confirmed] https://launchpad.net/bugs/1492394
<sarnold> Unit193: eww
<Umeaboy> Hi again!
<Umeaboy> I added the PPA for the Canonical Kernel Team, but I didn't get the 4.1-kernel when updating.
<Umeaboy> Could it be because I choose to not use Proposed Updates and Backports?
<infinity> Umeaboy: (a) it's 4.2, not 4.1, (b) which PPA, (c) did you add wily or vivid (4.2 is only in wily).
<slangasek> ppas include neither proposed updates nor backports.  however, that ppa exists for the kernel team's internal testing, not to provide newer kernels to users on older releases, so if you want the newer kernel you have to configure it to pull from wily as infinity says
<Umeaboy> infinity: OK. I guess I should change to Wily then.
#ubuntu-devel 2015-09-05
<samthewildone> whats up
<samthewildone> mwhudson, hey
<samthewildone> well then
<fredw> Hi, can someone please review https://code.launchpad.net/~fred-wang/ubuntu/wily/firefox/fix-for-1473552/+merge/268213 ?
<sidi> i'm building a library with a handmade makefile, and i'm struggling to find the proper rules to build debian library and header packages for it. Essentially i'm installing the files in $(DESTDIR)/usr/lib/ in my Makefile (which I suspect is wrong) and dh_install is not finding them in debian/tmp/usr/lib (since they apparently go to debian/pkg-name1/usr/lib) and fails
<sidi> Anyone got an example of a library package without autotools, by any chance?
<cjwatson> sidi: can you pastebin your debian/rules?
<cjwatson> and the Makefile as well, ideally
<sidi> cjwatson, sure, one sec
<sidi> Makefile: http://pastebin.com/6MhFyQKG // debian/rules: http://pastebin.com/NRNu3Qqn (pretty much as was generated)
<samthewildone> Straight outta bed
<cjwatson> sidi: that looks OK (except for the MAKEVARS setting which doesn't seem to do anything and if it did ought to be in a different place).  how about the debian/*install files?
<sidi> my preloadlogger1.install is usr/lib/lib*.so.* (which I've taken from other library-like packages)
<sidi> the -dev is usr/lib/lib*.so, plus etc/security/*
<cjwatson> sidi: should be fine, how about debian/compat?
<sidi> cjwatson, 9?
<cjwatson> sidi: that should be OK.  at this point I think it'd be helpful if you could put a full example source package somewhere so I can test it
<sidi> cjwatson, bzr+ssh://bazaar.launchpad.net/+branch/activityfinder/preload-logger/
<sidi> building the whole thing is really fast, it's a tiny library
<sidi> ... most of the commits being me attempting silly things to build the package
<cjwatson> this isn't the problem, but your Makefile would work better (i.e. install wouldn't have to repeat the build) if you had better dependencies - perhaps as a starting point, use "libPreloadLogger.so.0.9" as a target name rather than "lib", so that make knows it's already built
<cjwatson> this is the sort of thing not using a handmade Makefile does better at :-)
<cjwatson> oh I see
<cjwatson> sidi: you don't have preload-logger-dev defined in debian/control
<cjwatson> so debhelper is using its there's-only-one-package logic which is inappropriate here
<sidi> ah.
<cjwatson> (also, should be libpreload-logger1 and libpreload-logger-dev, really)
<sidi> well, the file i build is indeed a library but it's not really intended to be linked against for building other apps
<sidi> it's a LD_PRELOAD module loaded with PAM for process monitoring
<sidi> though I can change it
<cjwatson> I understand that but it doesn't change the library binary package naming rules
<sidi> i'll change it
<sidi> i think it's working better...
<sidi> still had a mistake in the libpreload-logger-dev.install
<sidi> cjwatson, once again, thank you!
<sidi> I suspect you're gonna end up in my thesis's acknowledgements section :-)
<cjwatson> heh
<cjwatson> no problem
<fredw1> Does anyone know who is in charge of reviewing patches for the Firefox package?
<fredw1> chrisccoulson is listed in the latest git revisions but these date back from 2012...
<cjwatson> fredw1: It would be chrisccoulson, yes, and if you're only seeing patches from 2012 then that must be because you're looking at an inactive branch.
<cjwatson> https://code.launchpad.net/~mozillateam/firefox/firefox.wily
<fredw1> cjwatson: thank you. I was looking at https://code.launchpad.net/~ubuntu-branches/ubuntu/wily/firefox/wily
#ubuntu-devel 2015-09-06
<mitya57> Mirv, I am going to sync qbs 1.4.2 from Debian because the latest upload fixes debian #795829, which is quite important.
<ubottu> Debian bug 795829 in qbs-doc "qbs-doc: wrong installation path of .qch file" [Normal,Open] http://bugs.debian.org/795829
<mitya57> Is it OK from qtcreator point of view? (I'll make sure that it builds of course)
<mitya57> Mirv, sorry, I meant debian #797774, not that
<ubottu> Debian bug 797774 in qbs "qbs projects are not build due to missing cpp scanner" [Important,Fixed] http://bugs.debian.org/797774
<ari-tczew> Can someone check whether "requestsync" does work? from my side it's a timeout. However, syncpackage works fine.
<ari-tczew> cjwatson, wgrant: might be it something related to LP's API? ^
<cjwatson> ari-tczew: can you show me the full output please?
<ari-tczew> cjwatson: w8, I was trying to fill a bug manually and I got this: (Error ID: OOPS-933ecce3baa55aec3f9502f1f0e41904)
<ari-tczew> about requestsync: there is no log, it's just hanging around without any error msg.
<cjwatson> just a bugtaskflat insert timeout, I'd just wait and try again a little later
<cjwatson> bit much for me to do any detailed investigation on a Sunday morning and by the time I can I'd expect it'll have gone away
<cjwatson> I'm guessing it's a lock held by some cron job maybe but that would take a while to pin down
<ari-tczew> cjwatson: ok, sorry for disturbing
<TJ-> When using pbuilder with --override-config --mirror XYZ, the generated sources.list contains the deb entry and a commented-out deb-src - is there a way to tell pbuilder to *not* comment out the deb-src line?
<ari-tczew> is it necessary to keep *.lintian-overrides in the case delta includes a gcc5 transition?
<ari-tczew> a lot of Debian packages don't ship it like our devs, I'm not sure whether such changes can we drop
<ari-tczew> slangasek: a lot of packages have got this change uploaded by you, could you share your feedback, please? ^
<ScottK> ari-tczew: if that's the only delta, don't bother keeping it.
<ScottK> Once lintian is updated from Debian, it won't be needed.
<ari-tczew> many thanks ScottK
<Laney> It already is AFAIK
#ubuntu-devel 2016-09-05
<pitti> xnox: indeed; it only iterates over arches for which it actually has queued or running jobs, but it behaves a bit weird
<pitti> xnox: use archive binaries, but run my tests from my source package> that's autopkgtest's normal (and only) mode, the test itself always comes from the tested source package; just run it with -B to avoid rebuilding the source
<pitti> jbicha: https://autopkgtest.ubuntu.com/running.shtml does redirect fine for me; can you please check again?
<jbicha> pitti: still doesn't work here
<mwhudson> morning pitti
<pitti> jbicha: hm, what shall I say -- works in firefox, chrome, and wget here, and I have a Redirect permanent /running.shtml /running
<pitti> jbicha: can you c&p what wget -O says?
<pitti> hey mwhudson, how are you?
<mwhudson> pitti: ok, trying to hack up a ui for console-conf to allow putting wifi config in
<mwhudson> man i hate ui code at the best of times, but console based uis have me pining for js :-)
<jbicha> pitti: ok, wget shows the right thing so I guess my cache needs to be cleared
<pitti> jbicha: where does it try to redirect you to?
<pitti> jbicha: there were some /browse.cgi intermediate paths, maybe I need to add another redirection for those
<pitti> although /browse.cgi/running also still works
<jbicha> https://autopkgtest.ubuntu.com/browse.cgi/running
<pitti> jbicha: try again?
<jbicha> works great now
<jbicha> pitti: what do you think of the new dbus-session-bus virtual packages from Debian? I was going to merge a package which recommends them
<pitti> jbicha: that's provided by dbus-x11?
<pitti> dbus-user-session too?
<jbicha> https://tracker.debian.org/media/packages/d/dbus/changelog-1.11.4-1
<jbicha> https://lists.debian.org/debian-devel/2016/08/msg00554.html
<pitti> jbicha: seems fine to me
<pitti> jbicha: if dbus 1.10.6 â 1.10.10 is bug fixes only (version number suggests that), it's also still fine for y
<jbicha> I don't think I know enough about dbus for that https://tracker.debian.org/media/packages/d/dbus/changelog-1.10.10-1 (is the correct link)
<jbicha> https://cgit.freedesktop.org/dbus/dbus/tree/NEWS?h=dbus-1.10
<pitti> jbicha: looks like we do want that
<RAOF> pitti: Would you very kindly be up for a colord upload, and a question about where to best get the systemd special locations from?
<pitti> RAOF: yes, and "pkg-config --print-variables systemd"?
<RAOF> pitti: Ah, so I'm right to build-depend on systemd (where systemd.pc is) then?
<pitti> RAOF: correc
<pitti> t
<pitti> RAOF: can you please do the gbp dch/release tag dance, and I'll upload it then?
<RAOF> Sure.
<pitti> (I often tend to edit the gbp dch result)
<RAOF> I'll do a final test-build in sid then ping you.
 * RAOF wonders if httpredir.debian.org has caught fire or something.
<Mirv> nothing more nice than filling the autopkgtest queues in the morning
<LocutusOfBorg> hi infinity fpc is finally fixed in Debian... and syncd in Ubuntu... bootstrap pretty please?
<LocutusOfBorg>  /cc doko ginggs ^^
<LocutusOfBorg> hi pitti, please ignore/skip ganeti testsuite? error type: insufficient_resources, error details:
<LocutusOfBorg> Not enough memory on node node1 for creating instance instance1: needed 1024 MiB, available 996 MiB
<LocutusOfBorg> it has been failing since the begin, or soon after the first build
<LocutusOfBorg> also fpc, please ignore the testsuite, buggy since a lot of time
 * RAOF wonders why his sid schroot is *still* updating?!
<pitti> RAOF: did you just forget to ping, or still building?
<pitti> LocutusOfBorg: bumped
<pitti> LocutusOfBorg: ... the hint, I mean
<LocutusOfBorg> thanks
<LocutusOfBorg> I hope them both :)
<cpaelzer> hi, after staring at this control file for too long maybe one has an extra hint regarding the architecture qualifiers https://git.launchpad.net/~ubuntu-server/dpdk/tree/debian/control?h=enablepowerpc
<cpaelzer> thrown at a ppa it works just as expected for arm64 to not-build some of the packages according to the Architecture in the control file
<cpaelzer> but for ppc64el it does not, it builds me empty packages and adds dependencies
<cpaelzer> ppa with packages created and buildlogs reachable from there is https://launchpad.net/~paelzer/+archive/ubuntu/deb-dpdk-16.07/+packages
<cpaelzer> I'll continue debugging, but I ran out-of-theories a few minutes ago so any idea would be welcome
<cpaelzer> There are avrious issues to that, but as an example the binary package librte-pmd-i40e1 is meant to (from dsc)
<cpaelzer> There are avrious issues to that, but as an example the binary package librte-pmd-i40e1 is meant to (from dsc): librte-pmd-i40e1 deb libs optional arch=amd64,i386
<cpaelzer> and it does indeed not build on arm64 as intended, but it builds an empty one on ppc64el
<xnox> cpaelzer, cat debian/control.orig debian/control.modules > debian/control
<xnox> cpaelzer, -> Package: librte-pmd-i40e1\n Architecture: amd64 i386 ppc64el -> hence built on ppc64el
<cpaelzer> xnox: thanks a lot
<cpaelzer> xnox: that was a changed not added by me that I totally overlooked, this pretty uch  seems like ti
<LocutusOfBorg> jbicha, how do you feel about this debdiff? http://paste.ubuntu.com/23136558/
<LocutusOfBorg> the m4 patch can be dropped
<LocutusOfBorg> because debian deletes it
<LocutusOfBorg> aldo the dbgsym bits
<LocutusOfBorg> not sure why he added cmake to b-d
<LocutusOfBorg> but meh, opening a bug
<highvoltage> /win 38
<jbicha> pitti: any recommendations for how to setup up an autopkgtest to run on every architecture except s390x? (thinking of libsecret)
<cpaelzer> jbicha: I've had success with a central compat checker referenced at the beginning of tests
<cpaelzer> jbicha: checker http://paste.ubuntu.com/23136777/
<cpaelzer> jbicha: test that uses it http://paste.ubuntu.com/23136778/
<cpaelzer> the intention was to have one place to enable/disable several tests
<pitti> jbicha: maybe you can run a subset of tests on s390x?
<pitti> jbicha: the test can check [ `uname -m` = s390x ] and exit early
<doko> jamespage, coreycb: https://bugs.launchpad.net/ubuntu/+source/pykerberos/+bug/1620293
<ubottu> Launchpad bug 1620293 in python-requests-kerberos (Ubuntu) "[MIR] python-requests-kerberos and pykerberos (deps of python-keystoneauth1)" [Undecided,Incomplete]
<LocutusOfBorg> doko, please demote mutt-kz, to have mutt migrate
<LocutusOfBorg> (same in Debian)
<jamespage> doko, I just demoted that to a suggested to avoid that - its not a hard dependency
<jamespage> I wish I could type on occasions
<jamespage> I mean't
<jamespage> I demoteded python-requests-kerberos to a Suggests as its not a hard dependency
<doko> ahh, ta
<RAOF> pitti: Still updating the sid chroot!
<RAOF> (Continues after a suspend/resume cycle!)
#ubuntu-devel 2016-09-06
<Trevinho> RAOF: hey
<Trevinho> RAOF: could you please review the unity7 xenial SRU that is in queue?
<RAOF> Trevinho: Sure!
<Trevinho> RAOF: related silo is https://requests.ci-train.ubuntu.com/#/ticket/1843
<Trevinho> RAOF: thanks a lot
 * RAOF dislikes reviewing SRU syncs. :(
<Trevinho> Eh, i'm sorry about that... We should really have some scripts which produces debdiff for these
<RAOF> Yeah, I could totally improve some of the scripts in ubuntu-archive-tools to do this.
<RAOF> Not your fault!
<Trevinho> RAOF: what would be the best way for helping SRU team in that? debdiffs attached to bugs, or what else?
<Trevinho> eh, I know.. I've heard about some difficulties about that, but I'm not much into that work to understand what's missing :-)
<RAOF> Trevinho: Make sru-review in lp:ubuntu-archive-tools handle syncs.
<cjwatson> It's really an LP bug, but quite a hard one to fix.
<cjwatson> (https://bugs.launchpad.net/launchpad/+bug/851562, specifically)
<ubottu> Launchpad bug 851562 in Launchpad itself "Diffs not available for syncs on +queue page like for regular uploads" [High,Triaged]
<RAOF> It would not be *that* hard to make sru-review DTRT; it'd just need to follow the sync link, then hope that the PPA has the regular stuff.
<RAOF> Trevinho: Presumably you need bamf, compiz, and unity all done at once?
<Trevinho> RAOF: yeah... I mean, there are no interdependencies... So you can actually land these in the order you want
<RAOF> Trevinho: Cool.
<Trevinho> RAOF: I see there's a from_ppa option in the review script, is that helpful?
<RAOF> Actually just checking that out :)
<RAOF> No dice, but --no-diff is helpful.
<RAOF> Heh. https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/913880 is clearly not fix-released in xenial :)
<ubottu> Launchpad bug 913880 in compiz (Ubuntu) "mouse scroll down over sound indicator while expo is active selects previous desktop" [Low,Fix released]
 * RAOF wishes PPAs built their debdiff against -updates
<Trevinho> ah, that's annoying...
<Trevinho> using options -p ci-train-ppa-service/landing-085 didn't give me anything though, but maybe it's just something else
<Trevinho> anyway... if there's any problem, let me know... time for bed now :-)
<RAOF> Trevinho: Do any of your bugs have xenial tasks? :)
<Trevinho> RAOF: no.... Cause I'm not an Ubuntu driver and I can't add these without confirmation it seems ð¢
<RAOF> Trevinho: You can nominate them, at least. But I'm happy to do so while processing, too. Just for future reference :)
<RAOF> Wow. That unity upload is all that and a bag of potato chips.
<RAOF> Trevinho: (For when you wake up) Is https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1616031 actually fixed in the uploaded unity and/or Yakkety?
<ubottu> Launchpad bug 1616031 in unity (Ubuntu) "Problems with restoring window size/position after half-maximizing" [Medium,Triaged]
<RAOF> Trevinho: Also, a *lot* of those bugs are pretty borderline SRUs.
<RAOF> Trevinho: Accepted the bamf and compiz SRUs, as they're good and correct.
<RAOF> Trevinho: Once you've checked that bug 1616031 is actually fixed in yakkety and the package, unity can (with some reservations) go through.
<ubottu> bug 1616031 in unity (Ubuntu) "Problems with restoring window size/position after half-maximizing" [Medium,Triaged] https://launchpad.net/bugs/1616031
<pitti> RAOF: urgh, seriously? that should take a few minutes, not a day..
<RAOF> IPv6 snafu, it seems.
<RAOF> Each package tried to resolve over IPv6 with a 1min timeout, failed, then tried again for the next package.
<RAOF> pitti: Anyway, ping!
<pitti> RAOF: aye!
<pitti> RAOF: "yakkety" â "unstable" in changelog, s'il te plaÃ®t
<RAOF> Ahem.
<RAOF> pitti: Done.
<pitti> RAOF: and built/uploaded
<cpaelzer> good morning
<RAOF> Oh, kfreebsd. Hush.
<pitti> RAOF: heh, --fail-missing FTW: )
<RAOF> touch debian/not-installed.linux; echo "/lib/udev/..." > debian/not-installed
<pitti> RAOF: oh, is debian/not-installed a thing? I wasn't aware of that
<RAOF> New in compat 9, I think?
<pitti> RAOF: I usually use some -X*.rules fu (conditionalized)
<RAOF> I think I'll go the not-installed route.
<RAOF> Aaargh. Git! When I push I want to push the signed tags, damnit.
<RAOF> pitti: I can't seem to push to colord git anymore, but the permissions on the repository seem fine? I was hoping to have another go at building on kfreebsd/hurd :/
<pitti> RAOF: uh, what happened since this morning? you still pushed the changed debian/changelog release target?
<RAOF> Yes! I don't know. I went to push 1.3.3-2 (that should build on kfreebsd/hurd, hopefully), and git is complaining about insufficient permissions on ./objects
<pitti> RAOF: some chmod -R on git.debian.org?
<RAOF> pitti: Everything seems to be 775, owned by mpitt:scm_collab-maint
<pitti> RAOF: uh, did I set up the colord.git? I don't remember that at all
<RAOF> pitti: Would you be able to pull from github.com:raof/colord.git ?
<pitti> RAOF: sure
<pitti> RAOF: there are a few files owned by raof-guest:raof-guest which should probably have group scm_collab-maint, but that shouldn't stop pushing for you..
<pitti> RAOF: oh, I do see a few files which are 444
<pitti> RAOF: perhaps do try a chgrp -R scm_collab-maint and chmod -R ug+w ?
<pitti> I just did that, but I cannot change the raof-owned ones
<RAOF> Nope
<pitti> RAOF: hmm, then I guess moving the whole colord.git/ dir away and re-creating/pushing it? I'm out of ideas
<RAOF> Oh, hello!
<RAOF> There are 3 files in objects/; two owned by mpitt:mpitt one by biebl:biebl.
<RAOF> Are you able to remove those final ones?
<pitti> RAOF: done
<pitti> RAOF: (pulled/building from github in the meantime)
<RAOF> And collab-maint/colord.git is now updated.
<pitti> RAOF: pulling works indeed, thanks
<pitti> RAOF: -2 uplaoded
<pitti> (which is better than uploading, obviously!)
<RAOF> It's more ladder-like.
<Trevinho> RAOF: so... We used to be pretty flexible in unty SRUs to keep the delta with trunk to the minimum
<Trevinho> So... Yes, there are bigger changes, but still all fixes
<Trevinho> RAOF: as for that bug, I thought I removed it from the changelog, didn't I?
<Trevinho> Since it wasn't fixed here
<Laney> what's this "Stale file handle" business that's going on with sbuild?
<Laney> anyone else seen that?
<pitti> Laney: oh, you got it too? xnox and me too
<pitti> I tried to apt-get clean/-f etc. in src:sid, but didn't help, so I just rebuilt it from scratch (easier than wasting time)
<Laney> pitti: first saw it yesterday and though it was some freak occurrence, but now I get it on other schroots too
<pitti> I only got it in my sid schroot; either because it was sid, or becasue that was my only schroot that used an overlay (the others are tarballs)
<xnox> Laney, pitti - you shall not use overlayfs and dpkg
<xnox> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1620525 our bug
<ubottu> Launchpad bug 1620525 in linux (Ubuntu Yakkety) "sbuild with overlayfs fails in yakkety" [Critical,New]
<pitti> it has worked for many years, but since all my others are tarballs I just use a tarball too now
<xnox> debian bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836211
<ubottu> Debian bug 836211 in dpkg "dpkg: Cannot upgrade some packages on overlayfs: Invalid cross-device link" [Normal,Open]
<pitti> and live with the 2 s unpack time
<xnox> pitti, use older kernel?
<Laney> xnox: do you know what changed?
<xnox> or newer....
<Laney> this has always been the case on overlayfs hasn't it?
<xnox> Laney, something rather fixed in overlayfs. Re-creating chroots with new enough apt pre-installed should work too, because then the subdir move is not needed.
<Laney> I get it on loads of random stuff
<Laney> Updating certificates in /etc/ssl/certs...
<Laney> mv: cannot move '/tmp/ca-certificates.crt.tmp.OgRoXw' to 'ca-certificates.crt': Stale file handle
<xnox> excellante.
<xnox> i bet all the live images are busted too
<tjaalton> looks like a xenial server of mine has had an unattended-upgrade in limbo since june
<seb128> tjaalton, like a stucked job? any error?
<tjaalton> yeah kernel install stuck
<tjaalton> nothing in dpkg.log
<seb128> urg
<seb128> do you know where it's stucked?
<tjaalton> grub-mount
<seb128> I guess that's worth at least a bug report
<tjaalton> then again this has zfs-on-root
<seb128> oh...
<tjaalton> eldon# LANG=C grub-mount /dev/sda1 /var/lib/os-prober/mount
<tjaalton> error: unknown filesystem.
<tjaalton> guess that's it
<seb128> well, it should handle the case better
<tjaalton> I'll file it against os-prober
<seb128> thanks
<tjaalton> hmm or grub2 actually
<pitti> juliank: there is no way to get a .dsc or diff for the synced apt 1.2.14 in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=apt
<juliank> pitti: Why?
<juliank> I just ran syncpackage for it :/
<pitti> juliank: this makes it extremely hard to review for SRU; normal uploads are a lot simpler
<pitti> juliank: this might also explain why nobody reviewed it yet
<Mirv> I seem to have many problems with "Finished" builds not really finishing like https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-1916/+build/10713715 (this is retry number two)
<pitti> oh, I can get it from here: https://launchpad.net/debian/+source/apt/1.2.14
<juliank> pitti: Yeah
<Mirv> maybe it's a test failure in content-hub though showing off as unkilled thread
<pitti> but this takes creativity (no click-through path), downloading two packages, running debdiff, etc.
<brendand> this feels like a dumb question, but i want to be able to ssh to the autopkgtest host from the testbed, without being prompted for a password - what are my options?
<pitti> brendand: scp your host's key to ~/.ssh/authorized_keys once?
<juliank> pitti: Right. I can upload (the next release) 1.2.15 as a .dsc for the next upload. infinity sort of wanted that to be in a PPA and then synced from the PPA, but if it's easier to look at, I can just re-upload the .dsc from the PPA then.
<pitti> juliank: got a diff now; I'm ok with accepting into -proposed, but for verifying (for -updates) I'd like to see an actual test plan such as testing a dist-upgrade with that apt, to see how it performs in big scenarios which the test suite doesn't cover
<brendand> pitti, i still get prompted for the password... maybe something i need to change in the hosts ssh configuration?
<pitti> brendand: no, this is determined by the guest, and this generally allows key-based auth (I do that often)
<pitti> brendand: maybe you forgot to say ubuntu@ ?
<pitti> brendand: the scp itself (for copying id_rsa.pub) will ask for the password of course, but after that it should work
<brendand> pitti, no i definitely did do that
<brendand> pitti, ah i think i know a way. i can set up the access in the base image
<pitti> brendand: please run ssh with -vv to see what it doesn't like about your key
<juliank> pitti: There were no changes at all to the installation code in 1.2.14 since 1.2.12(~ubuntu16.04.1) - don't you have some automated update testing tools in some QA thing somewhere?
<pitti> brendand: if this is lxc, lxd, or qemu, you can also funnel it in through the side channels like lxc-attach or ttyS1
<pitti> juliank: we have the autopkgtests, but AFAIK no automatic upgrade tests against -proposed
<pitti> we used to have some, or still have -- if so, running those is fine of course
<xnox> cjwatson, gimock fails to spawn things that are supposed to be executed in the subprocess as far as I can figure out. There is no stdin/stdout and the pipe that should unpickle things raised EOF. Who is the current maintainer of click/gimock?
<xnox> it's probably something changed in gi and/or python.
<cjwatson> xnox: already fixed in a silo awaiting QA approval
<xnox> ah excellent!
<cjwatson> https://requests.ci-train.ubuntu.com/#/ticket/1878
<cjwatson> xnox: (but I think it's waiting until after OTA13 - that's still in adequate time for yakkety so I'm not worrying about it too much)
<juliank> pitti: In the worst case, starting with a 16.04 image, install apt 1.2.14 and then upgrading to updates+proposed should be a good test
<cjwatson> xnox: there were quite a few little details wrong, I had a "fun" bit of weekend work sorting it all out
<juliank> 1.2.15 is going to be awful, I have queued 46 cherry-picked commits so far: https://github.com/Debian/apt/compare/1.2.14...julian-klode:1.2.y - one changes the cache format in order to fix a buffer overflow, and another one changes the main MarkRequired() algorithm to allow kernels to be autoremoved again in the presence of (zfs) virtual deps
<xnox> cjwatson, /o\ ok. So i'll grab that ppa, and retest that things don't regress with new python-debian / gpg -> because those trigger click tests. If all is good, I'll ask Laney to skiptest click on those packages.
<xnox> because gnupg2 transition is possibly stuck with click failure now.
<xnox> or possibly partially release above silo into yakkety only?
<juliank> Oddly enough, I did not reserve any space in the cache version, so both 1.3 and 1.2.15 have 10.6. That works now as they are the same format, but I should invent a better way to allow for independent changes in multiple branches of apt
<pitti> xnox: oh, I just force-badtest'ed the current click version as I thought it got broken by some apparmor thing, not the new gnupg2?
<xnox> pitti, no it's broken all by itself. the gnupg2 impact is unknown. It does use debsigs-verify thing, which uses gpgv, which should be fine.... but i want to test that.
<kgunn> flexiondotorg: ping
<cjwatson> xnox: I don't really want to think about doing a partial release, no idea how bileto would cope
<cjwatson> (hopefully it would be fine, but I don't know)
<Laney> xnox: are you winning?
<xnox> Laney, i am working on making more win
<Laney> k
<xnox> trying to fix parcimonie on our infra, it passes locally...
<Laney> well done for taking it on
<Laney> xnox: can provide you with access to a machine if you want
<xnox> nah it's all good. i create citrain thingy and it gives me access to our infra for adt
<Laney> you can operate it interactively then
<Laney> but ok
<doko_> tvoss: any update on unity-scopes-api and thumbnailer?
<Laney> xnox: reproduces for me with an adt-buildvm-ubuntu-cloud thingy btw
<xnox> Laney, i use lxc locally.
<Laney> well you also couldn't reproduce it
<Laney> just saying :)
<xnox> right. it's building in bileto, and should fix things there ( i did a blind patch ) in the mean time porting buildroot
<Laney> ahh
<Laney> xnox: add-apt-repository doesn't work out of the box due to dirmngr not getting installed
<xnox> muahaaaaaa
 * xnox ponders why it needs dirmngr all of the sudden....
 * Laney knows nothing
<doko_> Laney: please could you just attach the D file that triggers the issue? #1620681
<Laney> if you want
<doko_> ta
<doko_> Laney: I want the command line too ;p
<Laney> I doubt you can build those things alone
<bdmurray> pitti: the ubuntu-release-upgrader package tests started failing recently and I wonder if its related to the server change - http://autopkgtest.ubuntu.com/packages/ubuntu-release-upgrader
<bdmurray> pitti: the same failure happens if changelogs.ubuntu.com is not accessible when running test_dist_upgrade_fetcher_core.py
<Laney> doko_: got a reasonably minimal reproducer now
<pitti> bdmurray: which server change? was changelogs.u.c. changed recently and the test needs updating?
<bdmurray> pitti: I mean the autopkg test server
<pitti> bdmurray: I'm not aware of any change there; IS changed the firewall the other day, but the proxy should still behave as it used to
<bdmurray> pitti: is there anyway to test the firewall manually?
<pitti> bdmurray: sure, I can run things in a scalingstack instance
<pitti> bdmurray: indeed wget -O- http://changelogs.ubuntu.com/last_check.txt hangs now
<pitti> it seems our proxy stopped allowing changelogs.u.c.
 * pitti adds it to $no_proxy
<bdmurray> pitti: thanks
<bdmurray> pitti: also, the link back to the package here is broken http://autopkgtest.ubuntu.com/packages/u/ubuntu-release-upgrader/trusty/amd64
<pitti> bdmurray: I rolled out the proxy config update, so a retry ought to work now
<pitti> bdmurray: link fixed, thanks for pointing out
<nacc> smoser: thanks for the importer bugs and MRs, I'll try and get to them this week!
<smoser> nacc, cool. thanks.
<jbicha> sakrecoer: where did you get numix-blue from?
<jbicha> numix-blue should really be a separate source package (I can't tell what version it claims to be or where it came from or who wrote it)
<krytarik> jbicha: We are planning to get it in via Debian - but it was too late for this release.
<jbicha> krytarik: ok, I understand UI freeze
<Unit193> LocutusOfBorg: ...Feel like sponsoring something super simple to Debian?
<flexiondotorg> kgunn, Hi
<kgunn> flexiondotorg hey :)
<flexiondotorg> I was busy at work today so not on IRC.
<flexiondotorg> But, evening now :-)
<flexiondotorg> kgunn, How you doing?
<kgunn> good, you? i wanted to pick your brain, as mine got fuzzy, but I was wondering about those gpu drivers...
<flexiondotorg> OK
<kgunn> i couldn't recall were those closed source? or are those in some way realted to the freedesktop project here
<kgunn> https://github.com/anholt/mesa/wiki/VC4
<flexiondotorg> Those are the drivers.
<LocutusOfBorg> Unit193, yes
<LocutusOfBorg> but I guess you will have to send a mail :)
<Unit193> LocutusOfBorg: Git or dch?
<kgunn> flexiondotorg awesome, so do you know the story on those? e.g. is that a broadcom supported project?
<flexiondotorg> kgunn, My understanding is Eric used to work for ARM (maybe Broadcom) but is now in the employee of the Raspberry Pi Foundation working specifically on those drivers.
<kgunn> flexiondotorg ah, that's great...
<kgunn> flexiondotorg and our guys recently enabled gallium as part of the archive build...
<kgunn> so these should "just be there"
<flexiondotorg> Yes.
<flexiondotorg> They are in the 4.4 Ubuntu Kernel. At least a version of them.
<flexiondotorg> And the corresponding mesa and xserver pieces.
<flexiondotorg> In 16.04.
<kgunn> flexiondotorg cool, better story than i thot
<kgunn> time to get a pi3 i gues
<flexiondotorg> But I'm using the Raspberry Pi Foundation kernel on those demos I showed you.
<flexiondotorg> The Ubuntu kernel needs some more Pi 3 hardware enablement.
<flexiondotorg> Last time I checked.
<kgunn> flexiondotorg missing gpu firmware? or kernel modules for things?
<flexiondotorg> https://github.com/gohai/vc4-buildbot
<flexiondotorg> I think missing device tree for VC4.
<LocutusOfBorg> Unit193, I prefer mentors
<flexiondotorg> And firmware for wifi (I think).
<Unit193> LocutusOfBorg: Oh dang, I was going to link you to https://sigma.unit193.net/source/inxi_2.3.1-1.dsc or ssh://git.debian.org/git/collab-maint/inxi.git :3
<Unit193> I can do that too.
<flexiondotorg> kgunn, Eric was at Intel previously.
<kgunn> thanks flexiondotorg
<kgunn> will help a discussion i'm having tomorrow
<flexiondotorg> Great. I'd love to see for Pi 2/3 is the Ubuntu raspi2 kernel.
<flexiondotorg> There are several million of those devices out there now.
<LocutusOfBorg> Unit193, .
<flexiondotorg> So worth targeting.
<Unit193> LocutusOfBorg: Oh wow, thanks.  Had just uploaded to mentors!
<LocutusOfBorg> oops, sorry
<Unit193> Nono, totally fine.  Thanks. :)
<LocutusOfBorg> :)
<doko_> jamespage: I filed rt#95411 for the porter box updates :-/
<Unit193> nacc: Oh, never said because you were offline.  Congrats!
<nacc> Unit193: thanks!
<sarnold> oh!
<sarnold> nacc: congratulations :)
<nacc> sarnold: thanks!
#ubuntu-devel 2016-09-07
<Bluefoxicy> pissing off everyone on ubuntu-devel-discuss in 3, 2, 1...
<mwhudson> heh heh i ran "EB_BUILD_OPTIONS=nocheck sbuild -d yakkety"
<sakrecoer> jbicha: from upstream, https://github.com/numixproject/numix-gtk-theme/issues/508 :) we just grep'ed all the colors from red to blue :)
<jbicha> sakrecoer: oh
<pitti> Good morning
<sakrecoer> morning! :)
<pitti> bdmurray: http://autopkgtest.ubuntu.com/packages/ubuntu-release-upgrader passed again except on armhf
<jamespage> doko_, great - thankyou!
<LocutusOfBorg> hi, sigh  cp: error writing 'debian/insighttoolkit4-python/usr/lib/python2.7/dist-packages/itk/itkCenteredTransformInitializerPython.py': No space left on device
<LocutusOfBorg> ppc64el
<LocutusOfBorg> do you think we have machines with more free space?
<mwhudson> pitti: autopkgtests are confusing me again, http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#docker.io says "in progress" but it's lying
<mwhudson> or at least inconsistent with http://autopkgtest.ubuntu.com/running
<pitti> mwhudson: looking
<pitti> ERROR:root:http://10.24.0.175:8080/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/d/docker.io/20160907_055947@/result.tar is damaged, ignoring: "filename 'testpkg-version' not found"
<pitti> mwhudson: ah, that's it -- https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/d/docker.io/20160907_055947@/log.gz
<pitti> mwhudson: autopkgtest seems to have trouble with unpacking the source, I'll have a look
<mwhudson> pitti: special
<pitti> mwhudson: hmm, can't reproduce locally or on infra, and a retry worked; sun rays/temp network failure/fingers in ear/lalala etc.
<mwhudson> pitti: ok, so it's run on the real infrastructure now?
<pitti> mwhudson: yes, and http://autopkgtest.ubuntu.com/packages/d/docker.io/yakkety/amd64 has the actual result now
<mwhudson> huh lxd does not depend on lxd-client
<mwhudson> TIL!
<pitti> mwhudson: Restrictions: needs-recommends, or add it explicitly
<pitti> mwhudson: indeed, you can have a box which is only a remote lxd server
<mwhudson> pitti: yeah, added it explicitly
<pitti> PSA: autopkgtest infra will go down for a bit for redeployment; I'll mop up any missed britney tests afterwards
<Laney> doko_: do you know if anyone is aware of/looking at the mir ftbfs in yakkety-proposed?
<Laney> found https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1619616
<ubottu> Launchpad bug 1619616 in protobuf (Ubuntu) "Mir test fails with protobuf3: Protobuf-can-be-reloaded (SEGFAULT)" [High,In progress]
<cjwatson> LocutusOfBorg: all builders have identical disk allocation and are started from a fresh image between builds
<tseliot> pitti: hi, can you help with LP: #1619306 , please? nvidia is in NEW
<ubottu> Launchpad bug 1619306 in ubuntu-drivers-common (Ubuntu) "SRU request: Include the 367 driver in Ubuntu 16.04" [High,In progress] https://launchpad.net/bugs/1619306
<pitti> tseliot: not right now (I don't want to stop redeploying our test infra), maybe later
<tseliot> pitti: ok, thanks
<LocutusOfBorg> cjwatson, it makes no sense then :)
<LocutusOfBorg> the previous upload was successful
<LocutusOfBorg> and changes are not worth a size change
<cjwatson> LocutusOfBorg: ok, can't help with that, but I thought you might find it helpful to know that any exploration of the form "clean up builder" or "use a different builder with more space" is a red herring
<LocutusOfBorg> yes, and thanks for that :)
<cjwatson> your build may have slightly nondeterministic size
<LocutusOfBorg> the question hidden was something like "did anybody reduce the size of the ppc64el builders in the last 10 days"?
<LocutusOfBorg> but the answer should be "nobody" and the size is increased from time to time, not reduced
<LocutusOfBorg> so, exploring other possibilities
<cjwatson> LocutusOfBorg: basically the only way that could happen is if the inter-build reset was quite a while before the build started so that the launchpad-buildd log had grown larger - but that's really quite a negligible amount of space
<cjwatson> there are things we could do like running apt-get clean after installing build-deps, but even then the amount of space involved should not be *that* large
<cjwatson> there's no cruft build-up over time
<LocutusOfBorg> Build needed 08:42:50, 2391164k disc space
<LocutusOfBorg> this is from the old build
<LocutusOfBorg> I can also remove the debian/tmp after dh_install :)
<LocutusOfBorg> 	rm -rf BUILD debian/tmp
<LocutusOfBorg> already done :(
<LocutusOfBorg> Laney, pretty please can you look at merging gnome-pkg-tools? your "X-AppStream-Ignore=true" can't be merged
<Laney> LocutusOfBorg: We dropped that whole script there, so just copy it from the Ubuntu package when merging.
<LocutusOfBorg> ok thanks
<LocutusOfBorg> so, can I merge Laney? :)
<Laney> Sure
<LocutusOfBorg> -         python3,
<LocutusOfBorg> -         python3-gi,
<LocutusOfBorg> -         gir1.2-glib-2.0
<LocutusOfBorg> they have been removed from runtime-deps
<LocutusOfBorg> readding
<Laney> Yes
<LocutusOfBorg> according to svn, they are dropped with the pkg-gnome-compat-desktop-file removal
<Laney> Basically revert that commit
<LocutusOfBorg> yep
<pitti> Laney: FYI: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=d1ac20f3c5 and https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure?action=diff&rev2=66&rev1=65
<pitti> Laney: this should also reduce worker failure spam now
<pitti> Laney: i. e. only the 6-hour maintenance cron job will show the logs of permanently failed workers, not the ones any more which recover quickly (nobody pays attention to them anyway)
<semiosis> anyone know whats up with the daily builds of xenial on cloud-images?  latest one is a week old (aug 30)
<semiosis> Odd_Bloke: ?
<Odd_Bloke> semiosis: I'll ensure that the livecd-rootfs change has been picked up in our build PPA, then kick one off. :)
<semiosis> Odd_Bloke: sweet!  thank you
<Odd_Bloke> semiosis: (It triggers automatically on changes to packages _in_ the image, which doesn't apply to livecd-rootfs :)
<semiosis> Odd_Bloke: that makes sense
<Laney> pitti: nice; what else changed with moving to xenial?
<pitti> Laney: mostly the upstart â systemd move and moving teh notification mails from the worker upstart job into the maintenance cron script
<pitti> Laney: the rest is just gory small details
<Laney> nod
<Laney> well, good work!
<pitti> Laney: but this got rid of this wget | dpkg -i thing and the backport PPA, the workers are easier to stop now (cgroup units et al), and it can now be ported to py3
 * Laney is re-jujuing for appstream-generator as well
<Laney> tried to look at Mojo again
<Laney> *cough*
<Laney> also juju 2.0 appears to be fairly different to 1.x
<pitti> Laney: yeah, I keep trying 2.0, but earlier it got stuck on deploying, and now this silly 2.1 versioning bug
<pitti> Laney: 2.0 appears much nicer locally (it doesn't pull in all that crap on the host, but everything into lxd containers)
<Laney> pitti: oh, does it? I didn't get that far due to lxd bug and I wasn't sure if I could use it on wendigo anyway
<Laney> like if the charms are going to be compatible
<pitti> Laney: charm format hasn't changed much AFAICS
<pitti> Laney: but no juju 2.0 on wendigo indeed
<pitti> I was just hoping for a nicer "local" experience
<Laney> ya
<Laney> I'd probably end up using a 2.0 feature by accident
<pitti> old juju-local clutters the host and fails with ecryptfs (units need to be manually started after login, etc.)
<Laney> might try "juju-deployer" though if I can figure it out
<Laney> hopefully make the nagios/bootwhatsitcalled/turku setup easier
<Laney> basenode
<pitti> Laney: hm, I downgraded to 2.0.4 (that took some time), and now it fails due to
<pitti> ERROR failed to bootstrap model: cannot start bootstrap instance: unable to get LXD image for ubuntu-xenial: The requested image couldn't be found.
<pitti> Laney: that doesn't ring a bell with you by any chance?
<pitti> ah, nevermind -- installed https://launchpad.net/ubuntu/+source/juju-core/2.0~beta17-0ubuntu1.16.10.1/+build/10695313 and that works with lxd 2.1 and also downloads the image
<pitti> (that's just stuck due to FTBFS)
<Laney> nie
<Laney> nice*
<Laney> I didn't get that far :)
<pitti> Laney: nice, with that "juju bootstrap lxd-test localhost; juju deploy rabbitmq-server" Just Worksâ¢
<Laney> pitti: Maybe I'll try it again tomorrow or so then
<Laney> iterating on canonistack isn't that fun
<seb128> Saviq, cyphermox, was there anything else needed on bug #1613678? the hardening was enabled and the buglist seems short enough?
<ubottu> bug 1613678 in unity-notifications (Ubuntu) "[MIR] unity-notifications" [Undecided,New] https://launchpad.net/bugs/1613678
<Saviq> seb128, not that I know of, wasn't sure how to change the status to get it back in business
<cyphermox> seb128: I'd like to re-review to say
<seb128> cyphermox, can you do that this week?
<cyphermox> I will do that today
<seb128> thanks
<pitti> Laney: so, nice -- that's the first time juju-2.0 ever worked for me, and now it works without a hitch
<pitti> ... except for tab completion which is broken
<Laney> pitti: So you're going to use this to develop charms which you'll deploy on 1.25?
<pitti> Laney: not sure yet, but I at least wanted to play around with it
<pitti> Laney: I need to charm up the langpack-o-matic stuff, I think I'll use it for that
<pitti> Laney: and I at least want to make the autopkgtest charms compatible with juju-2.0, as that's the default juju on 16.04 now
<pitti> Laney: so I'm more worried about compatibility in that "upward" direction
<Laney> pitti: Are there problems in that way?
<Laney> too early to tell? :)
<pitti> Laney: I hope not -- as I said, I've never gotten j-2 to work until now :)
 * pitti â dinner
<octoquad> hi, can anybody tell me how I can create a branch for the software-center based off the latest revision for trusty. I don't see any obvious branches to fork from.
<rbasak> octoquad: bzr-based UDD is deprecated. Use "pull-lp-source software-center trusty" to grab the latest source (without VCS).
<octoquad> rbasak, thanks, it's been a while since I contributed!
<octoquad> ls
<nacc> rbasak: re: LP: #1579480 and similar bugs, is there a best practice for dealing with 'manually' installed packages that no longer exist in the new release?
<ubottu> Launchpad bug 1579480 in php-defaults (Ubuntu) "PHP7-ubuntu sessionclean searches for "php5" named binary" [High,Invalid] https://launchpad.net/bugs/1579480
<nacc> rbasak: e.g., LP: #1617397 might be related to the same idea (php5 packages sticking around)
<ubottu> Launchpad bug 1617397 in php5 (Ubuntu) "Some php5 packages not upgraded to php7 from 14.04 to 16.04" [Wishlist,Triaged] https://launchpad.net/bugs/1617397
<rbasak> nacc: if the new php-common should cause php5-common to be removed on upgrade, then maybe a Conflicts/Replaces? I'm not sure.
 * rbasak consults https://wiki.debian.org/PackageTransition
<rbasak> Maybe #11?
<rbasak> I'm interested in ondrej's opinion. We should probably do what he says here (and not diverge).
<nacc> rbasak: ack, i asked him in the second bug
<nacc> rbasak: also just took a look at debian sid and it seems to match what we currently have, afaict. Interesting, php-common breaks (versioned) php5.6-common which doesn't exist in debian, and not php5-common at all.
* sexy-guy changed the topic of #ubuntu-devel to: Why won't pretty girls talk to me?
<sexy-guy> Why won't pretty girls talk to me?
<Unit193> dax.
<sexy-guy> Unit193: Why won't pretty girls talk to me?
<sexy-guy> dax: Why won't pretty girls talk to me?
<dax> Unit193: danke
<Unit193> dax: Thank you.
* dax changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | 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:
<dax> Unit193: reminder about pondering changing this channel's ACL
<nacc> smb: around?
<mwhudson> pitti: is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834367 going to be fixed in xenial?
<ubottu> Debian bug 834367 in systemd "systemctl daemon-reexec (as run on systemd upgrade) causes all keystrokes to go to text console in addition to X (including passwords)" [Critical,Fixed]
<nacc> just to confirm, an SRU to a package with version currently 7.0.5+dfsg-4build1 should result in 7.0.5+dfsg-4ubuntu0.1?
<sarnold> nacc: yes, that's what we've got in our version-number-table https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<nacc> sarnold: yep, just my first upload, so didn't want to mess up :)
<nacc> sarnold: thanks!
<nacc> sarnold: for dput to xenial-proposed, it would be `dput ubuntu:xenial-proposed <changes file>`, correct?
<sarnold> nacc: that's what my notes say, but I've never done uploads outside of -security
<jbicha> you might even be able to do 7.0.5+dfsg-4ubuntu1 if that version doesn't and won't exist in any later Ubuntu release
<nacc> sarnold: ack, thanks -- many of the documents i'm finding just keep referring to 'when you do an upload', without specifying exactly what to do :)
<nacc> jbicha: true, i figured i was best off being consistent with the security team's documentation
<cjwatson> you don't specifically need to dput to ubuntu:xenial-proposed
<cjwatson> what matters is what's in the Distribution field in the .changes, which is generated from the first line of debian/changelog
<cjwatson> and "xenial" will do fine there, that's mapped to xenial-proposed automatically
<cjwatson> assuming that's correct then you can just dput to ubuntu
<nacc> cjwatson: ah ok, good to konw
<nacc> *know
<nacc> maybe that's why it's not easy to find that detail :)
<cjwatson> what matters> well, if you specify a particular dput target then that will override
<cjwatson> but most people don't
<nacc> right
<nacc> cjwatson: thanks again!
<sarnold> ah thanks :)
<Unit193> 'devel' is even more fun. >_>
#ubuntu-devel 2016-09-08
<pitti> mwhudson: err, that bug never affected xenial; it was introduced in some commit in 231 and reverted/fixed shortly after
<mwhudson> pitti: it's happening to me right now
<mwhudson> and i'm on xenial
<pitti> mwhudson: if you see a similar effect under xenial, please file a new bug, it's something completely new and unknown then
<mwhudson> pitti: oh goodie
<pitti> Good morning
 * mwhudson ubuntu-bugs
<mwhudson> pitti: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1621327
<ubottu> Launchpad bug 1621327 in systemd (Ubuntu) "alt-left/right moves VTs even when in X" [Undecided,New]
<pitti> mwhudson: oh, so keystrokes don't go to the VTs or mess up the console, only Alt+Left/Right?
<mwhudson> pitti: yeah
 * pitti actually has no idea what handles [Ctrl+]Alt+Left/Right, I thought that was the kernel itself
<mwhudson> so i guess it's not quite the same
<pitti> mwhudson: and is that happening in y for you too?
<mwhudson> pitti: no, i'm on x
<mwhudson> pitti: only started recently, i wonder what the chances that it'll stop if i restart...
<pitti> mwhudson: so this only happens after an upgrade, not after a fresh boot?
<mwhudson> pitti: to be fair i don't know what caused it
<pitti> this needs some reproducer and collecting data, I'm afraid; I don't get that here, nor did I see this before in bugs
<mwhudson> i just mentioned my symptoms and someone mentioned that debian bug
<pitti> I'll do some research what handles the (Ctrl+)Alt keys
<mwhudson> i'll reboot and see if it goes away :-)
<mwhudson> pitti: yeah, i rebooted and it's stopped
<RAOF> Oh, *that* bug!
<RAOF> Oooh, does it happen when updating systemd?
<stgraber> mwhudson: sudo kbd_mode -s
<RAOF> (That happens on yakkety too)
<stgraber> mwhudson: I've had a few systems where the console got reset to non-raw mode (on Xenial) which can cause the symptoms you described above
 * pitti runs systemctl daemon-reexec, and sudo apt-get install --reinstall systemd, nothing here
<pitti> maybe it sometimes restarts console-setup.service or so? /me tries
<stgraber> mwhudson: yep, confirmed that if I intentionaly break it with "sudo kbd_mode -u" I do get exactly what you described, "sudo kbd_mode -s" fixes it
<pitti> I tried to restart console-setup.service, keyboard-setup.service, setvtrgb.service, all fine; does that trigger the bug for you?
<mwhudson> stgraber: ah
<pitti> xnox: hm, today's dist-upgrade pulls in gnupg-l10n gnupg1 gnupg1-curl gnupg1-l10n
<mwhudson> pitti: yeah, those don't seem to do anything
<pitti> xnox: I thought we wanted to move to 2 only?
<mwhudson> stgraber's thing seems to match my symptoms
<pitti> Laney: FYI, I got it working last night: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=df691943dc
<pitti> Laney: i. e. nothing to change in the charms, just driving the juju-1 vs. -2 CLI in the deploy.sh script needs adjusting; now it works with both
<smb> nacc, Not at such times. I am UTC+2 right now ;)
<pitti> Laney: I ran into bug 1621336 (but that happens with juju-1 too) and bug 1621237, otherwise works great
<ubottu> bug 1621336 in snapd (Ubuntu) "snapd.boot-ok.service hangs eternally on cloud image upgrades" [Undecided,New] https://launchpad.net/bugs/1621336
<ubottu> bug 1621237 in Charm Helpers "get_local_nodename() fails in IPv6 addresses" [Undecided,New] https://launchpad.net/bugs/1621237
<dholbach> smb, happy birthday! :)
<sakrecoer> hi! we have a situation in ubuntu studio, non of our members have upload rights. could anyone of you help us with that or point me to someone who could?
<sakrecoer> and happy birfday smb! :) virgo power!
<smb> thanks
<pitti> ooh, alles Gute smb!
<smb> pitti, danke danke :)
<sarnold> gratulieren smb :)
<smb> danken sarnold
<smb> :-P
<xnox> pitti, ack. let me look into reverse-deps and kick things out.
 * xnox is glad things finally landed.
<pitti> xnox: oh, might be because I have signing-party installed
<pitti> xnox: indeed, congrats! nice work
<xnox> pitti, ... however i will be sad if caff cannot do gnupg2....
<pitti> xnox: so indeed my main concern was to not install it by default on images
<pitti> Package: gnupg
<pitti> Task: minimal
<pitti> I suppose we should update that :)
<pitti> also, minimal seems harsh
<pitti> apt prefers gpgv over gpgv2, at some point we should flip that around
<xnox> it's not that harsh. we rely on master key for archive key migrations.
<pitti> xnox: but that should be gpgv2, not gnupg
 * xnox thought gpgv is now 2.1, gpgv2 transitional, gpgv1 old one? (same as gnupg)
 * xnox checks
<pitti> xnox: oh, you are right, nice
<pitti> so we don't actually seed gpg or gnupg
<pitti> must come through dependencies, or the Task: headers didn't get recomputed after that
<pitti> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt has a lot of stuff which wants to get lifted, but no gpg 1 stuff to get dropped, hmm
<xnox> pitti, https://launchpad.net/ubuntu/+source/gnupg should be demoted to universe and/or removed
<xnox> as it should be replaced fully now by src:gnupg2 & src:gnupg1
<pitti> indeed, it's on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<xnox> cool
<pitti> only the source, for some reason
<pitti> ah, the gnupg binary is from gnupg2 now
<pitti> xnox: hm, do we actually want/need pinentry-curses as Priority: important (i. e. in the standard install, even in containers) now?
<xnox> it's either that or
<pitti> seb128, Laney: who knows about ubuntu-system-settings these days? it's the remaining thing on http://people.canonical.com/~ubuntu-archive/nbs.html, thus a thorn in my eye :)
<seb128> pitti, kenvandine and jgdx
<xnox> telling everyone to "echo allow-loopback-pinentry >> ~/.gnupg/gpg-agent.conf" and "echo pinentry-mode loopback >> ~/.gnupg/gpg.conf"
<seb128> you probably want Ken for packaging changes
<pitti> seb128: thanks
<seb128> yw
<mitya57> Mirv, I would like to get https://codereview.qt-project.org/170467 and https://codereview.qt-project.org/170460 into yakkety, but I want to wait for +2s first.
<mitya57> Maybe there will be one more fix from me, related to desktop notifications. But I have not yet written it :)
<Mirv> mitya57: I noticed them both, yes feel free to add them to qtbase packaging once +2. I'm (just) done now with my changes for a while.
<Mirv> mitya57: ok :)
<mitya57> Mirv, I'm a bit sorry that we now have too many patches, but on the other hand we'll have less bugs and complaints :)
<Mirv> mitya57: well this was hoped all along to get appmenu truly fixed for xenial+1, it's great to have these
<xnox> pitti, trying out systemd-graphical-session.... do i still need ppa and hud from that ppa and systemd-graphical-session?
 * xnox gets no hud/unity running
<pitti> xnox: half of it landed in yakkety proper, the other half has been stuck in https://requests.ci-train.ubuntu.com/#/ticket/1710 for a while
<pitti> xnox: but I believe Trevinho is working on landing the unity bits
<pitti> xnox: but the PPA is still expected to work, for the indicators, hud, and unity
<xnox> horum
<xnox> bamfdaemon failed for me, and then unity7 failed with dependancy wait
<xnox> pitti, i ponder about: alias userctl='systemctl --user'
<xnox> manually starting bamfdaemon works, and things look like they work.
<pitti> what did it fail on?
<xnox> the combos of upstart, systemd, gnome-session are a bit weird =)
<xnox> pitti, it was failing to aquire the dbus name for the org.Bamf whatever.
<pitti> xnox: hm, did both the upstart and the systemd job try to run?
<xnox> so it seems like bamfdaemon was started, respawned, hit limit, before user dbus was up.
<xnox> yes. my dbus is under upstart control it seems.
<xnox> and gnomne-session
 * xnox is weird and i have gnome-session (Unity) also under upstart
<pitti> hm, this is all supposed to be moved already
<xnox> and url-dispatcher, mediascanner-2.0
<pitti> dbus-user-session still installed?
<xnox> yeah.
<brendand> AdUw3Maa83!
<xnox> pitti, i have dbus-user-session installed, and i have two dbuses....
<xnox> systemctl --user status dbus pid 25133
<xnox> initctl --user status dbus process 27389
<doko_> Laney: yes, alan_g is looking at the mir test failure
<Trevinho> xnox: yeah... Please add an alias for that... Ora soooo annoying :-)
<xnox> i see no override for dbus in /usr/share/upstart/systemd-session/upstart
<Trevinho> xnox: as for unity, the other landing should be enough
<xnox> how is dbus supposed to run?
<xnox> this is amazing.... switched to tty and the gpg-agent still works =)
<pitti> xnox: via "systemctl --user status dbus.service"
<pitti> xnox: yep, the magic  of user bus :)
<Laney> Trevinho: are you still waiting for a second review?
<xnox> ok. and the $ initctl --user status dbus -> shouldn't be running? is it on manual for you?
<pitti> xnox: i. e. /usr/lib/systemd/user/dbus.service will always run, independent of our systemd-ified session startup
<xnox> sure. but something needs to get rid of the upstart user session dbus, no?
<Trevinho> Laney: yep...
<pitti> xnox: yes, indeed; trying to remember what does that
<Laney> meh
<pitti> xnox: ah, here: http://launchpadlibrarian.net/261442770/dbus_1.10.6-1ubuntu3_1.10.6-1ubuntu4.diff.gz
<pitti> xnox: we built it into the upstart dbus job itself
<pitti> xnox: so you should still have the upstart job running as we need it as a "stub" to start reverse dependencies, but it should only run "sleep infinity"
<pitti> (this can probably be made more elegant somehow, by merely having it appear as running but not execing anything)
<Laney> Trevinho: ted_g approved it
<xnox> right that pid is sleep infinity
<xnox> more elegantly, one would "initctl emit started JOB=dbus" and that's it.
<xnox> without actually running/respawning sleep infinity.
<pitti> sounds nice
<Laney> wouldn't that make it stop straight away?
<xnox> why?
<Laney> the process would finish
<highvoltage> l/win 46
<pitti> right, "stop on stopped dbus" needs to continue to DTRT
<pitti> if things are only listening for "started dbus", that'd be fine
<pitti> but ISTR having seen a job which does nothign on exec and just has pre/post-start
<Laney> RemainAfterExit=yes # oh wait
<Laney> yeah, gpg-agent does that
<Laney> I forgot precisely what events that causes
<Laney> but then you could just do /bin/true
<Laney> assuming it goes to started
<Saviq> xnox, hey, shouldn't gnupg in yakkety depend on dirmngr now?
<pitti> I thought it would only work for that as nothing does "stop on stopped gpg-agent"
<Laney> hang on, this is easily testable
<Laney> .config/upstart to the rescue
<xnox> Saviq, Laney asked me that as well. I'm not sure. what are the symptoms you hit?
<Saviq> https://unity8-jenkins.ubuntu.com/job/run-commands/node=jenkins-slave-0/lastBuild/console
<Saviq> xnox, â
<Laney> pitti: Don't think it works, since you still need the exec block for the old case; this trick only works if you have pre-start but no exec (or script)
<xnox> Laney, echo 'start on starting xsession-init' > ~/.config/upstart/dbus.conf
<xnox> Laney, echo 'stop on stoping xsession-init' > ~/.config/upstart/dbus.conf
<xnox> Laney, echo 'stop on stoping xsession-init' >> ~/.config/upstart/dbus.conf
<xnox> start dbus; status dbus -> running; stop dbus -> stopped.
<xnox> Laney, why do we need it for the old case? systemd user dbus session is always available, even in xenial.
<xnox> and we are not double/tripple landing dbus
<Laney> then just have it always be started
<Laney> pre-start exec /bin/true
<xnox> we need dbus events in upstart user session, but dbus can be started/stopped by user systemd
<xnox> i don't even need to exec anything.
<Laney> if that works, then 'start on startup'
<pitti> xnox: no, you can uninstall dbus-user-session, and it's not installed by default in xenial
<Laney> I think the old way is still required to be supported
<xnox> just have "start/stop on starting/stopping xsession-init" it does make an assuption that dbus is started by systemd before upstart user session is available.
<xnox> horum.
<xnox> then split into two upstart jobs.
<xnox> one is dbus to emit events / become sync point and another is dbus-daemon that actually spawns the daemon if need be, which is start on starting dbus
<Laney> sleep infini_ty seems less annoying than that
<xnox> true
<xnox> gnome-session is also sleep infinity
<pitti> the overrides  can go away once we lland systemdification of the rdepends
<pitti> i. e. unity and indicators
<pitti> so those sleep infinitys are only a temporary shim
 * pitti didn't expect unity and indicators to take that long, sorry
<xnox> what about the phone though?
<xnox> it has more things still....
<pitti> xnox: right, still lots of WIs for the phone; but this doesn't run on yakkety, so no sleep i_nfinity there
<xnox> Saviq, given that one cannot '--recv-keys' i do think we need/want dirmngr.
<Saviq> +1
<xnox> however, may i use "Recommends:" instead of "Depends:"?
<xnox> that way it will be installed by default on most systems, but bare-minimal offline ones.
 * xnox thinks that through for a moment.
<xnox> wait it already recommands dirmngr
<xnox> so why is it not installed.
<Saviq> xnox, likely the way I configured mk-sbuild
<xnox> Saviq, you use add-apt-repository, which assumes importing things over the network, maybe that should depend on dirmngr?
<xnox> same as e.g. bzr-builddeb, landscape-client, piuparts, python-apt, python-germinate, ubuntu-dev-tools?
<xnox> (as in software-properties-common)
<Saviq> xnox, wfm
<xnox> i'm happy to add depends in software-properties-common.
<Saviq> agreed that gnupg2 itself maybe shouldn't depend, since unless you use --recv-keys it will work fine, and the error message than is pretty clear
<Saviq> *then
<xnox> and done =)
 * pitti adds a more tasteful home page to http://autopkgtest.ubuntu.com/
<Trevinho> Laney: one more approval, then if you want it's good for your publish button
<tseliot> pitti: hey, do you think you can approve those packages for me today?
<roaksoax> howdy! are there any issues with apt or archives ?
<roaksoax> i'm starting to see issues like: http://pastebin.ubuntu.com/23149808/ in an overlayfs
<roaksoax> pitti who should I talk to about issues like http://pastebin.ubuntu.com/23149808/ ? any ideas ?
<Anticom> Hi all, I'm looking for jml. According to his readme, he's the guy to talk to about undistract-me
<hloeung> roaksoax: larrymi saw the same thing earlier today, so it may be a bad MAAS image. Not sure
<roaksoax> hloeung: I don't think it is the maas image itself, but something changed that is causing this issue
<roaksoax> hloeung: in an overlayfs
<hloeung> roaksoax: oh ok
<roaksoax> hloeung: may be related to this: https://bugs.launchpad.net/cloud-init/+bug/1618572
<ubottu> Launchpad bug 1618572 in linux (Ubuntu) "apt-key add fails in overlayfs" [High,Confirmed]
<pitti> tseliot: looking; FWIW, "low regression potential" is quite an understatement -- this involves new pacakges, new driver on existing systems, etc. :)
<pitti> roaksoax: it came up a few times recently with overlayfs (most people experienced that in schroot)
<pitti> roaksoax: I think I've overheard xnox saying it's some kernel change, but I'm not sure
<pitti> roaksoax: ah yes, that bug looks right
<Laney> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1620525
<ubottu> Launchpad bug 1620525 in linux (Ubuntu Yakkety) "sbuild with overlayfs fails in yakkety" [Critical,Triaged]
<Laney> xnox pointed me to that one, but might be a duplicate
<Laney> and the other one has a fix, go apw!
<roaksoax> pitti: yeah it seems it is the same bug
<pitti> tseliot: source-NEWed; will wait for the binaries, new them, and then call for testing on the bug
<mapreri> jbicha: in debian libsecret was properly fixed (and not just "skip the tests"+hacks..).  The fix is span over pygobject and libsecret itself, which could be both synced, imho.  Though we are in FF so some care could be used..
<mapreri> can you please look at it and see whether you could/should sync them?
<tseliot> pitti: thanks!
<pitti> tseliot: done
<jbicha> pitti: ^ see above about possiblying syncing pygobject 3.21.91
<jbicha> maybe I should type a bit slower
<pitti> ah, to keep up  with the beta
<pitti> jbicha: no objection, we have fairly good test coverage for it
<pitti> infinity: http://autopkgtest.ubuntu.com/packages/g/glibc/yakkety/amd64 started failing two weeks ago, is that known? due to gcc 6?
<flexiondotorg> I'm working on the this bug for libmateweather
<flexiondotorg> https://bugs.launchpad.net/ubuntu/xenial/+source/libmateweather/+bug/1616533
<ubottu> Launchpad bug 1616533 in libmateweather (Ubuntu Xenial) ""Forecast not available" error in GNOME Weather app" [High,Triaged]
<flexiondotorg> I've released libmateweather 1.12.2 upstream, which fixes the issue.
<infinity> pitti: That's LP: #1600000
<ubottu> Launchpad bug 1600000 in systemd (Ubuntu) "libnss-resolve treats two trailing dots on a domain name incorrectly" [Undecided,Triaged] https://launchpad.net/bugs/1600000
<flexiondotorg> I want to SRU libmateweather to xenial.
<infinity> pitti: Please turn off libnss-resolve in autopkgtest VMs until that's fixed? :)
<pitti> infinity: oh? we've had resolve a lot earlier than that
<infinity> pitti: Well, if you check the log, that's the failure.  *shrug*
<flexiondotorg> Do I need to create a additional bug for the SRU to xenial?
<pitti> infinity: ack, thanks
 * pitti looks into that
<jbicha> flexiondotorg: maybe use that bug for tracking the libmateweather issue and have bug 1620557 handle libgweather
<ubottu> bug 1620557 in libgweather (Ubuntu Xenial) "weather.noaa.gov was shut down" [High,In progress] https://launchpad.net/bugs/1620557
<jbicha> just because the SRU verification is a bit different for the 2 different packages
<flexiondotorg> jbicha, Just to be clear. You're suggesting libgweather uses https://launchpad.net/bugs/1620557 for SRUs.
<ubottu> Launchpad bug 1620557 in libgweather (Ubuntu Xenial) "weather.noaa.gov was shut down" [High,In progress]
<flexiondotorg> ANd libmateweather uses https://launchpad.net/bugs/1616533
<ubottu> Launchpad bug 1616533 in libmateweather (Ubuntu Xenial) ""Forecast not available" error in GNOME Weather app" [High,Triaged]
<pitti> infinity: https://github.com/systemd/systemd/pull/4111 sent FYI, I'll see to land that soon
<infinity> pitti: Excellent.
<infinity> pitti: When did systemd-resolve start being a thing we built and shipped?
<infinity> pitti: I'd suggest that's broken enough behaviour that it should be SRUed to any release that included the bits, even though we didn't enable it.
<pitti> infinity: somewhere end of May or June or so
<pitti> infinity: sure, it's simple enough to SRU (even though I don't think it's that important -- other than test suites I don't see what it could realistically break)
<pitti> resolving foo.bar.. like foo.bar is hardly completely unexpected
<pitti> but I'll cherry-pick it to the xenial branch once it lands
<infinity> pitti: Other than being completely wrong, but yeah, I suppose it's not something people are likely to do often.
<pitti> infinity: anyway, arguing about whether or not it's important enough would take more time than just cherry-picking the fix once it's in master, so JFDI :)
<infinity> pitti: Yeah, I think you're probably right that it's not actually desperately important, I'm just a big fan of not breaking RFCs.
<infinity> pitti: But, there's also just the "LTSes deserve polish" argument.
<flexiondotorg> jbicha, How to proceed with SRUs for libgweather and libmateweather?
<tseliot> pitti: great, thanks again!
<davmor2> pitti: JFDI is that yoda's impression of Obi-wan?  Jedi Force Disturbance Is hmmmmmmmm
<xnox> infinity, something i hope they don't, even I don't do that =)
 * xnox is crap with standards and networking =)
<jbicha> flexiondotorg: yes, the libgweather xenial sru is already in the unapproved queue
<flexiondotorg> OK, So no problem for me to remove libgweather from #1616533 then?
<jbicha> flexiondotorg: sure, go ahead
<flexiondotorg> jbicha, Thanks.
<pitti> davmor2: it's jedi typoed too indeed, but more commonly "just f** do it" :)
<jbicha> and change the title to match :)
<davmor2> pitti: I knew what it mean I just thought it was nicer ;)
<doko_> kenvandine: libphonenumber ping
<pitti> hmm, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and http://people.canonical.com/~ubuntu-archive/component-mismatches.txt are stuck, /me prods
<Laney> pitti: Already doing
<Laney> see #ubuntu-release
<pitti> Laney: just pushing the b1 fix
<pitti> Laney: argh
<Laney> :|
<pitti> Laney: what did you do?
<Laney> Nothing
<pitti> Laney: just pushed http://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/revision/296
<Laney> I know what the problem is but I didn't push it yet
<Laney> Fine
<pitti> Laney: sorry
<Laney> You should remove the exit 0 in run-proposed-migration
<Laney> doesn't that just push the problem to the next time?
<pitti> Laney: how do you mean?
<pitti> Laney: exit 0 removed
<kenvandine> doko_, there's a test failure for telephony-service in the silo, someone's working on fixing that
<drab> hi, couple questions: I'm trying to preseed all my installations and would love to be able to have a preseed common file imported by others. I'm pulling my main preseed file via url over http. There is a preseed/include string but that doesn't seem to be able to fetch from http, or I'm doing it wrong
<drab> anybody got a working example? or is there a better place to ask this question?
<drab> oh, maybe -installer, trying there
<nacc> drab: iiuc, preseed/include will grab relative to whatever directory your main preseed file was obtained from. Have you tried using a relative path? I honestly don't expect that to work (it seems mostly designed for on-cd customization), but it might?
<drab> nacc: yeah I read that and tried, it didn't, it never tried to pull from the webserver where the main file comes down from
<drab> I'm puzzled why if url works at the very beginning of the process preseed/include can't
<drab> but that does seem to be the case
<drab> i might look if I can use something like an early_command to pull it down on the system, but not sure that runs as early in the process as needed (ie it can influence partman etc)
<nacc> drab: yeah, i don't think early command will help you necessarily, for the reason you said
<semiosis> Odd_Bloke: i'm going to take a look into Poma's report about DNS on the new xenial vagrant box
<Odd_Bloke> semiosis: Excellent, thanks!
<semiosis> Odd_Bloke: if I can reproduce it and dont see a new bug opened tomorrow i'll open it myself.  i think i know were the problem is.  seem to remember something about resolv.conf manipulation in the livecd-rootfs hooks
<Bluefoxicy> I wonder how close my response to Thierry would be to something Linus would say, ignoring the many colorful ways in which Linus would say "You are Dumb(TM)" throughout the whole exchange
<attente> is anyone here using a yubikey for ssh authentication on yakkety? i'm wondering why the S.gpg-agent.ssh socket is no longer in my .gnupg directory
<stgraber> attente: possibly because of the ongoing switch to gpg2? just a guess though, I'm not using the gpg agent for ssh auth
#ubuntu-devel 2016-09-09
<mwhudson> uh
<mwhudson> what do i have to do to be able to edit the wiki?
<tsimonq2> mwhudson: Ubuntu Wiki?
<mwhudson> yeah
<mwhudson> i have to join some team or other iirc?
<tsimonq2> are you an Ubuntu Member?
<mwhudson> yes
 * tsimonq2 thought Canonical and Ubuntu Members had access
<mwhudson> maybe i just need to log in again...
<tsimonq2> oh that's right, you're Canonical too, right? :)
<tsimonq2> probably
<mwhudson> yes
<mwhudson> it's asking me about ubuntumembers when i re-log in so that's a good start
<tsimonq2> that should be it
 * tsimonq2 assumed ~canonical was a private Launchpad team
<tsimonq2> *shrug*
<mwhudson> if the login ever completes, taht is
<tsimonq2> yes, the wiki is really slow :/
<pitti> Good morning
<cpaelzer> good morning
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | 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: dholbach
<seb128> dholbach, enjoy the piloting ;-)
<dholbach> thanks seb128
<dholbach> can the release team take a look at https://bugs.launchpad.net/ubuntu/+source/underscore/+bug/1618904?
<ubottu> Launchpad bug 1618904 in underscore (Ubuntu) "[Ffe] Sync underscore 1.8.3~dfsg-1 (main) from Debian unstable (main)" [Wishlist,New]
<seb128> dholbach, they are their channel you might to ask there?
<seb128> though I guess they are here as well for most part
<seb128> but there is sometime more going on and backlog get lost
<dholbach> ok
<jamespage> doko_, annoyingly I can't get the cryptography py3 failure to fail on an actual armhf machine
<doko_> jamespage: yeah, but porter-arm64 should work?
<jamespage> doko_, testing that now
<Saviq> pitti, morning, I've got good news about unity8 suite, with the upcoming landing we've halved the time it takes to run the tests on our CI, britney should get much better in that regard, too
<Saviq> pitti, got a question, though, in CI we've been getting quite a bit of timeouts after the run's finished (scroll to the bottom of https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/1553/label=amd64,release=yakkety,testname=qmluitests.sh/console) - any idea what could cause that?
<Saviq> how we could debug?
<pitti> Saviq: hmm, schroot --end-session timed out (30 s); does  that happen often?
<Saviq> pitti, I'd say 10-20% of the runs, started a few weeks ago
<pitti> Saviq: maybe slow disks? I don't mind bumping the 30s timeout to 300s, maybe you can locally change it to try if that helps?
<Saviq> pitti, ack, will do
<pitti> Saviq: and nice work on halving the time!
<Saviq> pitti, that would be --timeout-???
<Saviq> man doesn't mention it, maybe I just --timeout-factor?
<pitti> Saviq: not configurable, I'm afraid; change it in virt/autopkgtest-virt-schroot, in hook_downtmp()
<pitti> sorry, hook_cleanup()
<pitti>        if VirtSubproc.execute_timeout(
<pitti>                 None, 30, ['schroot', '--quiet', '--end-session', '--chroot', sessid])[0] == 0:
<Saviq> pitti, ack
<pitti> change the 30 into a 300
<pitti> Saviq: I'll do it in trunk now if you run from git
<Saviq> I don't, relying on pkgs
<jamespage> doko_, bus error comes from siphash24 in a armhf schroot on arm64 host
<pitti> Saviq: https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=1cdc9df
<Saviq> ack, thanks
<Saviq> pitti, hmm good call, it looks like the slave on which that happens is having trouble, things take multiple times more on that one than others
 * Saviq talks to IS
 * pitti wonders on how many secret service watchlists we are by constantly saying "talk to IS" and even /join #is :)
<jamespage> doko_, I think crypto is the symptom - you can reproduce this with "print(hash(datetime.datetime(2015, 1, 1, 1, 1)))"
<LocutusOfBorg> is go* broken on yakkety/powerpc?
<LocutusOfBorg>  sbuild-build-depends-heartbleeder-dummy : Depends: golang (>= 1.2) but it is not going to be installed
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/heartbleeder/0.1.1-3/+build/10727160
<LocutusOfBorg> mwhudson, ^^ :)
<caribou> pitti: slangasek: I have updated LP: #1535898 with a proper SRU template & did my best to document. Please let me know if this is sufficient for the SRU to be accepted
<ubottu> Launchpad bug 1535898 in multipath-tools (Ubuntu Precise) "Trusty & Vivid multipath-tools (multipathd) seg-fault core dump" [High,In progress] https://launchpad.net/bugs/1535898
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | 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:
<semiosis> Odd_Bloke: slangasek: either of your around?  i made progress on bug 1621393 last night and want to discuss a solution.
<ubottu> bug 1621393 in cloud-images "xenial64 image (20160907.1.0) has a broken (empty) /etc/resolv.conf" [Undecided,New] https://launchpad.net/bugs/1621393
<Odd_Bloke> semiosis: o/
<semiosis> the resolv.conf file gets modified by mount_partition, then the original gets replaced in umount_partition, so I need to call umount_disk_image (which calls umount_partition) in the middle of my script, before I build the VMDK file
<semiosis> that's how I originally had my script working, but in review slangasek had me move umount_disk_image into the trap.
<semiosis> if umount_disk_image is in trap then the resolv.conf file is still modified when i build the VMDK, which is the cause of this bug
<semiosis> so... i want to put my script back to the way I had it before... with just rm -rf <temp files> in trap, and umount_disk_image called in the middle of the script, after the apt-get and before building the vmdk
<semiosis> looks to me like 4 other hook scripts do this, without their umount_* calls in trap.  so if it's OK for those, I think it should be OK for mine too :)
<semiosis> you can see slangasek's feedback if you go to the merge request (https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305) and switch the diff viewer to show "r1419 into r1415 on 2016-07-07".  his comment is "If you're going to be mounting a disk image in a script that uses set -e, you also need the unmount to be part of the trap handling."
<brendand> pitti, we keep hitting this issue in our ci - http://paste.ubuntu.com/23154341/. we're running autopkgtest from the git repo. is that something you've seen, or do you think upgrading might help?
<Saviq> seb128, hey, looking at gsettings-qt, according to LP and rmadison it's in main already https://launchpad.net/ubuntu/+source/gsettings-qt with the exception of one binary - do we need a MIR for that, too?
<seb128> Saviq, no, it's fine, sorry it seems the script had a small bugs and some source-in-main-but-binary-not cases showed on our updated list
<Saviq> ack tx
<pitti> brendand: that's an ancient bug already (bug 1384706); no known workaround so far :(
<ubottu> bug 1384706 in autopkgtest (Ubuntu) "tar: Unexpected EOF in archive in copyup()" [Medium,Triaged] https://launchpad.net/bugs/1384706
<Odd_Bloke> semiosis: That seems reasonable to me, but I'd really want slangasek to weigh in. :)
<semiosis> Odd_Bloke: thanks!  i'm open to other solutions as well, but that one seems the most reasonable to me
<brendand> pitti, oh damn
<ddstreet> hi all, i have a q...i need to patch the vlan pkg in ubuntu (version 1.9-3.2ubuntu1) and debian (version 1.9-3.2), is the best thing to do to get debian updated first (to version 1.9-3.3), and then update ubuntu to the full new version (to version 1.9-3.3ubuntu1), or to update ubuntu at the same time, e.g. to version 1.9-3.2ubuntu1.1 for xenial and 1.9-3.2ubuntu2 for yakkety?
<brendand> pitti, interesting that my team reported it originally!
<brendand> pitti, maybe it's our fault :P
<pitti> brendand: a lot of people report it, but it's ridiculously hard to reproduce and investigate
<pitti> I spent hours on that, with sleeps left and right, strace, etc.
<brendand> i wonder can it be mitigated by copying less stuff
<xnox> ddstreet, before you can upload SRU bug must be fixed in yakkety first.
<xnox> ddstreet, a fix in yakkety will most likely land as 1.9-3.2ubuntu2
<xnox> ddstreet, your xenial version number will be 1.9-3.2ubuntu1.1 (with the functional equivalent diff of what ....ubuntu3 fixes)
<ddstreet> xnox cool thnx!
<xnox> ddstreet, you shall not fix bugs in xenial-sru ahead of devel series, because versions don't work, and things regress on upgrade.
<ddstreet> right definitely not, devel fix first
<xnox> ddstreet, note you cannot upload 1.9-3.3 to ubuntu =) that's a debian NMU version number, such a fix needs to be sponsored into debian.
<xnox> ddstreet, what's the bug, and what's the fix? I can sponsor things for you into debian, yakkety, xenial as needed.
<ddstreet> bug 1224007
<ubottu> bug 1224007 in ifupdown (Ubuntu) "mtu not always set properly on bond/vlan interface" [High,Confirmed] https://launchpad.net/bugs/1224007
<ddstreet> i put a patch in comments there but i've changed it, i'll attach a patch and debdiff for yakkety
<ddstreet> xnox should i open a debian bug for ^?  I assume so yeah?
<ddstreet> there was a debian bug open, 722496, but it was closed as config error, which it isn't
<xnox> ddstreet, debian bug is against ifupdown package; ubuntu bug is aginst ifupdown & vlan package; if you have a patch against vlan package, opening a new bug in debian against vlan package makes sense
<xnox> explain the problem and probably reference old ifupdown bug # too
<xnox> or e.g. reopen 722496, and reassign 722496 to vlan package, and explain things
<ddstreet> xnox ah ok, i'll repoen the old one thnx
<LocutusOfBorg> pitti, hi, seems that a test disappeared
<LocutusOfBorg> astrometry.net/0.67+dfsg-1build2 against libpng1.6
<LocutusOfBorg> test in progress since some hours (i386)
<LocutusOfBorg> but not in the queue, nor running
<pitti> LocutusOfBorg: bumped
<LocutusOfBorg> pitti, was it a bug?
<slangasek> caribou: thanks, setting #1535898 back to v-done
<nacc> smoser: have a moment?
<smoser> sure
<nacc> smoser: thinking about this apt bug -- i got further in the import by adding a parent override for 0.7.19ubuntu1 that just manually tells the importer what the parent relationships are. However, 0.7.20.2ubuntu1 also hits it. I'm guessing any published version with 0.7.14ubuntu1 in the changelog will hit it. But without manually going through each time and figuring out what versions are affected, I am
<nacc> struggling to think of a generic solution to a malformed changelog
<smoser> i'm guessing you can't upload a malformed changelog any more
<smoser> right ?
<smoser> i'm surprised that it ever got into archive
<nacc> yeah, i'm guessing it isn't possible anymore too
<nacc> there are more checks now than historically, it seems like :)
<smoser> maybe its acceptable then to take the last good entry ?
<smoser> but you probalby dont have an easy way to know what the last one was
<smoser> as you're relying on parsechangelog to figure that out for you
<smoser> right?
<nacc> oh it's not about that, really
<nacc> well, i mean, it's not about 'last' in this case
<nacc> but i basically grab "all" entries at one point from the changelog
<nacc> in order to figure out common ancestor
<nacc> smoser: it might take another workaround file like the parent override to just say if you see this version in the changelog for a given package, we can't parse it, emit an error and ask for an override
<tjaalton> jbicha: hi, is there no bug for the other change in ubuntu-gnome-wallpapers?
<jbicha> tjaalton: no, I guess no one noticed or thought it important enough to file the bug; I found it while verifying there weren't any other typos breaking the slideshows
<tjaalton> alright
<smoser> nacc, i was just suggesting that you could just ignore invalid entries.
<smoser> would that help things ? anything that isnt valid is just dropped
<smoser> you could / maybe should require a flag to behave like that
<nacc> smoser: well, i mean, there's not a way for me to detect that
<nacc> smoser: i mean, i could assume dpkg-parsechangelog failing is that, but it's not always true
<smoser> right. other than basically parsing more loosely.
<jbicha> tjaalton: in case you didn't see, there's a trusty upload for u-g-wallpapers too
<tjaalton> looking
<nacc> smoser: yep, i wonder if i need to write another parser to do that, though -- more work :)
<jbicha> thank you
<Pharaoh_Atem> is there an API for retrieving the URLs of the source packages?
<Pharaoh_Atem> like the URLs on http://packages.ubuntu.com/source/trusty/libmodule-cpants-analyse-perl ?
<smoser> Pharaoh_Atem, pull-lp-source will let you pull them.
<smoser> likely you can do what you want, but i'm not sure excactly.
<nacc> Pharaoh_Atem: you mean the VCS urls?
<ogra_> Pharaoh_Atem, if you like it more raw ... https://help.launchpad.net/API/ and https://launchpad.net/+apidoc/1.0.html ...
<Pharaoh_Atem> nacc: no, I want the tarball and dsc file urls
<Pharaoh_Atem> I want to be able to pull them from say universe and be able to download them
<nacc> Pharaoh_Atem: oh, `pull-lp-source` is what you want
<Pharaoh_Atem> or at least grab the URLs
<nacc> Pharaoh_Atem: and `pull-debian-source` if you need it
<Pharaoh_Atem> pull-lp-source pulls from archive.ubuntu.com?
<ogra_> no, from launchpad
<Pharaoh_Atem> I specifically want the ones from archive.ubuntu.com
<ogra_> thats the same :)
<nacc> Pharaoh_Atem: i think you're overanalyzing :)
<nacc> Pharaoh_Atem: they are the same
<Pharaoh_Atem> okay...
<nacc> Pharaoh_Atem: maybe just try it and see? :)
<Pharaoh_Atem> where do I get pull-lp-source?
<nacc> Pharaoh_Atem: in your case, `pull-lp-source -d libmodule-cpants-analyse-perl trusty`
<nacc> Pharaoh_Atem: ubuntu-dev-tools
<ogra_> https://code.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk
<Pharaoh_Atem> nacc: I'm writing a script to pull selected components from universe into my private build environment
<Pharaoh_Atem> so I just need the URLs to pass to the OBS system
<nacc> Pharaoh_Atem:  i mean, do you really need the URL? just use `pull-lp-source -d`?
<Pharaoh_Atem> yes
<nacc> Pharaoh_Atem: i mean, it sounds like your script would end up just doing what `pull-lp-source -d` does with the same information
<Pharaoh_Atem> I'm sending the URLs into the obs source service system
<nacc> Pharaoh_Atem: i guess you could just make a copy of pull-lp-source and have it emit the URLs rather than d/l them?
<semiosis> slangasek: if you're around, could you take a look at my chat about bug 1621393 from earlier today?
<ubottu> bug 1621393 in livecd-rootfs (Ubuntu) "xenial64 image (20160907.1.0) has a broken (empty) /etc/resolv.conf" [Undecided,Confirmed] https://launchpad.net/bugs/1621393
<semiosis> see chat log here: https://irclogs.ubuntu.com/2016/09/09/%23ubuntu-devel.html#t11:34
<slangasek> semiosis, Odd_Bloke: hi, so, my guidance wasn't "you can't call umount earlier", it was "you must include a call to umount in your trap"
<slangasek> because if someone hits ^C at the terminal you don't want stray mount points left around
<slangasek> but if you need to call cleanup functions earlier than this as part of an image build, then you should certainly do so
<semiosis> slangasek: unfortunately the umount functions don't like being called twice.  in this case, the function moves a file, so if you call it a second time, the mv fails because the src no longer exists :(
<semiosis> so my options are... only call umount_disk_image once, in the middle of my script (not in trap) or manually create the resolv.conf symlink
<semiosis> slangasek: whats your take on the other four hook scripts that do call umount_* functions in the script, and not in trap?  as the kid in me wants to say... if they can do it why can't I? ;)
<semiosis> slangasek: they call `trap - EXIT` -- and I can't even figure out what the hyphen there does.  maybe thats my answer, somehow?
<slangasek> semiosis: the other option is to have the trap handling keep track of whether umount has previously been called or if it needs to be called again
<semiosis> ooh that's interesting.  maybe set a veriable after the umount_disk_image call, then test for that variable in the trap.  does that sound reasonable?
<slangasek> 'trap - EXIT' means 'clear the current EXIT trap'
<slangasek> yes, it can be a variable check, or a check for a file or whatnot
<semiosis> how about changing the trap... mount, set trap with umount, do stuff, call umount, remove umount from trap.  how's that sound to you?
<semiosis> slangasek: thanks for the guidance.  i'm not too experienced with all this sophisticated BASH.  appreciate the help & knowledge.  i'll try out some solutions around what we talked about this weekend and hopefully open a merge request.
<slangasek> semiosis: the challenge is that a trap can only have a single value for any given signal; so if you have various cleanup tasks, some of which may be required and some not depending on where in the sequence you are when interrupted, you have to leave the trap set to a common function that includes all the smarts for cleaning up
<semiosis> slangasek: ok that makes sense.
<slangasek> semiosis: strawman: http://paste.ubuntu.com/23156408/
<semiosis> that's pretty simple
<slangasek> semiosis: if you can test that this does what you want, I'm happy to push it
<semiosis> i'll try it now
<semiosis> slangasek: worked great.  thank you!
<semiosis> slangasek: want me to prepare this in a branch & a merge request?
<semiosis> i'm going afk but will check in later.  thanks again
<slangasek> semiosis: I'll just push it now to yakkety+xenial
#ubuntu-devel 2016-09-10
<seeit_> anyone in here able to help me with apt-build?
<sarnold> irc works better with specific questions :)
<seeit_> I am looking to build some packages with apt-build but if I do apt-build install <pkgname> I get a message that there must be some 'source' URIs in your sources.list, I've tried adding them but that doesn't work
<sarnold> did you run apt-get update afterwards?
<seeit_> I ran apt-build update
<seeit_> just ran apt-get and i get the same message
<sarnold> what do your apt sources.list files look like? (paste.ubuntu.com if they're more than three or four lines, please)
<seeit_> ok, the deb-src lines were still commented out, thought I had fixed it but guess not, its working now, ty
<seeit_> ls
<sarnold> woot :)
<seeit_> on a 4 core system with hyperthreading and 32gb of ram how long should I expect it to take to build world
<sarnold> yikes, uh, what's in the "world" category?
<seeit_> all currently installed packages
<seeit_> ls
<sarnold> probably a few weeks
<seeit_> wow, any idea what causes the error ' the value 'apt-build' is invalid for APT::Default-Release as such a release is not available in the sources?
<sarnold> you can find out how long launchpad takes to build specific packages; look up the source package name e.g. https://launchpad.net/ubuntu/+source/libreoffice click a triangle to expose the "builds", amd64 there says libreoffice took five hours, thirty one minutes...
<seeit_> wow ok
<seeit_> not interested in rebuilding libreoffice right nwo
<seeit_> mostly some computational packages
<sarnold> seeit_: wild-guess, maybe the '--target-release' option might help with the default-release setting  http://manpages.ubuntu.com/manpages/xenial/man1/apt-build.1.html
<seeit_> sarnold it was exactly that
<sarnold> man I love it it when things work as I expect :D
<seeit_> ok, now for a weird one, I was just doing this all in a VM to test out apt-build, now I copied sources.list over to the host machine and I get the previous error to put some URIs into sources.list
<seeit_> wait nm
<seeit_> timing world on my system :P
<sarnold> how many packages do you have installed?
<seeit_> 2206
<sarnold> the worst ones I can think off the top of my head would be firefox, chromium-browser, libreoffice, mysql...
<sarnold> owwwwww
<seeit_> i've got libreoffice and firefox in there
<sarnold> hope you've got loads of drive space and even more free time :)
<seeit_> I'm not using the cpu much most of the stuff I need is through citrix and about 500GB of space
<seeit_> but doing everything through -pipe
<seeit_> I'll be surprised if the system reboots after this
<seeit_> then the big question is if this works how do I make a install iso out of all these packages
<seeit_> I suspect libc won't work with -fstack-protector-strong, at least it hasn't in the past
<jbicha> webkit2gtk is heavy too
<seeit_> yeah I've done linux from scratch before in a VM and that one is pretty hefty
<sarnold> three and ahalf hours there, yeah...
<seeit_> is there a way to supress the output from the build? I'm sure that would speed it up some, at least it has on other compilations I've done
<seeit_> > /dev/null maybe?
<sarnold> it'd probably beb etter to save to a file so that you can figure out why things break, when they inevitably will..
<sarnold> grab stderr too
<seeit_> already failed on apparmor, "Sorry, no package to install"
<doko_> jamespage: https://launchpad.net/ubuntu/+source/python-cryptography/1.5-1/+build/10678695
<tjaalton> huh, the update manager reboot-popup somehow takes 30% cpu on both xorg and compiz (xenial)
<jamespage> doko_, +1 thanks for sorting that out
<doko_> jbicha: https://bugs.launchpad.net/ubuntu/+source/totem/+bug/1547395 totem doesn't migrate
<ubottu> Launchpad bug 1547395 in totem (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [High,New]
<ejat> anyone facing broken icon panel in 16.10 ?
<ejat> http://picpaste.com/broken-icon-right-top-panel-yvqAsbg3.png
<jbicha> doko_: could you demote libquvi to universe?
#ubuntu-devel 2016-09-11
<doko_> jbicha: no,  libtotem-plparser18 still depends on libquvi-0.9-0.9.3, and it doesn't show up in component mismatches
<doko_> ahh, in component mismatches proposed
<jbicha> doko_: can you demote libquvi-scripts too?
<doko_> jbicha: your gazebo upload ftbfs and now blocks the protobuf transition :-/
<jbicha> doko_: well it was broken before I touched it, but the fix is easy https://bugs.debian.org/837121
<ubottu> Debian bug 837121 in gazebo "gazebo: please restrict libkido-dev (build-)dependency to architectures where it is available." [Serious,Open]
<jbicha> we're waiting for someone to do something with libphonenumber anyway, right?
<doko_> it's in a silo
<jbicha> ok, I'll fix gazebo in Ubuntu then
<jbicha> doko_: could you look into removing fcl/armhf then? (since gazebo depends on kido which depends on fcl)
<doko_> jbicha: I asked LocutusOfBorg to have a look
<doko_> meh, ignition-transport autopkg test failure
<jbicha> autopkgtests are annoying where they only ever passed once, ostree has one like that too
<jbicha> ignition-transport/1.3.0-2build1 is an "ignored failure" but we now have 1.3.0-4
#ubuntu-devel 2017-09-04
<mwhudson> uhh why does docker.io ftbfs in artful now
<mwhudson> it worked last week
<mwhudson> --- FAIL: TestFastTimeMarshalJSON (0.00s)
<mwhudson> 	time_marshalling_test.go:36: open /usr/lib/go-1.8/lib/time/zoneinfo.zip: no such file or directory
<mwhudson> something has stopped depending on tzdata?
<blahdeblah> Just a reminder that we're having a mailing list outage shortly.
<mwhudson> orrrr the buildd chroots have tzdata but my artful one did not
<blahdeblah> See #canonical-sysadmin for updates
<jbicha> mwhudson: maybe see https://bugs.debian.org/839515 for instance ?
<ubottu> Debian bug 839515 in src:dateutils "dateutils must depend and build-depend on tzdata" [Serious,Fixed]
<mwhudson> jbicha: yeah, i remember things like that
<towolf> xnox: martin told me to ping you about this bug: http://pad.lv/1714933
<ubottu> Launchpad bug 1714933 in systemd (Ubuntu) "Xenial: Please merge upstream fix for networkd to "accept colons in network interface names"" [Undecided,New]
<xnox> towolf, correct, targetting to include the fix in xenial and zesty; artful appears to be unaffected (fix released, as it uses v234)
 * rbalint looking for sponsor for LP: #1714019
<ubottu> Launchpad bug 1714019 in unattended-upgrades (Ubuntu) "Please merge unattended-upgrades 0.96 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/1714019
<cjwatson> stgraber: Can you advise on https://launchpadlibrarian.net/335598163/buildlog_ubuntu_xenial_powerpc_ubuntu-server_BUILDING.txt.gz ?  Does lxd work on powerpc?
<stgraber> cjwatson: it's supposed to. Rebooting our test system now to see if I can reproduce your issue
<cjwatson> stgraber: this is xenial's lxd FWIW
<stgraber> cjwatson: yeah, I figured. Our backports don't include powerpc because gccgo doesn't like some of our dependencies...
<cjwatson> we can flip back to chroot on an arch-by-arch basis if need be, but figured you'd want to look
<cjwatson> and I'd rather not do that if possible
<stgraber> yeah, I'm pretty sure dumping lxc.seccomp= in your raw.lxc would work around this issue, but I'm also interested in why it's happening in the first place
<stgraber> root@1ss-powerpc:~# uname -a
<stgraber> Linux 1ss-powerpc 4.4.0-93-powerpc64-smp #116-Ubuntu SMP Fri Aug 11 17:05:22 UTC 2017 ppc64 ppc64 ppc64 GNU/Linux
<stgraber> root@1ss-powerpc:~# lxc launch images:ubuntu/xenial/powerpc test
<stgraber> Creating test
<stgraber> Starting test
<stgraber> so that's working fine on our test box...
<stgraber> cjwatson: can you get me "lxc config show --expanded NAME" for an affected container?
<LocutusOfBorg> rbalint, I can sponsor, if you give me a debdiff against latest debian
<cjwatson> stgraber: That would be challenging.  infinity might be able to
<LocutusOfBorg> applying on top of ubuntu: File test/unattended_upgrade.py is not a regular file -- refusing to patch
<LocutusOfBorg> 62 out of 62 hunks ignored -- saving rejects to file test/unattended_upgrade.py.rej
<stgraber> cjwatson: for a quick way out, adding lxc.seccomp= to your raw.lxc should avoid this, effectively turning off seccomp filtering too (given how privileged those containers are, it's unlikely to matter anyway)
<cjwatson> It's been broken since Friday, so I'm not going to panic
<cjwatson> infinity: So I think if you run the unpack-chroot and mount-chroot lines from https://launchpadlibrarian.net/335598163/buildlog_ubuntu_xenial_powerpc_ubuntu-server_BUILDING.txt.gz with PYTHONPATH=/usr/lib/launchpad-buildd prefixed to them, then 'lxd config show --expanded NAME', then the umount-chroot and remove-build lines likewise, that should get the information stgraber needs here
<cjwatson> infinity: rather, 'lxc config show --expanded lp-xenial-amd64'
<cjwatson> infinity: double rather, 'lxc config show --expanded lp-xenial-powerpc'
<cjwatson> (sigh)
<stgraber> was about to point that out :)
<LocutusOfBorg> meh rbalint done
<LocutusOfBorg> complain to me if I did any mistake :)
<rbalint> LocutusOfBorg: thanks!
<infinity> stgraber, cjwatson: http://paste.ubuntu.com/25466829/
<stgraber> cjwatson: doh, completely missed that our powerpc system has raw.lx: lxc.seccomp= in its config...
<stgraber> cjwatson: with a note that this is needed until the 4.8 kernel or so
<stgraber> cjwatson: that is, a HWE kernel would be fine for seccomp with lxc/lxd, but the release 4.4 not so much
<stgraber> cjwatson: so I'd say, just add lxc.seccomp= to your raw.lxc and call it done
<infinity> stgraber: Ahh, yeah, powerpc will never have 4.8, so...
<infinity> stgraber: Is that a thing that could be detected at runtime?  Seems a bit sketchy to require extra config options to work with the GA kernels.
<infinity> (unless this is just powerpc, then just meh, disable that option on PPC in the next build?)
<stgraber> infinity: it's kinda tricky to detect in a reliable way and we sure don't want to turn off seccomp for someone who'd be running a patched kernel.
<stgraber> infinity: I think our initial plan was to find the needed bits to fix seccomp support on powerpc and ask the kernel team to include in a SRU cycle. Obviously given how little interest we've been getting for powerpc, this hasn't quite happened yet :)
<ahasenack> hi, could someone accept the xenial and zesty nominations in bug https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1595889 please?
<ubottu> Launchpad bug 1595889 in bind9 (Ubuntu) "Bind9 service does not source OPTIONS from /etc/default/bind9" [Undecided,Confirmed]
<ahasenack> The yakkety isn't needed since it's eol
<ahasenack> yakkety one*
<tsimonq2> Heh, how do I do that? :P
<ahasenack> tsimonq2: only people with certain privileges can do that (I cannot)
<tsimonq2> oh
 * tsimonq2 thought it was an ~ubuntu-dev thing
<tsimonq2> nvm, carry on :P
<ahasenack> thanks for trying :)
<tsimonq2> :)
<ginggs> ahasenack: .
<tsimonq2> ginggs: What team to you have to be on to do that?
<ahasenack> ginggs: did you do it?
<ginggs> ahasenack: yup
<ahasenack> thx
<ginggs> tsimonq2: i'm not sure, it may depend on whether the package is in main or universe
<cjwatson> stgraber: Thanks, will do
<cjwatson> infinity: Yeah, pretty sure this is just powerpc; I've seen all this working on (all, I think) other arches
#ubuntu-devel 2017-09-05
<mwhudson> what the heck is going on here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/ppc64el/d/docker.io/20170905_034210_a49fd@/log.gz
<mwhudson> (this only happens on ppc64el, maybe there's some ppc64el scalingstack problem?)
<doko> jtaylor: online?
<ginggs> xnox: hi, may i sync atlas? it builds fine in artful-proposed
<ginggs> your diff was included in debian
<xnox> ginggs, sure.
<xnox> looks good
<ginggs> xnox: thanks!
<ginggs> xnox: hmm, i spoke to soon, the armhf build failed - something to do with NEON i guess
<doko> mvo, whoever: who am I supposed to ask about snapcraft autopkg failures?
<ogra_> doko, the snapcraft guys are on rocket.ubuntu.com in the #snapcraft channel
<doko> ogra_: separate irc server? ohh fun!
<ogra_> doko, or open a topic on forum.snapcraft.io
<ogra_> no IRc
<ogra_> its a web-chat
<doko> pff
<doko> and I assume you have to register for that ...
<ogra_> indeed, for both
<ogra_> (i'd actually recommend the forum over rocket ... there is a snapcraft category)
<Unit193> doko: Looks like the former supports login.u.c
<Laney> mwhudson: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1715128
<ubottu> Launchpad bug 1715128 in cloud-init (Ubuntu) "Crashes in convert_ec2_metadata_network_config on ScalingStack bos01 (ppc64el)" [Undecided,New]
<doko> Unit193: ? I don't see that sso is used
<cjwatson> stgraber: Is there some reason why a loop-mount might fail inside the launchpad-buildd lxd setup?  I don't see anything about that in the default seccomp profile.  https://launchpadlibrarian.net/335879037/buildlog_ubuntu_artful_armhf_raspi2_cpc_BUILDING.txt.gz
<cjwatson> Most things seem OK otherwise ...
<tjaalton> doko: so I think doxygen was the only thing in main besides mesa that used llvm-4.0. next upload will migrate it to 5.0
<LocutusOfBorg> doko, what is this? collect2: fatal error: ld terminated with signal 9 [Killed]
<LocutusOfBorg> somebody in the infra is killing ld?
<coreycb> jamespage: python-zunclient has dependencies on python-docker and python-websocket which are both in universe
<coreycb> jamespage: so I moved zunclient to Suggests in heat a few weeks back for artful. I think we can move zunclient back to universe if you agree.
<jamespage> coreycb: +1
<coreycb> hello release team, can you please move python-zunclient to universe as it is no longer needed in main?
<ricotz> LocutusOfBorg, *cough* poppler
<xnox> cjwatson, infinity: i wonder if /usr/share/locale/all_languages from kdelibs5-data should really be shipped in like glibc or something. It's a mapping of all language names, translated. Very useful for language selection dialogs like in ubiquity.
<cjwatson> isn't that what iso-codes is for?
<cjwatson> (not that I care very deeply)
<abeato> cyphermox, is there any way to override the netplan configuration from subiquity in UC16? I want to override console-conf one *and* that one
<cyphermox> abeato: I'm not sure what you mean, it should be easy to replace /etc/netplan/*.yaml to do what you want
<abeato> cyphermox, yeah, but I want to seed that config on first boot, and subiquity is overwriting it
<LocutusOfBorg> ricotz, do you want me to upload it?
<ricotz> LocutusOfBorg, you asked me to merge it, so I expected you have some intention to take care of the further process
 * ricotz doesn't have upload rights
<ricotz> ah 0.59...
<LocutusOfBorg> A 0.58-2ubuntu1 is trivial, 0.59 needs some Ffe checks
<ricotz> LocutusOfBorg, you mean 0.57.0-2ubuntu1
<LocutusOfBorg> yep indeed
<LocutusOfBorg> new soname needs talk in #-release
<ricotz> LocutusOfBorg, http://people.ubuntu.com/~ricotz/ubuntu/
<xnox> cjwatson, i'll check iso-codes.
<xnox> thanks
<xnox> also, tty1 should be unicode capable.... i wanted to write: Use â or â + â to select ðºï¸
<xnox> but i can't =(
<LocutusOfBorg> ricotz, .
<ricotz> LocutusOfBorg, .?
<LocutusOfBorg> done
<ricotz> LocutusOfBorg, thanks
<LocutusOfBorg> thanks to you!
<LocutusOfBorg> "ricotz doesn't have upload rights" sounds like a bug to me, a ppu might be beneficial for you
<LocutusOfBorg> are you motu?
<tseliot> Unit193: would you be available to test nvidia-304  in Ubuntu 17.10 for me?
<ricotz> LocutusOfBorg, no, never went for the hassle to apply for it
<LocutusOfBorg> ok
<Unit193> tseliot: If it's regarding that issue, sure would later today.
<tseliot> Unit193: yes, it's about LP: #/1711758
<tseliot> LP: #1711758
<ubottu> Launchpad bug 1711758 in nvidia-graphics-drivers-304 (Ubuntu) "artful: nvidia-304 unknown symbol init_mm" [High,In progress] https://launchpad.net/bugs/1711758
<slashd> Good day rbasak I see you are chairing the meeting this week (https://wiki.ubuntu.com/ServerTeam/Meeting), I won't be available today due to some personal reason, and following 2 Tuesdays as well (Conference + vacation). I'll be back for the meeting on Tues 9/26. For today, I have nothing to highlight or discuss.
<cyphermox> abeato: subiquity doesn't run on first boot of UC16. console-conf does -- if you just remove console-conf it won't
<cyphermox> abeato: there is no other option, I think the default "dhcp on whatever we can" is hard-coded in console-conf
<abeato> cyphermox, I see, thanks
<cyphermox> if you need to do otherwise; you should open a bug against the subiquity package in LP, and mention that. We should be able to move the config to some file that could then be overridden
<tseliot> Unit193: I have just uploaded the driver here. Give it some time to build. Thanks for your help https://launchpad.net/~albertomilone/+archive/ubuntu/deleteme-nvidia
<stgraber> cjwatson: do you have the /dev/loop* nodes (loop-control and loop* devices)?
<cjwatson> good question - let me finish setting this up locally
<stgraber> cjwatson: alternatively it may be caused by missing kernel modules, so you may want to make sure that any filesystem kernel module is loaded (you can list them in linux.kernel_modules)
<doko> sil2100: about #1696686: the binutils change is limited to arm32 only. so you have to look for other things causing these "regressions".
<doko> sil2100: and the linux/armhf failure seems to be unrelated, packaging error?
<doko> apw: ^^^
<sil2100> doko: leave a comment on the bug if possible
<apw> sil2100: got a link to the Linux/armhf failure? as it passes on my sheet
<doko> apw: http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#binutils
<apw> doko, oh i know what that is ...
<apw> sil2100, that can be ignored
<jtaylor> doko: yes, you should have waited a couple hours, I was just waiting for the numpy upload
<doko> jtaylor: go ahead and override ...
<jtaylor> doko: did you do it outside of git?
<doko> jtaylor: yes
<powersj> "Sep  3 03:54:38 debconf: --> INPUT critical keyboard-configuration/layout"
<powersj> It appears this key was increased in priority from high to critical recently.
<powersj> that's from the artful daily ISO as of sep 3.
<powersj> slangasek: ^ bug? expected?
<slangasek> powersj: not something I expect; I believe cyphermox was doing a console-setup merge, so he might know things
<cyphermox> ah, it's possible this slipped through the cracks
<cyphermox> OTOH, as I recall that key specifically has a different behavior depending on how the installer is started
<cyphermox> powersj: by artful daily iso you mean ubuntu-server/daily/current?
<cyphermox> (as opposed to using mini.iso)
<powersj> cyphermox: ubuntu-server/daily/pending
<cyphermox> ack
<powersj> this broke the daily ISO tests
<cyphermox> I'll have a look
<powersj> thanks!
<cyphermox> powersj: ok yeah, that's a mistake on my part
<powersj> cyphermox: ok, fix via new upload?
<Unit193> tseliot: I confirm that version fixes that specific bug.   Specifically, 304.135-0ubuntu5~ppa1
<Unit193> During upgrade, I did get: dpkg: error: version '-' has bad syntax: revision number is empty  however.
<tseliot> Unit193: yes, that's ok, it won't affect anything. Thanks for testing! I am going to upload the driver in Ubuntu tomorrow.
<Unit193> Thanks.
<cyphermox> powersj: yeah, but I wonder why it's an issue for the automated testing, i thought that would have been preseeded?
<powersj> cyphermox: I don't think we do since we set priority = critical
<powersj> https://paste.ubuntu.com/25473763/ is debconf output
<cyphermox> powersj: setting priority=critical is "preseeding". You're preseeding the minimum priority at which to prompt for things, and using defaults for everything else
<cyphermox> that said, https://launchpad.net/ubuntu/+source/console-setup/1.166ubuntu3
<powersj> Yes, I took your comment as you expected us to preseed the keyboard config
<cyphermox> not quite
<cyphermox> but I would prefer if you did use some preseed file to test more than just the defaults, but that's not a big deal
<powersj> cyphermox: go you explain that more
<powersj> can you explain that more*
<cyphermox> powersj: you can specify exactly how you want the install to happen, it might be useful to test in another language, or some specific partitioning scheme, etc.
<cyphermox> but that's for your team to decide :)
<powersj> cyphermox: we do a number of tests with different configs
<powersj> I'm surprised you didn't know this
<powersj> we do miss language, but we do different storage configs (e.g. lvm, raid1)
<powersj> as well as other tasksel related items
<powersj> so if there are other areas that are interesting I'm more than happy to hear them.
<cyphermox> I know, but I'm surprised to see this one not pass anything other than hostname and priority
<powersj> it does much more than that
<powersj> here is the preseed that is used for the smoke test of each daily ISO: https://paste.ubuntu.com/25474304/
<powersj> if it passes that it gets promoted to current
<powersj> then the other dozen or so tests get launched
<powersj> Yes a lot is commented out, but it is preseeding more than 2 things
<powersj> so if there are other areas that would be good to test, it would be nice to hear, especially given how much of the installer comes from foundations
<Unit193> rbasak: Regarding Firefox.  It's actually worse than that, as firefox is up to date in zesty but isn't even up to date in -proposed.
<Unit193> !info firefox artful-proposed
<ubottu> firefox (source: firefox): Safe and easy web browser from Mozilla. In component main, is optional. Version 54.0+build3-0ubuntu1 (artful-proposed), package size 48328 kB, installed size 113778 kB
<Unit193> !info firefox zesty
<ubottu> firefox (source: firefox): Safe and easy web browser from Mozilla. In component main, is optional. Version 55.0.2+build1-0ubuntu0.17.04.1 (zesty), package size 42299 kB, installed size 161720 kB
<Unit193> rbasak: Personally as long as it's in -proposed I don't really mind, as I've been using http://paste.openstack.org/show/620441 for the past couple cycles.
<tsimonq2> jackpot51: ping
<mwhudson> Laney: wtf!
<mwhudson> Laney: at least i'm glad i didn't bother trying to work out what was going on any more than that, i'd never have guessed it was cloud-init
<jackpot51> Hello tsimonq2
<tsimonq2> jackpot51: Hey there, so re: bug 1699216, sorry for not getting back to you, I wasn't subscribed to the bug...
<ubottu> bug 1699216 in gnome-initial-setup (Ubuntu) "Encrypted home support" [Wishlist,Confirmed] https://launchpad.net/bugs/1699216
<tsimonq2> jackpot51: Just wanted to make sure you saw my response on it :)
<jackpot51> Yep, I saw it. I left a comment for ubuntu-release, to explain the reasoning for merging patches to accountsservice, but not to gnome-control-center and gnome-initial-setup
<tsimonq2> Ok
<tsimonq2> jackpot51: In any case, it would be great if you could make those diffs into debdiffs (with a changelog entry and putting your patch in debian/patches) and add a DEP-3 header to it
<tsimonq2> s/it/them/ (last instance)
<jackpot51> I will try. It should be really close to that
<tsimonq2> Ok.
<tsimonq2> (it is)
#ubuntu-devel 2017-09-06
<LocutusOfBorg> hello doko I'm not sure if openjdk8 in debian/ubuntu armhf is broken or not
<LocutusOfBorg> Error: missing `server' JVM at `/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm/server/libjvm.so'.
<LocutusOfBorg> Please install or use the JRE or JDK that contains these missing components.
<LocutusOfBorg> it is not even installable :(
<LocutusOfBorg> https://buildd.debian.org/status/logs.php?pkg=gdal&arch=armhf
<Laney> what's a $ prefixed rule in a makefile? "$./KeyboardNames.pl:"
<Laney> and, well, how do I invoke it? :-)
<doko> LocutusOfBorg: I'll have a look
<doko> tjaalton: https://launchpad.net/ubuntu/+source/apitrace/7.1+git20170623.d38a69d6+repack-1build1   triggered by new glibc
<doko> infinity: ^^^
<LocutusOfBorg> thanks doko, ubuntu seems to be not affected, if this helps
<doko> tjaalton: mesa b-d on llvm-5? are you aware that it ftbfs?
<LocutusOfBorg> I'm seriously thinking about using gcc-6 for llvm and arm64/ppc64el
<juliank> xnox: What happened to apt 1.4.6~16.10.1 in zesty-proposed? Your last comment was: "And will redo zesty upgrade test again to make sure units are started for the upgrade timer."
<juliank> 1.4.7 entered stretch a few weeks ago, I'd like to get this over into zesty eventually :)
<doko> jbicha, didrocks: there are glib2.0 autopkg test failures on ppc64el and s390x triggerd by glibc and elfutils
<doko> infinity, xnox: ^^^
<tjaalton> doko: yep, but rc2 is available
<doko> tjaalton: sure, if you can fix bugs in this version ...
<Unit193> Specifically 1691908 would be awesome to fix.
<tjaalton> doko: apitrace has a bug for the ftbfs on debian too, i'll have a look
<tjaalton> though it was due to gcc7 I think
<fossfreedom_> hi cyphermox , Laney - I saw that the latest upload of ubiquity in artful is having a little bit of trouble building.  Just wondering - any chance of my PR sneaking in with the next upload please? https://code.launchpad.net/~ubuntubudgie-dev/ubiquity/fix_lp_1713662/+merge/329911
<Laney> Probably. And I know.
<Laney> I got 5 emails about it....
<Laney> No, 6
<dgadomski> hey doko, re bug #1638695, have you been doing any benchmarks of the artful builds after your changes?
<ubottu> bug 1638695 in python2.7 (Ubuntu Xenial) "Python 2.7.12 performance regression" [High,Confirmed] https://launchpad.net/bugs/1638695
<doko> dgadomski: no
<dgadomski> doko: ok, I'll check it out and share the results in the bug
<doko> dgadomski: sure, but remember that pie is turned on by default in artful
<dgadomski> doko: ack, thanks
<xnox> infinity, dpkg -S xlocale.h -> libc6-dev:s390x: /usr/include/xlocale.h is not true with new glibc in proposed. Is that intentional, or accidental?
<xnox> infinity, autoconf, in prelude, fails to find perl.h because conftest includes xlocale.h
<xnox> infinity, not sure if i'm supposed to fix autoconf/perl/prelude or if libc6-dev should continue to ship xlocale.h
<xnox> infinity, doko - found changelog saying "Don't include xlocale.h. If necessary, include locale.h instead." hence intentional.
<xnox> i think we need perl rebuild, to drop #define I_XLOCALE from its config.h
<xnox> testing.
<LocutusOfBorg> xnox, sync perl instead
<xnox> LocutusOfBorg, right that could do it too. But will wait for my local test build to finish, to make sure that a rebuild of perl will resolve my issue
<LocutusOfBorg> with perl we shoudl also sync... let me check
<LocutusOfBorg> rename
<xnox> huh? rename what?
<LocutusOfBorg> I was going to sync, but autopkgtests are already fully
<LocutusOfBorg> src:rename
<LocutusOfBorg> if we have to rebuild, better sync instead
<cyphermox> Laney: I'll fix ubiquity, unless you already started..
<doko> rbasak, jamespage: there was no tomcat8 merge for a while ...
<Laney> cyphermox: sure did
<cyphermox> yeah I just noticed
<cyphermox> pull, I merged fossfreedom's code
<LocutusOfBorg> doko, I would say tomcat8 needs a sync, not a merge
<tjaalton> LocutusOfBorg: no
<tjaalton> tomcat8.5 breaks dogtag-pki
<tjaalton> and tomcatjss
<LocutusOfBorg> I mean, tomcat8 "can" be syncd, because the delta is useless
<LocutusOfBorg> not "we should sync it right now" :)
<tjaalton> you'd just get it stuck in proposed because of failing freeipa-server autopkgtest
<tjaalton> so what's the point of syncing it then?
<LocutusOfBorg> mmm I still just mean, that it can be syncd, not that we should sync it
<Laney> okey dokey
<LocutusOfBorg> I honestly think that tomcat-8 needs to be syncd on next release cycle, are the two above useful packages?
<tjaalton> next cycle is when redhat should get dogtag/tomcatjss ported over
<LocutusOfBorg> mmm patching security stuff on old tomcat might become painful soon :)
<tjaalton> non-lts releases still
<tjaalton> doko: uploaded new apitrace to debian, fixes build
<xnox> LocutusOfBorg, rebuild results in I_XLOCLAE not defined; synced perl over.
<rbasak> tjaalton: would you mind noting that on https://merges.ubuntu.com/main.html please?
<tjaalton> rbasak: sure
<rbasak> Thanks! As I read the scrollbackscroll I knew there was a reason but couldn't remember why, and I figure that's a good place to note it for reference the next time I'm asked :)
<tjaalton> yeah, it's there now
<LargePrime> juliank, regarding your gnutls patch, how can i test it?  i have to add a repo, right?  how can i pull just that one updated library?
<juliank> LargePrime: It's all explained in the wiki page that was linked in the bug report https://wiki.ubuntu.com/Testing/EnableProposed
<juliank> LargePrime: Just with zesty instead of xenial, of course
<juliank> LargePrime: Summary: Add sources.list entry, add preferences entry, and then apt install libgnutls30/zesty-proposed
<LargePrime> thanks again
<LocutusOfBorg> interesting xnox
<LocutusOfBorg>  #   include <xlocale.h>
<LocutusOfBorg>              ^~~~~~~~~~~
<LocutusOfBorg> this happens in libguestfs
<LocutusOfBorg> so, I presume until perl is rebuilt, mostly everything will FTBFS?
<xnox> LocutusOfBorg, yes.
<LocutusOfBorg> https://launchpadlibrarian.net/336044681/buildlog_ubuntu-artful-ppc64el.libguestfs_1%3A1.34.6-7ubuntu1_BUILDING.txt.gz
<LocutusOfBorg> ack
<xnox> /usr/lib/powerpc64le-linux-gnu/perl/5.26/CORE/perl.h:738:13: fatal error: xlocale.h: No such file or directory
<xnox> yeah, that's the badger.
<LargePrime> juliank, from that wiki 'sudo aptitude -t zesty-proposed' gives 'sudo: aptitude: command not found'
<LocutusOfBorg> thanks for cathing it early!
<LargePrime> i dont like pain when i cath
<seb128> bdmurray, hey, I put some update-notifier fixes for wayland up for review on https://code.launchpad.net/~seb128/update-notifier/wayland-no-pkexec/+merge/330278 https://code.launchpad.net/~seb128/update-notifier/work-under-wayland/+merge/330271 , would be nice if you could review them today I would like to upload this week so we start getting more feedback about issues under wayland, atm users don't get prompted by apport to report those
<bdmurray> seb128: I saw and will have a look today
<seb128> bdmurray, thanks!
<juliank> LargePrime: You don't need to do that
<juliank> LargePrime: It would just show you what is available
<juliank> LargePrime: Just apt install libgnutls30/zesty-proposed :D
<doko> xnox: perl ftbfs on i386. test failure. give back?
<LocutusOfBorg> "06_timed.t" yes, I would say to give back
 * LocutusOfBorg does it, I think this happened already in the past
<xnox> tah for monitoring
<bdmurray> xnox: have you seen bug 1713984? I just had a very long boot myself
<ubottu> bug 1713984 in systemd (Ubuntu) "started raise network interfaces - times out" [Undecided,Confirmed] https://launchpad.net/bugs/1713984
<xnox> bdmurray, yes and i think i know how to fix it. but not fixed yet.
<bdmurray> xnox: Shall I target to artful? assign to you?
<infinity> xnox: Definitely intentional.
<xnox> infinity, tah. fix in perl is inflight - rebuild should make perl.h sane again.
<xnox> bdmurray, yes please.
<LargePrime> juliank, I have it working.  patch works great!  my question about the wiki command had to do with noting some sort of error on the wiki.
<LargePrime> also thanks
<doko> infinity: https://bugs.launchpad.net/debian/+source/glibc/+bug/1715366
<ubottu> Launchpad bug 1715366 in glibc (Ubuntu) "stage1 builds try to install gdb hooks, which are not built" [Undecided,New]
<doko> but the cross-build fails later with linker errors
<Anticom> Hi all. Are packages published on *.ubuntu.com on topic here?
<Anticom> It's really bugging me, that libgtest-dev is not being built in a post-install hook
<doko> this is not Gentoo
<Anticom> doko: ?
<ogra_> doko, tell that to the dkms maintainers :P
<LocutusOfBorg> Anticom, we cant bild libgtest-dev
<LocutusOfBorg>   * control: Switch to cmake (upstream deprecated autoconf build).  Build
<LocutusOfBorg>     only static library (remove libgtest0 package).  Install full source
<LocutusOfBorg>     and example files.
<LocutusOfBorg> http://metadata.ftp-master.debian.org/changelogs/main/g/googletest/unstable_changelog
<LocutusOfBorg> packages depending on it should build it when needed locally
<LocutusOfBorg> http://bugs.debian.org/662989
<ubottu> Debian bug 662989 in gtest "gtest: libgtest.a needs to be built with -fPIC" [Normal,Fixed]
<Anticom> LocutusOfBorg: Well maybe i was not precise. Afaik you're supposed to invoke cmake after installing libgtest-dev yourself to produce the *.so's etc. However the package depends on cmake already iirc and debs do support post-install triggers don't they? so why not trigger the cmake 'build' after the package has been installed?
<LocutusOfBorg> no, a package you maintain, that needs libgtest-dev should just include its cmake file, and live happy
<Anticom> LocutusOfBorg: So you mean adding gtest via cmake's add_subdirectory in order to build it as a target before linking against it?
<LocutusOfBorg> that one, yes
<Anticom> hm, doesn't sound very convenient. However as i said i don't understand why everyone should build libgtest themselves anyway
<LocutusOfBorg> because providing a system shared library failed
<LocutusOfBorg> and google told us to remove it because it can't work
<LocutusOfBorg> even the static one
<LocutusOfBorg> you will find references to google/debian bugs if you search
<Anticom> Yea I get that, i've read that myself (in the google docs). However i'm suggesting to invoke cmake after the sources have been installed in a post-install trigger
<Anticom> Or wouldn't that work either?
<LocutusOfBorg> nope, this is not Gentoo :)
<LocutusOfBorg> the latter, it wouldn't work
<Anticom> Bc this is typically what i do. I just sudo cmake where it's installed
<Anticom> and with my projects i didn't have any issues
<infinity> I suspect the concern here is that you need gtest built with the same compiler/linker options as your project.
<LocutusOfBorg> I don't remember the exact issue, maybe some ABI
<Anticom> Hm well, too bad
<Anticom> Thank you guys for the elaboration :)
<LocutusOfBorg> yes, probably, the ABI is not stable, building with different CFLAGS/LDFLAGS/GCC and so on changes the gtest library
<infinity> Compiling it at install time would give the same results as us delivering a binary package to you -- it would have defaults that might be wrong.
<LocutusOfBorg> exactly, but again, too much time has been since I looked at gtest
<LocutusOfBorg> now it is googletest btw
<Anticom> LocutusOfBorg: nope, still libgtest-dev
<LocutusOfBorg> the source package is src:googletest that provides the libgtest-dev libraru
<Anticom> ah i see
<Anticom> okay thanks guys
<LocutusOfBorg> you are welcome
<LocutusOfBorg> hello perl, welcome back on i386
<LocutusOfBorg> publisher run and FUN
<juliank> infinity: LocutusOfBorg: I must say though that not shipping the library is a bit annoying. Other distributions do ship it, and the CMake plugin for gtest relies on the library, so you end up with ugly workarounds like the first 22 lines here: https://anonscm.debian.org/cgit/apt/apt.git/tree/test/libapt/CMakeLists.txt
<juliank> (re gtest)
<juliank> Although if everyone else would just switch over that would work as well
<doko> infinity: any idea about https://launchpadlibrarian.net/336065945/buildlog_ubuntu-artful-amd64.cross-toolchain-base_18ubuntu1_BUILDING.txt.gz ?
<doko> not architecture specific
<doko> argh, https://launchpad.net/ubuntu/+source/gcc-5/5.4.1-12ubuntu3/+build/13343450 ... SIGSEGV now undefined. header moved?
<infinity> doko: Probably a side-effect of 9e78f6f6e7134a5f299cc8de77370218f8019237
<infinity> Though, how it manifests only in our cross builds is something to look into.
<jackpot51> tsimonq2: I have added a debdiff file here: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1699216
<ubottu> Launchpad bug 1699216 in gnome-initial-setup (Ubuntu) "Encrypted home support" [Wishlist,Confirmed]
<jackpot51> Let me know if that is what you need
<LocutusOfBorg> juliank, http://sources.debian.net/src/pcl/1.8.1%2Bdfsg1-2/cmake/Modules/FindGtest.cmake/?hl=27#L27
<LocutusOfBorg> you are probably right: https://gist.github.com/oneamtu/3734295
<juliank> LocutusOfBorg: The offiical FindGTest.cmake shipped with CMake is different: https://github.com/Kitware/CMake/blob/master/Modules/FindGTest.cmake
<LocutusOfBorg> maybe we should make it smarter and submit the patch upstream
<juliank> LocutusOfBorg: Probably
<juliank> but it's work and it takes time
<LocutusOfBorg> the cmake module maintainer might want to do it
<juliank> might have migrated to meson by the time it's widely available :)
<tsimonq2> jackpot51: ack, I'll look in a few hours. Thanks!
<catbus> jsalisbury: Hi, could you please advise what other kernel to test for bug 1646277?
<ubottu> bug 1646277 in linux (Ubuntu Xenial) "Xenial server 16.04.x will have a black screen after PXE installation" [Medium,Confirmed] https://launchpad.net/bugs/1646277
<LocutusOfBorg> infinity, are you aware of missing xlocale.h ? https://launchpadlibrarian.net/336088033/buildlog_ubuntu-artful-ppc64el.boinc_7.9.0+dfsg~git20170906+r23843~r10~ubuntu17.10.1_BUILDING.txt.gz
<LocutusOfBorg> this smells like a glibc regression
<jsalisbury> catbus, sorry for the delay on that bug.  I'll review it and see what the next steps should be.
<catbus> jsalisbury: thank you!
#ubuntu-devel 2017-09-07
<infinity> LocutusOfBorg: It's not "missing", it's removed intentionally.
<infinity> * The nonstandard header <xlocale.h> has been removed.  Most programs should
<infinity>   use <locale.h> instead.  If you have a specific need for the definition of
<infinity>   locale_t with no other declarations, please contact
<infinity>   libc-alpha@sourceware.org and explain.
<infinity> LocutusOfBorg: ^
<cpaelzer> Laney: (or anyone else on autopkgtest) I've seen that since the 5th these tests are failing http://autopkgtest.ubuntu.com/packages/vagrant-mutate/artful/ppc64el
<cpaelzer> seems reproducible and the error always is "Error: Failed to connect to atlas.hashicorp.com port 443: Connection timed out"
<cpaelzer> other arches as well as local tries seem to work
<cpaelzer> so I wonder if there might be any Firewall or Proxy setup that might cause this?
<LocutusOfBorg> ack infinity
<Laney> cpaelzer: it's probably https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1715128
<ubottu> Launchpad bug 1715128 in cloud-init (Ubuntu) "Crashes in convert_ec2_metadata_network_config on ScalingStack bos01 (ppc64el)" [Undecided,New]
<cpaelzer> I opened bug 1715555 for what I saw, but the bug you listed makes sense to all I've found
<ubottu> bug 1715555 in Auto Package Testing "ppc64el vagrant-mutate tests fail to access atlas.hashicorp.com" [Undecided,New] https://launchpad.net/bugs/1715555
<cpaelzer> my issue boils down to proxies missing and the bug you referred is reporting just that as an issue
<cpaelzer> I'm dupping mine - thanks for the info
<cpaelzer> Laney: do we fake the EC2 datasource in our scalingstack?
<cpaelzer> to provide the config data to cloud-init
<Laney> I don't know how that stuff works
<Laney> it's more or less the normal cloud images if that helps
<cpaelzer> that is only the consumer
<cpaelzer> how the config is passed is the interesting part in this case
<cpaelzer> Laney: it would be great if you could add the full boot log containing all cloud-init output to the bug
<wgrant> bos01 is a pretty standard kilo AFAIK
<wgrant> We didn't do anything specially EC2ish while deploying it
<cpaelzer> so it should be detected as openstack datasources then, which it is not
<wgrant> How does cloud-init actually detect the datasource, though?
<cpaelzer> Laney: if you could attach the output from the failing ppc as well as the working lcy01 or lgw01 that would be great
<wgrant> If it uses DMI or something that might just not work on ppc64el with our relatively old setup
<cpaelzer> wgrant: Laney: https://git.launchpad.net/cloud-init/tree/tools/ds-identify
<wgrant> I have a religious objection to 1300 line shell scripts.
<wgrant> Ah yes, lots of DMI bits in there.
<Laney>  https://bugs.launchpad.net/cloud-init/+bug/1715241?
<ubottu> Launchpad bug 1715241 in cloud-init "ds-identify openstack returns not found on non-intel" [Medium,Confirmed]
<cpaelzer> Laney: if you could provide those logs I'm sure smoser and rharper will find that most interesting later on and then has all the data to start finding what is wrongin the detection
<wgrant> Aha
<cpaelzer> It shoudl still find an openstack config drive no matter of DMI in your case
<cpaelzer> (assumption)
<wgrant> I have never seen an OpenStack that used configdrive.
<wgrant> Oh you can do it when creating the VM, I see.
<cpaelzer> which brings me back to my former question what you currently use to pass cloud init config info?
<wgrant> Still never seen it used :)
<wgrant> It uses the normal Nova metadata HTTP service
<cpaelzer> thanks
<cpaelzer> I'll copy this chat to the bug, together with the logs Laney can provide this should make some progress when US wakes up later
<wgrant> Thanks.
<Laney> Ta
<Zwei> Hello, I'm trying to add the test toolchain ppa, but I get this error: http://codepad.org/YoDRkJ69
<Zwei> I've googled around but not 100% sure how to fix this. Should I do some of the solutions mentioned here? https://askubuntu.com/questions/49040/apt-could-not-find-a-distribution-template-error
<Zwei> I want to double check since I want to minimize downtime. Thank you.
<Zwei> (I was told to come here and ask doko, so tagging doko...)
<cpaelzer> Zwei: was this just happening the last minutes?
<cpaelzer> Zwei: if so could you retry
<cpaelzer> I happened to be unable to access the ppa's pages but just now things seem to have resolved
<cpaelzer> also the add is working in a zesty for me atm
<cpaelzer> Zwei: related issues seem to be around a broken /etc/lsb-release, please share that as well if it still is an issue
<Zwei> cpaelzer: just restarted and I got a popup window/error about "add-apt-repository has stopped unexpectedly"
<Zwei> hmm, I guess I should fix that first somehow.
<Zwei> this is my /etc/lsb-release: http://codepad.org/7Lg1CbfB
<Zwei> I still get exactly the same error when I run "sudo add-apt-repository ppa:ubuntu-toolchain-r/test"
<wgrant> Zwei: Hm, how long since that machine has been updated? Its lsb-release looks quite out of date.
<Zwei> Hmm... I'm in Synaptic Package manager, trying to find out which package caused the error, I clicked Reload and for this: "The repository 'http://ppa.launchpad.net/jonathonf/gcc-6.3/ubuntu yakkety Release' does not have a Release file."
<Zwei> But I thought I was using Zesty, as per the lsb-release, not yakkety.
<Zwei> wgrant: Updated in January this year...
<Zwei> Well, that's when I installed 17.04, since I needed gcc 6.x
<wgrant> You apparently haven't upgraded since well before zesty went stable in April
<wgrant> Try upgrading to stable zesty and see if it works
<wgrant> (well, reinstall the machine because it's probably compromised, then upgrade :))
<Zwei> Okay, will google that, will report back.
<Zwei> Oh, I need to reinstall the OS?
<Zwei> damn...
<Zwei> wanted to avoid that.
<wgrant> Zwei: You don't have to, but you are at least six months behind on security updates, so if it's been anywhere near the Internet I would be reinstalling it myself.
<wgrant> Zwei: Anyway, if you have further questions then #ubuntu can probably help you.
<wgrant> This channel is for Ubuntu development, not general support.
<Zwei> wgrant: thank you for your help!
<Zwei> :)
<acheronuk> LocutusOfBorg: breakage here as well :/ https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1715599
<ubottu> Launchpad bug 1715599 in glibc (Ubuntu) "2.26-0ubuntu1 breaks compliation of several KDE sources" [Undecided,New]
<Unit193> LocutusOfBorg: I don't suppose you're still here?
<Unit193> LocutusOfBorg: Just looking for a sponsor for https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/8240708/+listing-archive-extra (since for some reason it isn't in the packageset still.)  It's a bugfix release, adds translations, and addresses the only remark doko (ftp-master) had on it.
<Unit193> http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-statusnotifier-plugin-0-2-0-released-tp49735.html
<xnox> doko, infinity - i'm having new fun with NM NetworkManager: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by NetworkManager)
<xnox> and i am confused =)
<xnox> that's from autopkgtest. If NM tries to require that symbol, it should have had a tigher glibc dep generated by the build, no?
<LocutusOfBorg> Unit193, will have a look tonight
<cpaelzer> cyphermox: sorry to reply in-meeting - I didn't realize
<cpaelzer> cyphermox: just replied to highlights
<cpaelzer> bug 1711358
<ubottu> bug 1711358 in ubiquity (Ubuntu) "20170817 - ISO hangs on boot on qemu with splash screen enabled and qxl graphics driver" [High,Confirmed] https://launchpad.net/bugs/1711358
<cyphermox> cpaelzer: no worries
<cpaelzer> I came over a report on virt-inst which I handle
<cyphermox> yeah, I noticed such issues, but been busy on something else
<cpaelzer> but eventually found that, you might find some extra info in the dup bug on there
<cyphermox> I'll spin a vm as soon as our meeting is done
<cpaelzer> I just failed to know how to debug plymouth at all, as it wasn't helping me with any messages
<cpaelzer> I documented a set of workarounds in the bug (different video driver, nosplash, ...)
<cpaelzer> but then gave up and hoped for people experienced in that area
<cpaelzer> which I must admit I don't have a "name for plymouth" in my mind
<doko> LocutusOfBorg: https://launchpad.net/ubuntu/+source/h5py/2.7.1-1ubuntu1  please build with -v<version>
<acheronuk> with autopkgtest-build-lxc, when running setup-testbed, neworking fails for the container :/
<acheronuk> Running setup script /usr/share/autopkgtest/setup-commands/setup-testbed...
<acheronuk> grep: //etc/network/interfaces: No such file or directory
<acheronuk> Err:1 http://archive.ubuntu.com/ubuntu artful InRelease
<acheronuk>   Temporary failure resolving âarchive.ubuntu.comâ
<jackpot51> Are didrocks or jbicha available to talk about GDM theming?
<mwhudson> morning
<tsimonq2> o/ mwhudson
<tsimonq2> mwhudson: How are you doing?
<tsimonq2> acheronuk: What does /etc/resolv.conf look like? I'm thinking systemd-resolved :P
<acheronuk> tsimonq2: can't check now. I nuked it all. will try tomorrow
<tsimonq2> acheronuk: ack
<LocutusOfBorg> Unit193, .
<Unit193> Thanks!
<LocutusOfBorg> yw!
<Unit193> Very interested in having it for myself too. :)
<sarnold> Unit193: .
<sarnold> dunno what you're going to do with these punctuation marks but i'm feeling generous
<tsimonq2> sarnold: Debian people (or so I hear) use "." as an alias for "taken care of" or "done"
<tsimonq2> sarnold: I was tricked by it too :P
<Unit193> á£ á£ á£   á§ * * * * * *
<sarnold> Unit193: @>--`--,--`---
<Unit193> \o/
<Unit193> tsimonq2: Not that I've ever seen, it's just a Locutus thing. :)
<tsimonq2> Unit193: Oh, mapreri told me at one point it's a Debian Release Team thing :P
<Unit193> Mmmm, could be.  I don't tend to interact with that group.
<tsimonq2> Unit193: Also, nice Pacman emojis :D
<tsimonq2> Pac Man? Pacman? PacMan? *shrug*
<wxl> you mean canadian aboriginal syllabics
<tsimonq2> wxl: lol?
<Unit193> sarnold: I have a rose, but it's waaaay too much for here. :3
<sarnold> hehe
<cjwatson> infinity: yo, you should possibly clear out root's .bash_history from chroot tarballs.  freaked me out slightly just now when I pressed up-arrow right after unpacking it and there were commands I knew I'd never typed
<sarnold> *terror*
<sarnold> what's your heart rate now?
#ubuntu-devel 2017-09-08
<infinity> cjwatson: My work here is done, then.
<Unit193> Crap, there was a really useful page that had info on autopkgtests, but now I'm unable to find said page..
<cpaelzer> Unit193: what for example would you look for there?
<cpaelzer> how they are written or where/how they are executed in infra?
<Unit193> Well for one it's a really good reference page, and no it's about running them yourself.
<cpaelzer> Unit193: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test ?
<cpaelzer> https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html ?
<Unit193> That's what I found as well, it isn't it.  The other was something about basics, lxc, and all.  Was short enough, but pretty decent nevertheless.  I haven't been able to find it, but found my issue.
<cpaelzer> https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst are the other two I have bookmarked on this topic
<Unit193> (I had also found https://phabricator.kde.org/w/kubuntu/autopkgtests/staging_howto/ and https://www.wefearchange.org/2016/11/sbuild-redux.html)
<Unit193> cpaelzer: What I needed, I'm updating package A and in doing so want to test all rdeps against it.
<Unit193> Issue, for the magic ruby tests, one needs autodep8.
<cpaelzer> as long as it worked I loved bileto for that (test all rdeps on LP infra), but missing robru that slowly starts to bit-rot too much
<cpaelzer> I'd really love a general autopkgtest-my-ppa button
<cpaelzer> but I understand that might be a ressource hog
<cpaelzer> maybe with some sort of per user limiting
<Unit193> Well it's not pretty, but   for pkg in $(apt-cache rdepends ruby-net-ssh | sed -n 's@  @@p');do sudo autopkgtest -U -o $pkg -B /var/cache/pbuilder/result/unstable/ruby-net-ssh_4.2.0-1_all.deb $pkg -- lxc autopkgtest-sid;done   does the trick, once I got autodep8 figured out.
<cpaelzer> blahdeblah: would you verify bug 1706818 on xenial or should I?
<ubottu> bug 1706818 in ntp (Ubuntu Xenial) "mismatched file locking since 1:4.2.8p4+dfsg-3ubuntu1 causes race leaving ntp dead on reboot" [High,Fix committed] https://launchpad.net/bugs/1706818
<sil2100> Anyone looking at the update-notifier autopkgtest failures or can I take a look at those?
<LocutusOfBorg> sorry doko I don't receive all the messages, I'm still trying to get how to make irc bouncer work correctly
<LocutusOfBorg> [18:05:40] <doko> LocutusOfBorg: https://launchpad.net/ubuntu/+source/h5py/2.7.1-1ubuntu1  please build with -v<version>
<LocutusOfBorg> I don't get this, this was a subsequent upload after a sync of 2.7.1-1
<LocutusOfBorg> so, I don't get which -v should have passed...
<LocutusOfBorg> against the one in release and not against the one in proposed? seems strange to me
<acheronuk> I assume there is not much chance of getting exiv2 0.26-1 currently in debian/exp into artful?
<acheronuk> not overly hopeful, but 'nothing ventured' as the say: bug #1715931
<ubottu> bug 1715931 in exiv2 (Ubuntu) "Update to evi2 version 0.26" [Undecided,New] https://launchpad.net/bugs/1715931
<jbicha> acheronuk: the new version requires a library transition, have you checked whether all rdepends still build with the new version?
<jbicha> https://release.debian.org/transitions/html/auto-exiv2.html
<acheronuk> jbicha: not yet. only just started looking. not very hopeful, but not the end of the world if not possible either
<jbicha> it's a lot of work â¦ :)
<acheronuk> indeed. well the bug is there for 18.04 when it gets going :P
<jackpot51> didrocks: I am going to work on https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1715722 with the method I described first, having alternatives for a gdm.css file that is the stylesheet of GDM
<ubottu> Launchpad bug 1715722 in gnome-shell (Ubuntu) "Allow safe override of GDM3 theme" [Undecided,New]
<jackpot51> It is critical to our Beta release that we have a reliable method of overriding the GDM theme, so the alternatives method seems to be the best way to go. We can talk about further improvement and upstreaming after 17.10
<didrocks> jackpot51: I think it will need a FFe though
<jackpot51> In my mind, it isn't a feature
<jackpot51> It is a bug fix for a bug affecting flavors of Ubuntu using GNOME
<didrocks> jackpot51: you meant "deratives" rather than flavors? I don't know of any existing 17.10 flavors using gdm?
<jackpot51> Yes, that is what I mean - derivatives
<jackpot51> If this becomes too complicated, we would have to fork the gnome-shell package to accomplish what we need to in Pop before 17.10
<jackpot51> So I would like to do this as simply and smartly as possible
<didrocks> jackpot51: I guess you just need to talk to the release team telling us you want to do a temporary override until we get a better upstreamable solution and see if they consider it's a FF breakage or not
<didrocks> maybe Laney can quickly give his thoughts ^
<Laney> where does this pop.css come from?
<jackpot51> Ok, that sounds good to me
<Laney> I think it'd be easier for you to dpkg-divert the ubuntu one away if this is a temporary solution for one derivative only
<jackpot51> Pop is a derivative of Ubuntu, providing a different GNOME experience. This also involves a custom GDM theme. I want to be able to install ubuntu-session on Pop, and pop-session on Ubuntu. Currently, the ubuntu.css has to be overridden by pop-session to provide correct GDM theming, which breaks the theme in ubuntu-session
<jackpot51> I would code a method for both ubuntu-session and pop-session to coexist happily on the same system
<jackpot51> I want to do it the right way, which I believe to be alternatives for the time being, as this will allow the user to select the GDM theme
<Laney> jackpot51: It feels like a lot of complexity and risk for a one-use temporary solution
<Laney> but if you really want to work up the patches and someone agrees that they'll review them then I guess you can
<Laney> if it were me I'd use dpkg-divert and say that the way to revert to Ubuntu's theme is to uninstall the package
<jackpot51> The package it comes in is gnome-shell-common, one that cannot be removed.
<jackpot51> I will look into using dpkg-divert in our gnome shell theme package, but I would still want to be able to have both Ubuntu and Pop GNOME themes installed side by side
<sil2100> bdmurray: hey! Would you mind if I propose an MR to fix the failing update-manager autopkgtest?
<bdmurray> sil2100: No, what's failing now?
<sil2100> bdmurray: one test case is wrong, started failing because a new update of policykit arrived at -updates
<sil2100> But the update is unrelated
<sil2100> Just the test case is wrong and it was working by 'luck' I'd say
<jackpot51> didrocks, Laney: I created a debdiff adding the alternatives method. It was not much code, so I just wanted to get it out there for you to review: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1715722/comments/5
<ubottu> Launchpad bug 1715722 in gnome-shell (Ubuntu) "Allow safe override of GDM3 theme" [Undecided,New]
<sil2100> Let me explain on the MP, you can then tell me if I think right
<sil2100> bdmurray: https://code.launchpad.net/~sil2100/update-manager/fix-test-failure-origin/+merge/330446
<didrocks> jackpot51: I doubt you tested it
<didrocks> seeing the postinst, you don't reference ubuntu.css
<didrocks> but I'm really not a fan of that approach as told and would prefer an upstreamable solution as told many times, if anyone else wants to sponsor it, (after testing it) feel free
<jackpot51> Sorry, I uploaded the patch prematurely, true. I am waiting for launchpad to build a version that has the correct path: https://launchpad.net/~system76/+archive/ubuntu/pop-staging/+build/13352379, so I can do a full test of this.
<jackpot51> I imagine it is too late to get a patch to you today, so I will fork gnome-shell instead
<jackpot51> I will also work on an upstreamable solution, but I am not very satisfied with your unwillingness to see things from my perspective. You have essentially broken GDM3 for all Ubuntu derivatives, forcing your theme upon them, and then having no desire to work on any solution to remove this hard-coded theming
<Laney> hmm, I guess actually we could use this in Ubuntu to let people use the default gdm theme
<Laney> maybe not, that's the built in one isn't it?
<Laney> jackpot51: please attach it, I think it's worth considering
<Laney> goodnight!
<jackpot51> Ok, good night Laney
<didrocks> jackpot51: mind toning a little bit done please?
<didrocks> jackpot51: you are quite offensive in that bug report
<didrocks> and proposing a patch that you even didn't test it doesn't really pledge your saying
<jackpot51> I know I screwed up, and I am sorry. But I don't want to have our amount of maintenance increased significantly because of a hardcoded GDM theme. For the short term, I can override the gnome-shell package, but it is not good for release
<didrocks> jackpot51: does it justify this tone?
<jackpot51> Building on gnome-shell on a new Artful installation is breaking, so I have to wait for the launchpad build to test changes.
<jackpot51> No, it does not. I apologize for being offensive
<didrocks> ok, better ground (not really fancy having this kind of discussion on Friday at 7:15PM)
<didrocks> so, if I have the certainty you will work on a longer term solution, alternatives is ok
<didrocks> (as the other solution I gave)
<didrocks> I just don't want that we keep this for the LTS
<didrocks> does it make sense? If so, please test the patch (especially lock screen-wise, that's the part I'm unsure if you install 2 sessions with different lock screen theme, which one will be picked)
<didrocks> and if you tell me it's good, I can sponsor it on Monday
<didrocks> (after a final round of testing ofc)
<jackpot51> What happened was that user-theme stopped working the day of feature freeze for us, leading to a cascade of theming changes we had to do. This culminated in theming GDM by replacing the ubuntu.css file, which broke my ability to use ubuntu-session. I like to see all three sessions (Ubuntu, Pop, and GNOME) for testing, so I only wanted a way to keep
<jackpot51>  them all installed while having the GDM theme we had designed. That is all. We are in a scramble to get things fixed in a sane way, allowing us to release an ISO with our own theming. I am very sorry for out of line, I have misinterpreted messages from others and gone overboard.
<didrocks> but again, I don't want to carry the patch post-17.10. I think there is a very good opportunity for cooperating inside GNOME to have those easily themeable (Shell, GDM)
<didrocks> jackpot51: maybe your company could have talk or even help us within ubuntu itself to get things prepared
<didrocks> and we could have cooperated, things were discussed :)
<jackpot51> I agree. I am here, always, with an IRC bouncer. I have been following the ubuntu-devel mailing list, which is where I first saw the gnome-shell changes. Other members of our community are present here.
<didrocks> come participate and ask during our meeting on #ubuntu-desktop, and work within ubuntu rather than a derivative, that will help your case being taken into account :)
<jackpot51> I also want to have a good way for all GDM instances on all distributions to have the GDM look and feel configured
<didrocks> jackpot51: so, on that one, do we agree with the timeline? You test the patch (especially lock-screen wise), if all +1 (tell it on the bug report), I will sponsor this on Monday, and then, we work together inside GNOME to get the proper fix before the LTS
<jackpot51> I, however, feel there is a systemic issue in the Ubuntu community of not working with people like myself, who are outsiders trying to make their way into the community
<didrocks> I'm unsure about the "trying to make their way", I've never seen you participate on our desktop meetings for instance
<didrocks> where we have external contributors like jbicha and others
<jackpot51> I have written patches for ubiquity, wpa, gnome initial setup, gnome control center, and others. Some have been merged, most have been ignored
<didrocks> jackpot51: same in any projects unfortunately, I have multiple patches ignored and staying in GNOME bug tracker for yearsâ¦
<didrocks> jackpot51: but you are on IRC, so you can comment and ping on relevant channels, this is your added value :)
<jackpot51> For example, here is a (fully tested) patch for Encrypted Home, something that I was actually present in the Ubuntu Desktop meeting discussing a desire for it: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1699216
<didrocks> (and #ubuntu-desktop is a good one for those kind of topics)
<ubottu> Launchpad bug 1699216 in gnome-initial-setup (Ubuntu) "Encrypted home support" [Wishlist,Confirmed]
<didrocks> yeah, this has been discussed multiple times on #ubuntu-desktop
<jackpot51> Now, all I am asking for is *to not have our distribution broken by upstream*
<didrocks> I don't really know more but seen it discussed (as I don't have expertise in accountservice)
<didrocks> jackpot51: working inside ubuntu would have helped prevented that, or at least communicating on IRC and asking for our plans
<jackpot51> I WAS HERE
<jackpot51> I was on #ubuntu-desktop and I talked with people about this patch
<jackpot51> I was on the mailing list
<jackpot51> I was on launchpad
<jackpot51> I subscribed ubuntu-sponsors
<jackpot51> I provided a debdiff
<didrocks> about the GNOME Shell one?
<jackpot51> No, the encrypted home one
<didrocks> you are telling "all I am asking for is *to not have our distribution broken by upstream*"
<didrocks> I was answering on that one
<jackpot51> This one is different, the implementation details, not the high level details, hit us by surprise
<didrocks> I don't know about the other one and the state of it
<didrocks> ok, anyway, we have a plan for the gdm theming, right?
<jackpot51> Yes, I believe so
<didrocks> I guess it's going to work at least for 17.10
<didrocks> we'll then get the better solution, where I hope system76 will help GNOME upstream to get this done
<didrocks> and we'll revisit
<jackpot51> That is good to hear. I will be communicating with GNOME upstream, opening a bug on their tracker and talking on their IRC, to do the right thing
<didrocks> good :)
<jackpot51> Sorry about my mistakes on the patch earlier, and about the time-criticality of this patch
<didrocks> no worry, I can understand patch not being fully fledge, I accept less the tone though
<didrocks> (and we all live on deadlines :p)
 * didrocks really goes on week-end now
<jackpot51> True that
<jackpot51> Have a good weekend didrocks
<didrocks> thanks, you too! and let's catch up on Monday jackpot51 :)
<jackpot51> Sure thing!
<jbicha> jackpot51: I wasn't around earlier but I can clarify a few things
<jbicha> your string of patches related to Encrypted Home is blocked on someone reviewing accountsservice
<jbicha> I did bring it up in this week's Desktop meeting: https://irclogs.ubuntu.com/2017/09/05/%23ubuntu-desktop.html#t13:05
<jbicha> I do apologize for the delay there but there's only a few people that can review that change and they've all been quite busy
<jbicha> this was fairly widely publicized: https://insights.ubuntu.com/2017/08/08/ubuntu-artful-desktop-fit-and-finish-sprint/
<jbicha> and that does say "GDM theming"
<jbicha> from your experience with Pop!_OS, I think you were already aware months ago that GDM theming is not that easy to override or switch between alternatives
<jbicha> I think the Ubuntu Desktop's theming actions weren't late at all since the User Interface Freeze is not until next week
<jbicha> https://wiki.ubuntu.com/ArtfulAardvark/ReleaseSchedule
<jbicha> Desktop Team meeting is at 15:30 UTC Tuesday currently (9:30 Colorado time) https://wiki.ubuntu.com/DesktopTeam/Meeting
<Unit193> <didrocks> where we have external contributors like jbicha and others   External?  I don't think someone running for DMB can be called "external" in any sense...
<Unit193> Unless by 'external' you mean not Canonical. :P
<jbicha> honestly, I'm not actively campaigning for DMB. It just looked like something that someone needed to doâ¦
<sdeziel> I'd like to know when is the next patch pilot? The Google calendar seems to be unmaintained/empty since April 2017
<jackpot51> Thanks jbicha, I will make sure to be present during the next desktop meeting. I have missed too many.
<jackpot51> I don't mind the delay, I just want to be sure we are in a safe place. If an upstream release of accountsservice happens, we will have to revert changes to initial setup and control center
<jackpot51> Currently we have "safe" forks of initial setup and control center, but I was unable to have a safe replacement of accountsservice
<Unit193> jbicha: Nobody ever does, just a wiki page usually.  Also sure it didn't land past UI freeze, but made it less idea for others, like jackpot51, where the only way to fix it would be to break FF.  It's a bit of a hard move.
<jackpot51> By the way, the work Ubuntu has done to theme GDM and GNOME Shell has been very helpful for our own efforts. It has been nice to finally kill off the use of "User Themes" - theming using stylesheets and modes feels much more correct
<Unit193> (I've also had no interaction with jackpot51 or Pop! before, btw, so I don't have a specific reason to be "on his side".)
<Unit193> jackpot51: Who was your UEFI guy?
<jbicha> yeah, GDM is the one exception where we don't have a good way to separate out the major Ubuntu changes but that's also a bit of an upstream problem
<Unit193> LocutusOfBorg: So it seems I've gone and done it... https://wiki.ubuntu.com/Unit193/MOTU
<jackpot51> Unit193 what do you mean UEFI?
<Unit193> jackpot51: I was talking with someone from sys76 a while ago, he was doing stuff with UEFI and Qemu.  I suppose it doesn't really matter.
<jackpot51> Was that Jason or David?
<Unit193> Jason could be, don't know real names.
<jackpot51> jderose
<Unit193> Yep!
<Unit193> mapreri: Not sure if you're interested, but might be.  MOTU application above, feel free to ignore or make comments about corrections!
<mapreri> Unit193: -v?
<Unit193> I'm not sure what else I could say, sorry for another communication blunder. :3
<mapreri> Unit193: I mean, where should I start reading?
<Unit193> https://wiki.ubuntu.com/Unit193/MOTU ?
<mapreri> oh, you mean you are running for MOTU and you seek an advocate?
<mapreri> looks so :)
<Unit193> Advocate if you feel like it, a general going over and comments about corrections if you don't wish to advocate.
<mapreri> ack
<Unit193> Thanks!
<mapreri> Unit193: I'll keep the tab open and will get back to you in the next few days
<Unit193> No problem, thanks muchly.
<mapreri> I kind of have a deadline looming over me and making me a tad anxious...
<jackpot51> What is a MOTU?
<mapreri> Unit193: well, you know about it, actuallyâ¦ :P
<jackpot51> nvm https://wiki.ubuntu.com/MOTU
<wxl> !motu
<ubottu> 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
<Unit193> jackpot51: People that can upload to non-core packages.  I'm an Xubuntu developer and can upload to Xubuntu packages (mostly), but that doesn't help for when I want to contribute outside of Xubuntu.
<mapreri> so, ja na
<Unit193> LocutusOfBorg: Just as an *FYI*, https://packages.qa.debian.org/t/tint2/news/20170908T210923Z.html previous upload built on everything besides hurd and kfreebsd.
<tsimonq2> jackpot51: fwiw irt the encrypted home patch, we're waiting on the Release Team to ack the FFE... that's, fwiw, outside of the Desktop Team's control (there's #ubuntu-release if you wish)
<jackpot51> Thanks tsimonq2, that is good to hear
<tsimonq2> jackpot51: Unfortuately, your patch was in a collection of ones on here: http://reqorts.qa.ubuntu.com/reports/sponsoring/
<tsimonq2> jackpot51: When I became MOTU on August 28th, I went and cleaned up shop a bit
<tsimonq2> (in the collection of untouched, unresponded-to)
<tsimonq2> jackpot51: But yeah, once that FFE gets a Release Team ack and in general an ack from the Desktop Team, I'll be happy to hunt someone down to upload it for you :P
<LocutusOfBorg> Unit193, do you want a sync?
<Unit193> LocutusOfBorg: If it's free, sure.
<jackpot51> Ok, thanks tsimonq2
<LocutusOfBorg> Unit193, you tell me :)
<LocutusOfBorg> you are applying to MOTU, so you should know if it should be syncd or not :p
<tsimonq2> jackpot51: yw, thanks for your work :)
<Unit193> LocutusOfBorg: Depends on how strict a view you have, it's certainly a splinter package, but https://gitlab.com/o9000/tint2/blob/master/ChangeLog that seems quite a jump from 12.12
<LocutusOfBorg> please get an Ffe, major code refactoring is something we shouldn't ignore
<LocutusOfBorg> https://anonscm.debian.org/cgit/collab-maint/tint2.git/tree/ChangeLog
#ubuntu-devel 2017-09-09
<juliank> jbicha: So, while I'll work around duplicate Contents-deb-legacy in 17.10, it would be a good idea to still change LP to generate modern per-component Contents file. At which point we can turn it on again I guess
<jbicha> thanks
#ubuntu-devel 2017-09-10
<tenplus1> hi folks
<tenplus1> Q. wasn't ubu 17.10 supposed to move from python 2.x to 3.x this release so it can be removed ???
<Faux> I thought so. https://lists.ubuntu.com/archives/ubuntu-devel/2017-June/039826.html
<tenplus1> cause libsmb client and in turn mpv and gimp still need python 2.6 to work...
<Faux> The plan was to remove it from the base install, I thought, not from the archive.
<Faux> [not an official answer]
<tenplus1> still got 2 months to go <fingers crossed> it might still happen :) heh
<tenplus1> thanks
<Faux> Pretty sure it won't be removed from the archive. It's still a supported piece of software upstream, with more users than most of the crap in there.
<tenplus1> weirdly enough I'm using LUA and it's a lot more friendly/smaller
<piet> Hello, I have a feature request for Ubiquity.
<piet> Currently, I think it's far too easy to select advanced options like full disk encryption and LVM.
<piet> This often leads to problems for beginners, who without thinking tick those options, which regularly causes difficulties for them which they can't solve.
<piet> I think it would perhaps be better if in the Ubiquity installation dialogue, both full disk encryption and LVM would be "tucked away" behind an Advanced button or something similar.
<piet> cjwatson and others: what do you think?
<doko> pitti: alive!
<juliank> piet: Really? I had to setup everything manually because ubiquity refused to do either LVM, LUKS, or GPT; but I really don't know which one anymore
<juliank> I think I had to manually setup grub because ubiquity did not install it correctly
<juliank> (It might be that it did not handle LVM without a separate /boot or something, which is crazy)
<juliank> I should reinvestigate that
<juliank> No wait, I did not setup encryption at all
<juliank> So, I tried installing Ubiquity with LVM on a UEFI system, but ended up doing all LVM stuff in the terminal because it was not available in ubiquit
<juliank> y
<juliank> (in 16.04.something)
<piet> juliank: sometimes these options are greyed out in the Ubiquity dialogue, sometimes not. I haven't investigated under qwh
<piet> ...which circumstances it's greyed out yet.
<juliank> I don't think I ever saw any, but I might be wrong
<juliank> t's been a few months
<juliank> In any case, I found the partitioning far too inflexible
<juliank> The disk was to be setup like this: small ESP followed by LVM partition with a / and a /home logical volume
<juliank> Both logical volumes fairly small, as we can grow them later
<juliank> Did not manage to do that in Ubiquity, although that's essentially the optimal setup
<juliank> (My own machine has the LVM in a LUKS, but that's another topic)
<piet> I think it would be better if those options would be more "tucked away", so it would be cearer that only advanced users should apply them
<piet> cearer = clearer
<juliank> I also I think it was creating mbr partitions all the time, despite being on an UEFI machine
<juliank> s/partitions/partition tables/
<juliank> piet: Ah, you mean the two shortcuts below the "Erase disk and install Ubuntu option"?
<piet> juliank: yes
<juliank> So I guess the problem with Ubiquity is that it supports LVM and encryption in that screen, but the partition editor supports neither
<juliank> Looking at the editor, when you want to create a partition, it only offers you file systems
<piet> perhaps that too, but mainly the problem is (in my opinion) that these options are only suitable for advanced users. Now they are too accessible for inexperienced users.
<piet> Putting them behind an "advanced" button or something, would make that clear
<juliank> piet: Well, I don't see the use case for the options anyway
<juliank> I mean if you are advanced user, you likely want to setup partitions to your liking and not use a "erase disk and install ubuntu option"
<juliank> So IMHO, the partitiion editor should support that and the options can go away on the "easy" page
<piet> juliank: Good idea! If they would disappear completely, that would be fine as well
<piet> disappear from the "easy" page, that is
<piet> juliank: could you perhaps make this happen?
<juliank> ubiquity is not really my kind of thing
<piet> Maybe you can talk to the devs who oversee Ubiquity?
<piet> have to go now, bye
<juliank> cyphermox: your gpg key contains a mathieu-tl@ubuntu.com UID, but: 550 5.1.1 <mathieu-tl@ubuntu.com>: Recipient address rejected: User unknown in virtual alias table
<juliank> maybe revoke it?
<maxb> Hello, is this the right place to suggest someone override an autopkgtest failure? python3-lxml (source: lxml) in artful currently segfaults on importing lxml.etree - the fix is in proposed, but is blocked by an unrelated issue with the snapcraft autopkgtest. The snapcraft issue is discussed here, including there apparently being a fix upstream.
<maxb> https://forum.snapcraft.io/t/snapcraft-autopkgtest-failure/2007
#ubuntu-devel 2018-09-03
<wxl> does anyone know what is keeping a fresh container from connecting to networking?
<tsimonq2> DNS?
<wxl> on a fresh container? bionic works fine and cosmic fails?
<tsimonq2> systemd-resolved is a weird beast.
<wxl> i guess having a broken systemd-resolved is worse than having a broken msttcorefonts, at least
 * wxl ducks
<tsimonq2> >:P
<tsimonq2> didrocks: Morning, how are you doing?
<didrocks> morning tsimonq2, I'm fine, yourself?
<tsimonq2> didrocks: Pretty good; I was just going through -proposed and wondered if you had eyes on https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-make
<didrocks> tsimonq2: I'm not the maintainer anymore, usptream is aware but quite puzzled
<didrocks> tsimonq2: maybe open a bug on the github project to remind them?
<tsimonq2> didrocks: Sure.
<pfsmorigo> hello, what line should I include in my preseed to avoid the "Continue installation without /boot partition?" query
<pfsmorigo> got it... partman-auto-lvm/no_boot
#ubuntu-devel 2018-09-04
<Unit193> ...Well dang, python-httplib2 does have quite a few rdeps.  Meh.
<ahasenack> tjaalton: around?
<tjaalton> ahasenack: yes
<ahasenack> tjaalton: adding dep8 tests to sssd: https://git.launchpad.net/~ahasenack/ubuntu/+source/sssd/tree/debian/tests?h=sssd-dep8-tests
<ahasenack> will soon make a merge request in salsa
<ahasenack> tjaalton: I'm guessing a bit in util's reconfigure_slapd(), I didn't want to purge and reinstall slapd. I think what I'm doing there is working
<tjaalton> ahasenack: ok, looks good
<ahasenack> hi, can somebody please update the agenda at https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda, the "next dmb meetings" bit is outdated
<seb128> bdmurray, hey, I would like to dispute that SRU team position you state on bug #1782320 "
<seb128> This is not yet fixed in cosmic as version 5.6-5ubuntu1 is still in -proposed."
<ubottu> bug 1782320 in brltty (Ubuntu Bionic) "Braille display inoperable in GUI since polkit-update" [High,New] https://launchpad.net/bugs/1782320
<seb128> bdmurray, saying that a security-update introduced in the LTS can't see it's SRU fix go to bionic-proposed because the corresponding cosmic upload is stucked in cosmic-proposed due glib blocking things atm isn't great imho
<seb128> security-update introduced *regression*
<seb128> slangasek, ^ btw  (unsure where would be the right place to discuss that policy, SRU team doesn't have a list? TB maybe?)
<seb128> I think it's wrong as a default position to block SRUs because the newer-serie fix is blocked in proposed for a reason which isn't due to the package itself
<bdmurray> seb128: We get lots of things uploaded in the queue which are incomplete / not following the process. When I first looked at this bug there was no Bionic task and I had to dig a bit to find out what was going on in Cosmic. When I saw it was stuck in -proposed for cosmic I stopped digging into what was going on.
<bdmurray> seb128: I'm fine with getting the fix into Bionic, just wanted to explain how the bug ended up where it is.
<seb128> bdmurray, I'm not sure I follow you, afaik that bug follows th process, the fix has been uploaded to cosmic, the cosmic line is fix commited, the description includes the impact/test case/regression potential sections, the changelog lists the bug number
<seb128> https://wiki.ubuntu.com/StableReleaseUpdates#Procedure doesn't state that having the bug targetting bionic is a pre-review condition afaik
<ricotz> hi, this seems to need a retry https://launchpad.net/ubuntu/+source/rust-syn/0.14.6-1
<seb128> ricotz, hey, depwait should autoclear no?
<ricotz> seb128, maybe not after a long time
<seb128> let me retry
<seb128> ricotz, those packages don't seem to exist though?
<ricotz> seb128, https://launchpad.net/~ricotz/+archive/ubuntu/mozilla/+build/15330344
<seb128> ?
<seb128> $ rmadison librust-quote-0.6+proc-macro-dev
<seb128> $
<ricotz> it builds in a ppa, and those dependencies are available
<Laney> could be a Provides from something else
<ricotz> there are a lot of virtual packages
<ricotz> exactly
<seb128> what source/package is providing them?
<ricotz> this is likely the reason it doesn't "autoclear"
<seb128> rustc?
<bdmurray> seb128: There is no need to have a bionic target, but having the cosmic task set to "Fix Committed" isn't enough for me to feel comfortable so I went and looked to see why it wasn't Fix Released in cosmic and added the comment about it being stuck in -proposed. I didn't look into why it was stuck in -proposed.
<seb128> bdmurray, k, I'm still failing to understand what I did wrong though
<ricotz> seb128, rust-quote
<seb128> bdmurray, or what is described on  https://wiki.ubuntu.com/StableReleaseUpdates#Procedure is not a reflection of what you expect as a SRU reviewer?
<seb128> ricotz, k, I guess that got uploaded together and it was not available at the time rust-syn tried to build
<seb128> and the provide things made it not get into depwait
<seb128> since it was not waiting on a real package maybe?
<ricotz> yes, this what I am thinking too
<Laney> https://bugs.launchpad.net/launchpad/+bug/335913
<ubottu> Launchpad bug 335913 in Launchpad itself "depwait builds do not retry even though the dep can be met via a virtual package" [High,Triaged]
<seb128> retrying is working, amd64 built
<seb128> I did retry the other archs as well now
<seb128> Laney, thx, that confirms it :)
<bdmurray> seb128: No it is and part 1 says 'Check that the bug is fixed in the current development release, and that its bug task is "Fix Released".' With regards to doing something wrong, I don't think you did here rather my point was I'm predisposed to think SRU uploads are missing something.
<bdmurray> s/you did/you did something wrong/
<seb128> k
<seb128> well, in that case the bug has been introduced by a CVE fix that went to bionic-security
<seb128> which exposed a bug in the policykit use of that app
<seb128> so I would appreciate if you could have a review :)
<seb128> thx for the explanations bdmurray!
<seb128> (I still think the SRU policy of waiting for things to be in the release pocket of the devel serie is not the right one, but I keep that one for Brussel maybe, I think there is a SRU team meeting there)
<bdmurray> people sometimes flip the bug status to fix committed and don't mention the bug number in the changelog for the development release and it requires some detective work to figure out what's happing in -devel
<seb128> that sounds like to me that you should request a clickable url to the devel-serie-fix in the bug description
<seb128> maybe as part of the process
<seb128> so the review can just click and doesn't have to do detective work
<seb128> reviewer*
<bdmurray> seb128: I'll add that to my notes for Brussels too
<seb128> thx
<seb128> ricotz, ryst-syn built on all arches now :)
<ricotz> seb128, thanks
<seb128> np!
<seb128> bdmurray, thx for the SRU
<ricotz> seb128, another one https://launchpad.net/ubuntu/+source/rust-tempfile/3.0.3-1
<ricotz> and https://launchpad.net/ubuntu/+source/rust-serde-derive/1.0.70-1
<ricotz> there are likely more
<seb128> ricotz, k, I'm going to look at the rust- packages blocked in proposed and retry builds
<ricotz> seb128, thanks
<seb128> yw!
<seb128> (done for those)
<ricotz> damn new firefox dependency
<ricotz> chrisccoulson, likely something to include into cargo backports or so
<ricotz> chrisccoulson, please don't forget to push the firefox packaging branches, 61.x wasn't pushed either yet
<ricotz> to clarify: rust-cbindgen is the needed one
<ricotz> seb128, https://launchpad.net/ubuntu/+source/rust-fuchsia-zircon-sys/0.3.3-1 looks like a leaf
<slangasek> seb128: we generally use ubuntu-release for such discussions
<seb128> ricotz, k
<seb128> slangasek, right, I think it's fine for now I can keep that discussion for Brussel
<seb128> juliank, could you SRU bug #1790671 to bionic?
<ubottu> bug 1790671 in packagekit (Ubuntu) "/usr/lib/packagekit/packagekitd:11:std::__cxx11::basic_string:AptIntf::providesCodec:backend_what_provides_thread:pk_backend_job_thread_setup:g_thread_proxy" [High,Fix released] https://launchpad.net/bugs/1790671
<juliank> seb128: I will, yes
<seb128> great, thx
<juliank> I'll check xenial too
<juliank> seb128: I need to find out a reproducer, and there's another bugfix to cherry-pick it seems; as well as potentially a fix for packagekit crashing upgrading itself
<juliank> that last one just came in today: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1790613
<ubottu> Launchpad bug 1790613 in packagekit (Ubuntu) "Regression: packagekit crashes updating itself to 1.1.9-1ubuntu2.18.04.1" [Undecided,Incomplete]
<seb128> juliank, I don't think we used that code in xenial, we had aptdaemon/session-installer since
<seb128> since->there
<juliank> possible
<juliank> but if it applies, why bother not fixing it :)
<juliank> If not, I don't really care :)
<seb128> the  e.u.c summary has no report for xenial
<seb128> well, unsure what's the point fixing a bug no user is hitting
<seb128> just waste reviewers/testers time and bandwith
<juliank> that code does not exist anyway
<juliank> also, maybe xenial used the apt backend instead of the aptcc one
<juliank> I don't remember the details :)
#ubuntu-devel 2018-09-05
<acheronuk> tianon: do you happen to know when cosmic docker images are next likely to be updated?
<mwhudson> acheronuk: when either he or i get around to clicking the button
<mwhudson> acheronuk: is there some change you are after?
<mwhudson> ah i guess the new glibc is probably a good reason to update
<acheronuk> mwhudson: Yeah. I have an issue with building Kubuntu CI cosmic container, which could be because glibc mismatch
<acheronuk> 07:04:10 /usr/bin/ruby: relocation error: /lib/x86_64-linux-gnu/libnss_files.so.2: symbol __libc_readline_unlocked version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
<acheronuk> if I start with glibc all up to date, then hoping that goes away!
<mwhudson> hmm
<mwhudson> still sounds like something that shouldn't be happening...
<acheronuk> mwhudson: yeah, but I did not write the .rake and I'm not up to speed enough on docker/ruby to debug. so as said, rather hoping it goes away with upgraded images
<acheronuk> bionic and xenial container still build/deploy fine
<mwhudson> well i've started the process of updating
<mwhudson> will probably have to wait until tianon wakes up to finish though
<acheronuk> mwhudson: thanks. no problem. I'm busy with other stuff a lot of today, so won't look at this again until tonight or tomorrow anyway
<mwhudson> acheronuk: https://github.com/docker-library/official-images/pull/4809
 * mwhudson puts the laptop away
<acheronuk> thanks :)
<abeato> sil2100, hey, so what do you think of https://github.com/CanonicalLtd/ubuntu-image/pull/160 ? regardless of any redesign on how to handle grub.cfg on classic, would you be happy if I change it to remote /boot/grub/* instead of the whole folder?
<abeato> s/remote/remove/
<ricotz> xnox, hi :), meson 0.47.2-1 seems an important package to merge
<LargePrime> Hi, i got a weird question.  it is possible to modify a key mapping of a device at the driver level?  on my own system
<ahasenack> no idea what you mean, nor how it relates to ubuntu development
<LargePrime> ya, i dont know where to ask.  this is my first guess
<LargePrime> ahasenack, I have a mouse and i want to remap its buttons
<LargePrime> the tools and guides I find give remaps that do not survive rebboots, or even replugging the usb device
<LargePrime> So i was thinking to goto a lower level hack
<sladen> LargePrime: use 'udev' to make the change each time the mouse is inserted
<LargePrime> sladen, ya.  I was hoping to hack something at a lower leve, so as to not have to do it each time
<sladen> LargePrime: udev does it for you, every time!
<sladen> LargePrime: much much easier than hacking and recompiling drivers...
<LargePrime> sladen, thanks.  I missunderstood
<sladen> LargePrime: see https://unix.stackexchange.com/questions/65891/how-to-execute-a-shellscript-when-i-plug-in-a-usb-device replies
<ahasenack> tjaalton: hey, is this something you could review? https://salsa.debian.org/sssd-team/sssd/merge_requests/2
<tjaalton> ahasenack: there's noone else either, so..
<ahasenack> tjaalton: you are the sole debian maintainer?
<tjaalton> yes
<ahasenack> happy to help whenever I can
<tjaalton> cool
<tjaalton> cyphermox: hi, there's a patch for grub2 that I need in cosmic for bug 1785033, do you want to handle it or can I?
<ubottu> bug 1785033 in HWE Next "GRUB needs to support 64-bit efi linear frame buffer address" [High,In progress] https://launchpad.net/bugs/1785033
<cyphermox> tjaalton: I'll do it
<tjaalton> cyphermox: thanks. I've uploaded the patch to the t/x/b queue
<cyphermox> tjaalton: if you've already uploaded to the queues, please make sure you also upload grub2-signed.
<seb128> slangasek, I don't remember what you said about the netplan.io autopkgtest regression that is blocking network-manager in cosmic-proposed ... is anyone looking at it? likely this week?
<slangasek> seb128: more likely this week than last
<slangasek> cyphermox: ^^ is the netplan.io autopkgtest failure on your list for this week?
<tjaalton> cyphermox: oh, ok
<cyphermox> slangasek: ok
<cyphermox> tjaalton: change of plans, I'll reupload grub2 in bionic along with grub2-signed
<cyphermox> seb128: won't be done today, but I'm cutting a release I'll address that.
<slangasek> cyphermox: does that mean the current tests are bad, rather than identifying a regression in network-manager, and I should hint around it?
<cyphermox> slangasek: there's a difference in how Networkmanager reports DNS, you can hint around it
<slangasek> ok
<cyphermox> it's not a bad test, it's watching for NM's output, and NM did like systemd-resolved and grew this stupid ~. domain.
<seb128> cyphermox, great, thanks
<cyphermox> AFAICT there's no regression there, the expected "real"  domain is still there.
<dadada> hi
<dadada> please package github.com/browsh-org/browsh/   --- www.brow.sh  --- for Fedora. It's a text-based internet browser using Firefox as the backend.
<dadada> sorry, I mean for Ubuntu :D
<TJ-> dadada: we don't work like that. You'd need to find a package maintainer first, who would do the packaging. Ubuntu imports from Debian so if the package gets into Debian it'll percolate to Ubuntu later
<dadada> TJ-: okay, I think they already tried to get it into Debian, thanks...
<ginggs> dadada: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#NEW_packages_through_Debian
<ahasenack> a snap could be another option, although the firefox dependency might make that difficult to bundle
<TJ-> yeah, it'd have to contain Firefox as well I guess. I like the idea though!
<blackboxsw> sorry for the general/basic question here. I'm about to sponsor my first upload to cloud-init package for rharper. I have upload rights, but I'd like to sponsor He  generated the changeset into cosmic for cloud-init (and is the documented author of record in the most recent debian/changelog that I'll be uploading).    My understanding is that I don't need to do anything special in addition to just reviewing the
<blackboxsw> changeset/approving it and uploading it as is.   Is this correct?
<seb128> slangasek, cyphermox, thanks for unblocking the n-m update!
<blackboxsw> looking over a previously sponsored change of mine. it seems that the changes email generated catalogs who signed the upload (the sponsor) and the author of the changeset (me)  https://lists.ubuntu.com/archives/cosmic-changes/2018-May/002547.html   so I *think* that sponsorship tracking is automatically handled when signed-by != Changed-by
<nacc> blackboxsw: you will need to sign it, to upload it
<blackboxsw> nacc: thanks I actually typed a message to you and nearly submitted as you had sponsored one of my uploads. Thanks will do!
<Unit193> Right, so is it possible to "stage" a sync from Debian, such that it's not yet in proposed but it does trigger autopkgtests?
<nacc> blackboxsw: :)
<nacc> blackboxsw: so often, I will build the unsigned source package locally, then use debsign to sign it before upload.
<blackboxsw> nacc: getting out for any pickup lately ?
<blackboxsw> ultimate that is
#ubuntu-devel 2018-09-06
<juliank> seb128: JFTR (in case you see the regressions now and think they need fixing) I just uploaded a new update-manager to fix the autopkgtest regressions in 18.10.5.
<juliank> The lines introduced by the livepatch message were too long
<juliank> and there was an unused import, but I don't think that was related to the upload, just a new pyflakes test
<seb128> juliank, oh ok, thanks!
<seb128> sorry I sort of force pushed a bit that one since it wasn't getting reviewed by anyone from foundations :)
<juliank> no problem
<ahasenack> hi,
<ahasenack> does anybody know when is the next dmb meeting?
<ahasenack> the agenda at https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda lists dates from the past as the next meeting times
<jbicha> ahasenack: updated :)
<ahasenack> jbicha: thanks
<jbicha> ahasenack: you can add your name back to the agenda with the date you plan to attend
<ahasenack> jbicha: it's less than a week, I thought the next meeting would be on the 17th
<abeato> Sigyn, hey, I added a bug for https://github.com/CanonicalLtd/ubuntu-image/pull/162#pullrequestreview-152846703 - it has failed the "boot" test though in xenial, but I do not think that is related to the changes
<ahasenack> 24th is fine
<ahasenack> there is still one endorsement I'm going after, too
<abeato> Sigyn, oops, that was not for you, but for sil2100 :) sil2100 see above ^^
<sil2100> abeato: thanks!
<sil2100> abeato: yeah, boot can be flaky, sadly
<cpaelzer> doko: I subscribed you on 1791010 in case you might have an idea what in gcc might be responsible for the change
<cpaelzer> let me know if there is anything in particular that comes to your mind that could be tested
<smoser> hey
<smoser> open-iscsi is currently FTBFS, dieing with: undefined reference to `minor'
<smoser> http://paste.ubuntu.com/p/W6R7fPPFcN/
<smoser> https://github.com/hishamhm/htop/commit/c01f40eb3e599f55d408448228d95ecee4b2031f
<Ulfalizer> any recent known startup issues with gdm3? had to switch to lightdm to get my system working again after running an 'apt full-upgrade'.
<Ulfalizer> could share some logs, but thought i'd check first. think this guy might be having the same issue: https://ubuntuforums.org/showthread.php?t=2400466
<Ulfalizer> that script failing is just a symptom though i think
<nacc> Ulfalizer: you might want #ubuntu?
<jbicha> Ulfalizer: there is a fix incoming in a few hours: https://launchpad.net/ubuntu/+source/gdm3/3.30.0-0ubuntu2
<Ulfalizer> jbicha: great, thanks! sent an email to the guy who wrote the script about maybe making it fail more gracefully too.
<LargePrime> sladen, regarding udev, it seems there are lots of problems.  is it that hard to recompile a driver for a mouse?  is it a full dedicated driver, or more of a config file?
#ubuntu-devel 2018-09-07
<cpaelzer> doko: for the bug I'm tracking on float precision I somehow think it might be libquadmath
<cpaelzer> which is enabled in gcc-8
<cpaelzer> what is the best way to have a normal cosmic with gcc-8 just without libquadmath
<xnox> cpaelzer, which arch? cause i thought power has quadmath without needing libquadmath.
<cpaelzer> xnox: well it changes
<cpaelzer> gcc-8 + libquadmath != the results of before
<cpaelzer> even gcc-8 (as in cosmic) and force removing libquadmath makes it work
<cpaelzer> xnox: and yes ppc64el
<xnox> huh
<xnox> interesting
<cpaelzer> and old gcc was compiled --disable-quadmath and such - so it was surely off beofre (lib or not)
<xnox> cpaelzer, just FYI doko is in Manchester today, at GNU Tools Cauldron aka the gcc/binutils/what-not conference
<xnox> slangasek, Laney - is it intentional that https://bugs.launchpad.net/autopkgtest-cloud does not have a bug tracker?
<xnox> how can i report bugs against autopkgtest infra? use autopkgtest ubuntu package?
<Laney> yes it is, use https://launchpad.net/auto-package-testing
<xnox> oh, ok
<xnox> thanks!
<xnox> Laney, started typing bullshit, went to find data to back my claims, failed to find data that proves my narative, gave up.
 * xnox found lots of data to disprove my narative....
<Laney> rubber duckism is a valuable tool
<xnox> Laney, =))) hm? what does "rubber duckism" means? =)
<xnox> you mean like a bug bear?
<cjwatson> https://en.wikipedia.org/wiki/Rubber_duck_debugging
<Laney> It's not strictly what you did, but seems related.
<Laney> :-)
<ogra> lol ... the return of clippy ?
 * juliank uses penguins
<juliank> penguin debugging
<msalvatore> doko: We're getting build failures for armhf when uploading a new version of libgit2 to the security-proposed ppa. I'm able to build for armhf locally and sbeattie was able to build it on cady. Do you have a minute to take a look? Build: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/15336959
<doko> msalvatore: not before Wednesday
<msalvatore> doko: Ok. If you could have a look on Wednesday it would be much appreciated.
<doko> LocutusOfBorg: https://launchpad.net/ubuntu/+source/ldc/1:1.11.0-1 are there any llvm switches to target long-double-128?
<ginggs> LocutusOfBorg: did you know? https://wiki.ubuntu.com/ProposedMigration#Testing_against_a_PPA - you don't have to experiment in the archive ;-)
<LocutusOfBorg> doko, I don't get the question
<LocutusOfBorg> please remove ppc64el and that is all :)
<LocutusOfBorg> unsupported upstream, also debian requested its removal
<LocutusOfBorg> so I can do the necessary rebuilds
<LocutusOfBorg> ginggs, somewhat I tested locally, but I don't know why it is good there
<LocutusOfBorg> I even asked a friend to help me, and we didn't come to understand what this code does:
<LocutusOfBorg> echo "$components" | parallel --gnu --keep-order 'echo -e "\\nRunning {} tests"; SYMFONY_DEPRECATIONS_HELPER=weak phpunit --colors=always --exclude-group network,tty,benchmark,intl-data,functional,composer {} || (echo -e "\\e[41mKO\\e[0m {}" && $(exit 1));' && exit_code=0 || exit_code=$?
<LocutusOfBorg> I don't get if the "exit" is quitting from the whole script or not, it seems not on my laptop, but it does against ppa/autopkgtestsuite
<LocutusOfBorg> doko, btw, ppc64el has no reverse-deps, because the resulting compiler never worked, even to build a simple test hello world
<LocutusOfBorg> so, removing is really the best thing to do
<smoser> autopkg test question.
<smoser> autopkgtest --output-dir=$out open-iscsi -- qemu /tmp/autopkgtest-$rel-amd64.img
<smoser> isn't that supposed to build the binaries? if not... how do i tell it "please build binaries first".
<cjwatson> It only builds the binaries if the test specifies build-needed; otherwise it fetches pre-built binaries from the archive.
<cjwatson> I think the easiest way to override that is to fetch the source package separately and then pass the .dsc to autopkgtest rather than just the source package name.
<bdmurray> didrocks: Could you have a look at bug 1791324 when you get a chance?
<ubottu> bug 1791324 in apport (Ubuntu Bionic) "/usr/share/apport/apport-gtk:KeyError:/usr/share/apport/apport-gtk@598:run_argv:run_crashes:run_crash" [Undecided,New] https://launchpad.net/bugs/1791324
<didrocks> bdmurray: yeah, I have a theory, but I'll read the code more on Monday to validate it
<bdmurray> didrocks: Sounds good, thanks!
<didrocks> yw, thanks for pointing me to the automatically filed bug, one less thing to do (I only looked at it on errors.ubuntu.com when receiving the email)
<smoser> cjwatson: ok.. thank you. i was building from a git branch. so i guess i'll just have to build a dsc file first.
<cjwatson> smoser: You can pass a directory name too
<cjwatson> smoser: Lots of options in autopkgtest(1)
<cjwatson> smoser: (If you meant for 'open-iscsi' to be a directory name, prefix it with ./ as otherwise it'll be interpreted as a source package name)
<smoser> ah! thats it.
<smoser> thank you cjwatson .  crazy. these 2 things are completely different:
<smoser>  autopkgtest --output-dir=../out.d . -- ....
<smoser> and
<smoser>   cd ../ && autopkgtest --output-dir=out.d open-iscsi -- ...
<smoser> and it just did not occur to me that it woudl be the case.
<Saviq> tsimonq2: hey, is it by design that qml-module-qtquick-virtualkeyboard only has the .so for Styles, and not the keyboard itself https://packages.ubuntu.com/bionic/amd64/qml-module-qtquick-virtualkeyboard/filelist ?
<Saviq> what should I do to get the kbd to show up, other than setting QT_IM_MODULE?
<Saviq> now I'm getting an error that the module isn't installed, and unless it's supposed to be preloaded somehow I can't see it in the package?
<Saviq> ah! qtvirtualkeyboard-plugin
<tsimonq2> Saviq: Yep :)
<xnox> cjwatson, are there any specific reasons why openssh, in default config insists on using two sockets to bind to [::]:22 and 0.0.0.0:22 separately, instead of binding to [::]:22 alone in dual v6/v4 mode? especially on hosts that default to such behaviour (/proc/sys/net/ipv6/bindv6only=0)
<xnox> or is this something i should take upstream?
<xnox> (maybe just openssh-portable i guess...)
<slangasek> stgraber: is https://github.com/lxc/lxd/issues/4862 something you would plan to land on stable lxd series?  since bionic ships with 3.0.x, it would be good to have it at least fixed there before changing the behavior of the cosmic images
<cjwatson> xnox: take it upstream, please
<cjwatson> (this has been historically complicated; I haven't thought about to what extent it still makes sense)
<stgraber> slangasek: It's in 3.0.2
<slangasek> stgraber: oh, huzzah
<xnox> cjwatson, ack. just thought i might be missing something obvious.
<xnox> cjwatson, actually, i think i figured the obvious why.... that's the simple way to support any sshd_config's which may have overlapping things.
#ubuntu-devel 2018-09-08
<alkisg> Hi, if I have a clean xorg environment, e.g. plain `xinit`, and I run `python3 -c from gi.repository import Gtk`, then that *launches* dbus
<alkisg> I haven't seen this on other distros, i.e. importing python modules to run programs, I think it's caused by some ubuntu-specific python module
<alkisg> But I don't know about python modules enough to know against which package to file this... so where would I report it? :/
<alkisg> root
<jbicha> alkisg: check if it affects Debian. It it does, I guess report against pygobject there
<jbicha> (I don't understand people's dislike of dbus though)
<alkisg> jbicha: thanks; I checked; it does affect debian. I'll file it against pygobject there then.
<alkisg> I don't mind if dbus is running etc; but in this case it's not, and after importing gtk, my service runs dbus without anyone using it (no child processes), and then systemd even complains about my service not properly terminating, and it needs 1.5 minute to force shutdown...
<alkisg> I.e. chaos with just one innocent import gtk
<xedniv> anyone around with systemd experience can explain what @ service units do?
<xedniv> are they templates of some kind?
#ubuntu-devel 2018-09-09
<sarnold> xedniv: yes, that's it exactly, see e.g. https://fedoramagazine.org/systemd-template-unit-files/ for some examples
<bigon> I booted a ubuntu livecd (loooong time ago that I looked at ubuntu tbh :p) and I was wondering, i see you are using the resolved stub server but you are not using nss-resolved, any reasons for this?
#ubuntu-devel 2019-09-02
<mwhudson> how frequently does launchpad import packages from debian? i can't remember
<alkisg> mwhudson: hi; I'm around in case you need any feedback wrt https://code.launchpad.net/~alkisg/ubuntu/+source/isc-dhcp/+git/isc-dhcp/+merge/371861
<ackk> rbasak, hi, would you mind reviewing https://code.launchpad.net/~ack/ubuntu/+source/django-piston3/+git/django-piston3/+merge/372061 and if you approve sponsor the upload?
<Laney> ddstreet: you might be interested in https://git.launchpad.net/autopkgtest-cloud/log/?h=wip/mojo-juju-2
<Laney> this is something that actual humans can deploy (if they have an Openstack)
<cjwatson> mwhudson: every six hours
<mitya57> sil2100: hi! Please see https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1833536/comments/8 â I think qtbase-opensource-src/bionic-proposed can also be released to -updates
<ubottu> Launchpad bug 1833536 in qtbase-opensource-src (Ubuntu Bionic) "QuiteRSS crashes intermittently" [Undecided,Fix committed]
<Laney> mwhudson: tobikoch: rcj: do you have any feedback on https://paste.debian.net/1098377/ ? we've got image builds failing now because the partial seeds aren't valid so I was trying for a low-enough-risk way of deferring this to the end
<Laney> (untested)
<mwhudson> Laney: sounds sane
<mwhudson> alkisg: aaargh tomorrow i promise
<alkisg> mwhudson: no worries, as long as it makes it for 20.04 :D
<mwhudson> alkisg: that's the sort of time frame i should be able to meet
<Laney> except that the "-n" should be "-z", otherwise the test is inverted :P
<rbasak> ackk: this package is a mess :(
<ackk> rbasak, yeah, hopefully we'll be able to move away from it by transitioning to snaps
<rbasak> ackk: still the same maintenance issues though?
<ackk> rbasak, we have a branch in LP where we track the changes we have from the original pcakage
<ackk> rbasak, so we could switch to that instead, or even include it in maas
<cjwatson> Laney: Is that what's going on with the mysterious i386 failures on https://launchpad.net/~cloud-images/+livefs/ubuntu/eoan/cpc-buildd/ ?
<cjwatson> Laney: (I'm slightly confused because I wouldn't have expected buildd images to have any snaps seeded at all)
<ackk> rbasak, it's unfortunately an abandoned project
<Laney> cjwatson: I think that's a bug that I've incidentally fixed (not in that diff; I noticed it while running the autopkgtest locally)
<Laney> https://git.launchpad.net/livecd-rootfs/tree/live-build/functions#n658 notice the different paths on 658 and 659
<Laney> although maybe that but in a different place, reading the message closely
<cjwatson> Mm, could be
<Laney> probably a missing similar guard somewhere
<Laney> or is "iptables: Bad rule (does a matching rule exist in that chain?)." the actual error?
<Laney> TIL that we use iptables in livecd-rootfs
<Laney> mmm, snap-seed-parse exit(0)s after printing that warning, so it won't be that
<Laney> cjwatson: so the iptables -A failed or something?
<cjwatson> Tobias asked something about that the other day IIRC
<cjwatson> https://irclogs.canonical.com/2019/08/27/%23launchpad-ops.html#t11:00
<Laney> Sounds likely
<cjwatson> But I have no idea how it could be LP's fault
<Laney> any difference that would explain it only happening on i386?
<cjwatson> Not that I know of
<cjwatson> Tempted to just suggest || true-ing the iptables cleanup command because honestly who cares
<Laney> at that point, yes, but if it means that the magic-proxy thing isn't working because the nat rule never got set up
<Laney> maybe you'd want to move the failure earlier somehow
<cjwatson> The only thing I can think of is that the daemon user's uid might have changed, but that seems fairly spectacularly unlikely
<cjwatson> Right, that's definitely possible given that livecd.magic-proxy.log is empty in successful builds
<cpaelzer> rafaeldtinoco: ahasenack: could one of you lend me an eye and confirm that this is nonsense => https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/misc/util_misc.c#L718
<cjwatson> iptables doesn't seem to be displayng any errors though
<cpaelzer> after the assert we can assume expand != NULL, then chunks[i] is set to expand (which as we know is != NULL), and then the check for chunks[i] == NULL should never matter - do you agree?
<ahasenack> that's a lot of #idfefs
<cpaelzer> unless their ASSERT isn't alsways on or so
 * rafaeldtinoco checks
<cpaelzer> hmm yeah, just found that their ASSERT isn't always active
<cpaelzer> depending on the config it could be https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/include/vm_assert.h#L259
<ahasenack> cpaelzer: it's not immediately obvious, there are a lot of assignments to expand before that
<ahasenack> ah, wait, you said something more after the ping
<ahasenack> ok, you are comparing line 718 (assert) with 721 (another check for null)
<cpaelzer> ahasenack: yeah I was wondering if line #722 inside the if could even be reached
<cpaelzer> but since then I found that their ASSERT might be on/off depending on the config, and therefore it can enter the if
<cpaelzer> that was all I wanted to know - sorry for the noise rafaeldtinoco & ahasenack
<ahasenack> rubber duck debugging
<ahasenack> worked flawlessly again
 * rafaeldtinoco glad he helped
<rafaeldtinoco> rofl
<cpaelzer> :-)
<Laney> cjwatson: I've pushed what I have; did you want to add the "|| true" or something before I upload?
<cjwatson> Laney: No, let's see how your changes go I guess
<cjwatson> I may be able to see if I can reproduce anything locally
<Laney> OK
<sil2100> mitya57: I know, I talked with RikMills on -release about that earlier
<cpaelzer> ahasenack: rafaeldtinoco: this might be a rubber duck again - is "static inline" now an error?
<cpaelzer> http://paste.ubuntu.com/p/dfphNffZW6/
<rafaeldtinoco> cpaelzer: welcome to wonderful world of gcc9
<rafaeldtinoco> and its new warnings
<rafaeldtinoco> ive been facing this all previous week
<cpaelzer> I'm ther all day already rafaeldtinoco :-)
<cpaelzer> well in the context it is here https://developer.gnome.org/glib/stable/glib-Miscellaneous-Macros.html#G-INLINE-FUNC:CAPS
<rafaeldtinoco> cpaelzer: https://gcc.gnu.org/gcc-9/changes.html
<rafaeldtinoco> it does not explicitly say its a change
<cpaelzer> so I'd just convert it to "static inline" then
<cpaelzer> lets see if it then still is an issue
<rafaeldtinoco> cpaelzer: its funny because inline is (or used to be) just a hint
<rafaeldtinoco> so static would still make sense
<cpaelzer> well I'd love to see some more error context on this
<cpaelzer> the message doesn't really make sense
<cpaelzer> but since I found that it is deprecated lets follow the advice and replace it
<cpaelzer> maybe it works or at least has a more graspable error then
<rafaeldtinoco> op_query.c:341:2: error: format not a string literal and no format arguments [-Werror=format-security]
<rafaeldtinoco> cpaelzer: ^
 * rafaeldtinoco wrapping gcc with Wno-error 
<rafaeldtinoco> #)
<rafaeldtinoco> i wonder why we didnÂ´t catch errors like this ^
<rafaeldtinoco> in package upload/sync
<rafaeldtinoco> and I do get it now
<rafaeldtinoco> do we copy binaries from one version to another ?
<rafaeldtinoco> cpaelzer: LOL getopt() loops indefinitely in arm64
<rafaeldtinoco> char t = getopt() -> while t != -1
<rafaeldtinoco> t will never be -1 =) compiler does not assume -1 == (char)
<rafaeldtinoco> (for arm64 only)
 * rafaeldtinoco fixing ocfs2-tools upstream
<cpaelzer> yay
<cpaelzer> nice find rafaeldtinoco
<rafaeldtinoco> cpaelzer: similar to the one you found some time ago
<rafaeldtinoco> about overflows in arm64
<rafaeldtinoco> (char) stays 255 forever
<cpaelzer> rafaeldtinoco: you said you fought issues like that last week - any idea why -Wno-error=deprecated-declarations (and some permutations thereof) don't get rid of error: Deprecated pre-processor symbol [-Werror]
<cpaelzer> I'd not want to generally unset -Werror
<cpaelzer> but it seems that is what it wants to tell me ... :-/
<rafaeldtinoco> cpaelzer: whenever this happened to me... debian/rules was overriding somewhere else
<cpaelzer> not here, I see it in the commandline
<cpaelzer> unless it comes before some re-enable
<cpaelzer> ...
<rafaeldtinoco> cpaelzer: try LC_FLAGS directly in rules with -Wno-error=
<rafaeldtinoco> just to make sure =) ive done it
<rafaeldtinoco> export CFLAGS+="-Wno-error=format-security"
<rafaeldtinoco> example ^
<rafaeldtinoco> without "s
<ahasenack> there is a maintainer var  for adding and removing chunks in cflags and friends
<rafaeldtinoco> yep, that was just to check if it would be overridden..
<rafaeldtinoco> not sure if there is as HARDENING option for no-error
<rafaeldtinoco> or you have to specifically add as DEB_CFLAGS (or something like it)
<ahasenack> rafaeldtinoco: cpaelzer: is this a known thing with the mysql8 update?
<ahasenack> + mysql_install_db --no-defaults --user=mysql --datadir=/<<PKGBUILDDIR>>/mysql_db/data
<ahasenack> debian/setup-mysql.sh: 47: mysql_install_db: not found
<ahasenack> that's in the php7.2 build
<rafaeldtinoco> ahasenack: errr, no ?
<rafaeldtinoco> =)
<ahasenack> I was wondering if mysql_install_db was renamed or something
<rafaeldtinoco> first time I see this :\
<rafaeldtinoco> <PKGBUILDDIR>> <- extra < ?
<rafaeldtinoco> ah nm
<ahasenack> no, that's just from launchpad
<rafaeldtinoco> yep
<ahasenack> mysql-server-core-5.7: /usr/bin/mysql_install_db
<ahasenack> let me see if mysql8 has something equivalent
<rafaeldtinoco> i was checking that
<rafaeldtinoco> yep
<rafaeldtinoco> apt-file update here
<rafaeldtinoco> err, looks like it doesnÂ´t
<rafaeldtinoco> mariadb-server-core-10.3 and percona-xtradb-cluster-server-5.7 only
<rafaeldtinoco> i think u found a bug
<rafaeldtinoco> =)
<ahasenack> rbasak: do you recall something about that mysql_install_db binary/script? It doesn't seem to be available in mysql8
<rbasak> ahasenack: yes there's a new way now
<ahasenack> rbasak: known bug in php 7.2, or shall I file one?
 * ahasenack searches quickly
<rbasak> ahasenack: we want to remove src:php7.2 before release.
<rbasak> So not worth fixing?
<ahasenack> I see
<ahasenack> it's in the migration blocking list
<rbasak> See the git repository with patches for examples
<rbasak> bryce: ^ do you have removal in your list?
<ahasenack> bryce is on holiday today
<ahasenack> I don't see a card in the daily board
<ahasenack> rbasak: I'll respond in the mail thread, I see he saw this already
<ahasenack> rbasak: php7.3 started tests now \o/
<ahasenack> mediawiki failed, but just on armhf...
<ahasenack> heh, it's the only one that actually used mysql8
<ahasenack> rbasak: I think a whole bunch of the tests in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php7.3 used mysql-5.7 instead of 8
<ahasenack> checked mediawiki and php-horde-db so far
<ahasenack> those runs are old, from about 3w ago
<ahasenack> they ran before the universe/main dependency issue was solved? I was wondering how they appeared so quickly
<rafaeldtinoco> ocfs2-tools in -proposed is broken BTW (and ocfs2-tools in -stable has defrag broken). working on it.
<ahasenack> rafaeldtinoco: the defrag command is new in this version, btw
<ahasenack> new in 1.8.6, I mean
<rafaeldtinoco> ahasenack: yep, its because of an overflow of a small int (char)
<rafaeldtinoco> in arm64 it does not overflow =)
<ahasenack> rafaeldtinoco: I meant it's not broken in 1.8.5 because it doesn't exist there
<rafaeldtinoco> ahh no, its the service name
<rafaeldtinoco> but i think its on my end, will flag the bug i just created as invalid
<rafaeldtinoco> anytime soon
<rafaeldtinoco> hopefully
<rafaeldtinoco> yep, it was on my end, i missed the 1st quilt patch
<rafaeldtinoco> ahasenack: are u aware of a way to ignore files when using dpkg-source --commit ?
<ahasenack> no, I don't think I have ever used --commit
<rbasak> rafaeldtinoco: you could use --commit and then pop quilt and delete the file from the patch manually if that helps
<rafaeldtinoco> rbasak: quilt pop 1
<rafaeldtinoco> and then refresh ?
<rafaeldtinoco> ah i see, delete from patch
<rafaeldtinoco> [  541.862381] ocfs2: Mounting device (7,0) on (node 0, slot 0) with ordered data mode.
<rafaeldtinoco> [  967.650404] INFO: task defragfs.ocfs2:15546 blocked for more than 120 seconds.
<rafaeldtinoco> [  967.655841]       Tainted: P           O      5.0.0-27-generic #28-Ubuntu
<rafaeldtinoco> [  967.661329] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
<rafaeldtinoco> [  967.666882] defragfs.ocfs2  D    0 15546   5947 0x00000801
<rafaeldtinoco> [  967.672396] Call trace:
<rafaeldtinoco> [  967.677892]  __switch_to+0xb8/0x1a8
<rafaeldtinoco> [  967.683418]  __schedule+0x358/0x998
<rafaeldtinoco> [  967.688882]  schedule+0x30/0x78
<rafaeldtinoco> [  967.694283]  rwsem_down_write_failed+0x144/0x258
<rafaeldtinoco> [  967.699720]  down_write+0x54/0x58
<rafaeldtinoco> ocfs2 is a nightmare
<rafaeldtinoco> anyway, fix works
<rafaeldtinoco> cpaelzer: I believe that DEB_BUILD_MAINT_OPTIONS=hardening=+all,-format
<rafaeldtinoco> would be the appropriate option to handle -Wformat and -Wformat-security options
<rafaeldtinoco> -Wformat and -Werror=format-security options, but that does not seem to be working for GCC9 (just tested), this way I had to export CFLAGS to -Wno-errror=format-security
<rafaeldtinoco> Ill open a bug as soon as this is over
<rafaeldtinoco> (this = my bug)
<mwhudson> oh for heavens sake i need to skip another test in golang-golang-x-tools
<rafaeldtinoco> its skip tests season!
<rafaeldtinoco> cpaelzer: nm, my env CFLAGS is overriding debian/rules one, and it comes from $(dpkg-buildflags --get CFLAGS)
<rafaeldtinoco> so correct way to discard format-security warnings (for now, with GCC9) would be DEB_BUILD_MAINT_OPTIONS=hardening=+all,-format
<rafaeldtinoco> and, unfortunately, there is quite a few popping up here and there.. so not sure if we should go upstream and do small fixes or just get rid of the errors
#ubuntu-devel 2019-09-03
<alkisg> ty mwhudson :)
<cpaelzer> rbasak: sil2100: is there a good way to bring https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1841936 to the SRU team for an evaluation and decision?
<ubottu> Launchpad bug 1841936 in haproxy (Ubuntu Bionic) "Rebuild haproxy with openssl 1.1.1 will change features (bionic)" [Medium,Triaged]
<cpaelzer> It would be a no-change rebuilt, so there is no actual debdiff content to review in this case
<cpaelzer> more the implications it will have as outlined in the SRU template
<cpaelzer> I can upload a rebuild, but taking this as a precedent I wondered if there are other ways to get things onto your queues?
<oysteins> Does anyone know in which package the text for unlocking a LUKS partition is (the "Please unlock [partition]" text that appears on boot)?
<oysteins> Someone suggested cryptsetup-initramfs, but it's not on Launchpad, and the text isn't in the cryptsetup package either.
<Faux> https://codesearch.debian.net/search?q=enter+passphrase&literal=1
<RAOF> cpaelzer: Uploading a no-change rebuild (with bug link in the changelog) is a perfectly fine way of getting it on our queue.
<oysteins> Faux: Wow, thanks. :-)
<cpaelzer> ok RAOF, thanks
<oysteins> The weirdest thing; there's no string "Please enter passphrase for disk %s:" in cryptsetup, cryptsetup-luks or systemd on translations.launchpad.net/ubuntu/eoan
<cpaelzer> oysteins: could it be https://codesearch.debian.net/show?file=cryptsetup_2%3A2.2.0-3%2Fdebian%2Finitramfs%2Fcryptroot-unlock&line=184
<cpaelzer> but you sid it isn't cryptsetup .. hmmm
<oysteins> Hm, no package called cryptroot on Launchpad. There is a package called cryptsetup-initramfs in Ubuntu repos, though.
<rbasak> cpaelzer: I've added it to a list for discussion
<RAOF> oysteins: that's in the cryptsetup source package
<rbalint> RAOF, could you please check this hint for systemd? https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/372181
<RAOF> Hm. We don't still need the ppc64el hint for the old version, right?
<RAOF> When's the next upload (mentioned as âthis hint will be made unnecessary by the next uploadâ)
<rbalint> RAOF, in a few days hopefully, but i'd like to have this migrated without a rebuild because it triggers a lot of tests and rebuilding it would pick up new glibc
<RAOF> Sure. I'm not at a computer right now, so I can't actually merge it, but that seems sane.
<rbalint> RAOF, also the old version is gone from the archive
<RAOF> Right, so you can clean up the badtest line by removing the reference to the old version?
<rbalint> RAOF, could you please merge it later today or i should ping other AAs?
<rbalint> RAOF, exactly
<cjwatson> Laney: Huh, so I figured out what's going wrong with the image build failures from yesterday - iptables in eoan is now effectively nftables, iptables-legacy is there for the older kernel interface, and it all gets a bit confusing when you run the newer version in a container when the host system already has rules set up using the older version.  Trying to work out the exact constraints ...
<cjwatson> tobikoch: ^- FYI this is what you were asking about the other day
<RAOF> rbalint: I can merge it later, before my 9pm meeting ð
<RAOF> rbalint: actuallyâ¦ now that I look at it again, will that actually mark the test as bad? You've dropped the `force-badtest` directive from the start of the line.
<Laney> cjwatson: Huh indeed
<Laney> so I guess it's trying to talk nftables to an iptables-using kernel, which isn't going to work AIUI
<cjwatson> Might be kernel version, might be confusion with existing rules
<cjwatson> Trying to narrow that down with a small pile of VMs on Canonistack at the moment :)
<cjwatson> It doesn't seem to *completely* fail to talk nftables - it seems to add the rule, but in a slightly weird way, and then indeed it can't remove it again
<Laney> I wonder if it'll work, even if you do manage to wangle it so that the rule can be inserted & deleted properly (it was my understanding that you can't mix them, BICBW)
<cjwatson> Even in that case I still want to work out exactly how to detect the situation from livecd-rootfs
<RAOF> rbalint: Bah, also, I can't actually merge it - you're after a release team member, not an AA. Oops!
<rbalint> RAOF, i fixed the the line now
<rbalint> RAOF, ah, i thought you wear that hat, too, thanks for the review then
<rbalint> sil2100, Laney: could you please check this hint for systemd? https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/372181
<cjwatson> On bionic and disco kernels, iptables at least inserts the rule into just the OUTPUT chain rather than all chains in the nat table.  Still can't delete it though
<cjwatson> (Also, on >=bionic kernels, the redirect rule actually works; on xenial it doesn't)
<sil2100> rbalint: looking in a moment
<ahasenack> cpaelzer: are you uploading rafaeldtinoco's ocfs2-tools?
<cpaelzer> ahasenack: I haven't checked mails for a while
<cpaelzer> ahasenack: if he said "please do so then I will"
<cpaelzer> ok seeing the MP update
<cpaelzer> yes I'll do the sponsoring
<ahasenack> thx
<ahasenack> rbasak: the php7.3 excuses page is live, since yesterday's fix for the universe dependencies
<ahasenack> rbasak: but it's showing tests results from early august
<ahasenack> rbasak: they used mysql 5.7, not 8. A few red ones used mysql-8
<Skuggen> ahasenack: Where is that page (I might have input for mysql)?
<ahasenack> Skuggen: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php7.3
<ahasenack> my question is why the tests were apparently run before php7.3 was ready. It was showing "not considered" due to missing dependencies, but that was only fixed yesterday, and the test timestamps that suddently showed up are from weeks ago
<Skuggen> Oh, I had that page up, maybe I just misunderstood the issue
<rafaeldtinoco> cpaelzer: ahasenack: tks
<ddstreet> Laney thnx for autopkgtest-cloud mojo branch link, i had been using master branch, i'll give that one a try deploying :)
<rbasak> ahasenack: I believe the algorithm is that it initially looks for autopkgtest results that match its criteria, and only if they aren't present does it request new runs.
<rbasak> ahasenack: so the logic probably just thinks that the historical results are acceptable.
<ahasenack> rbasak: well, those greens cannot be trusted
<ahasenack> rbasak: the log from early august does show 7.3.8 was used, which is what was uploaded
<rbasak> ahasenack: I believe that if we manually rerun tests, the new ones will be picked up instead.
<ahasenack> so the tests ran before the deps check was resolved
<rbasak> Providing the triggers are correct.
<ahasenack> rbasak: my surprise is that there shouldn't have been "historical results" for 7.3.8, given it had that universe dependency issue we uncovered yesterday
<ahasenack> looks like the tests are run before, and that check just hides them if it fails
<rbasak> ahasenack: I think it's understood that the current infrastructure doesn't really ensure that tests are run with the correct combination of packages but only an approximation
<ahasenack> rbasak: I think all tests need to be re-run. If only those red ones are fixed, it might migrate without having been exposed to mysql-8
<rbasak> ahasenack: that sounds right
<ddstreet> sil2100 hey, minor point re: the new 'autopkgtest regression report' emails, the proposed-migration url link is line-wrapped, making it not clickable, e.g. https://lists.ubuntu.com/archives/ubuntu-sponsors/2019-September/063139.html
<Laney> ddstreet: looks like that's done by pipermail? https://bugs.launchpad.net/cloud-utils/+bug/1836593/comments/4 seems ok to me
<ubottu> Launchpad bug 1836593 in cloud-utils (Ubuntu) "race condition in dep8 test" [Medium,Confirmed]
<ddstreet> Laney ah well that's annoying then, wonder if pipermail has an option to not do that
<ddstreet> Laney if pipermail is just the archiver, then it's earlier than that i think, as it's line-wrapped in my inbox
<Laney> could be
<rcj> cjwatson: I was out yesterday but I'm reading the backlog on the iptables issues in eoan builds.  Looks like the magic-proxy isn't working at all on eoan (based on 0-byte logs) while only i386 fails due to the rule removal failure.  Are you still chasing this down in the builders?
<rcj> Laney: I was out but I see that your livecd-rootfs change causes our builds to fail now for cloud-images because the variable is unset outside the preseeda and we're running with 'set -u'
<Laney> ah man
<Laney> I ran the autopkgtests, guess there isn't one for this case
<rcj> I guess not :-/
<cjwatson> rcj: I'm still chasing it down, yes.  Almost done
<cjwatson> rcj: (none of it is a problem with the builders, incidentally - it's all to do with iptables, although one part of it can sensibly be handled in livecd-rootfs IMO)
<rcj> cjwatson: thank you.  I was worried that you had to put in code to download 0-byte files and you said the magic-proxy log was empty, but it was hard to know what was going on without logs from failed builds (which aren't so helpful anyhow)
<cjwatson> Yeah, it's empty and that is indeed a problem.  I only worked around it because the failure mode was excessively obscure
<cjwatson> rcj: There are two problems: one is that livecd-rootfs needs to run iptables-legacy on old kernels; the other is https://bugs.debian.org/939336 which I just filed
<ubottu> Debian bug 939336 in iptables "iptables: fails to delete rules when running 32-bit userspace on 64-bit kernel" [Normal,Open]
<cjwatson> rcj: The workaround for the first part will avoid the second for now though
<Laney> rcj: https://paste.debian.net/1098560/ ?
<rcj> Laney: that works
<Laney> ok, I pushed that
<Laney> thanks for the heads up
<rcj> Laney: thank you
<rcj> Laney: we'll add a task to get the tests updated
<Laney> neat
<rcj> cjwatson: I'm trying to decide if we should check something in livecd-rootfs to decide which to use or use iptables-legacy unconditionally as builders are the intended environment.
<cjwatson> rcj: I think a kernel version test is closer to being correct, and that's what I'm testing at the moment
<cjwatson> rcj: Testing for whether it's on a builder, or being unconditional, are both incorrect - at some point we'll upgrade build VMs to bionic, and at that point the nft-based iptables works (modulo the i386 bug)
<cjwatson> I haven't narrowed down exactly which kernel versions are too old for the nft-based iptables to work properly, but 4.4 fails and 4.15 works, which is good enough information
<cjwatson> https://paste.ubuntu.com/p/XYhpDQ87p5/ is the patch I'm testing at the moment
<cjwatson> rcj,Laney: Could you review https://code.launchpad.net/~cjwatson/livecd-rootfs/+git/livecd-rootfs/+merge/372203 ?  I've tested it locally and it seems to be behaving itself?
<cjwatson> s/\?$/./
<rcj> cjwatson: That looks good
<cjwatson> Thanks.  Will get that uploaded
<cjwatson> (including Iain's changes)
<cjwatson> Uploaded
<Laney> thanks
<ahasenack> rbasak: php-horde-db (http://autopkgtest.ubuntu.com/packages/p/php-horde-db/eoan/amd64) ran with mysql-8, but that run was with php7.3
<ahasenack> rbasak: the php-defaults run was with with mysql8 too, but php 7.3.6 (not 7.3.8)
<rbasak> ahasenack: that's good at least
<rbasak> So it's not that the tests were skipped entirely
<rbasak> Only the current problem of needing to tweak them to be against the right thing
<ahasenack> rbasak: just talked about it in #ubuntu-release
 * ahasenack -> quick lunch
<tumbleweed> cyphermox: a year ago, you added ubuntu-archive-assistant to ubuntu-dev-tools source, but nothing to actually install it
<tumbleweed> am I missing something?
<cyphermox> not really, I was so far only using that from the git tree; and there's been pushback on having it there
<cyphermox> also, kinda lacking time to look at it :/
<tumbleweed> OK, I'll leave it to languish there
<cyphermox> feel free to remove if it's in the way; I have the code elsewhere too. no clue if people actually use that for proposed migration or MIR review
<cyphermox> (aside from me, I mean)
<choon> test
<sarnold> pong
#ubuntu-devel 2019-09-04
<cpaelzer> doko: I think I found an issue in glibc 2.30 vs python triggering further issues in samba https://bugs.launchpad.net/ubuntu/+source/python3.7/+bug/1842618
<ubottu> Launchpad bug 1842618 in python3.7 (Ubuntu) "python3.7 might need a rebuild against the new glibc 2.30 - fails with stropts define" [Undecided,New]
<cpaelzer> doko: once you are around it would be great if you could let me know if you agree and schedule a python3 rebuild or if it is more complex than that
<cpaelzer> because in case of the latter we might (for now) add some silly but working emergency patch to get samba updated
<cpaelzer> sbeattie: ^^ FYI
<doko> cpaelzer: uploaded
<cpaelzer> uh, ok that seems like a "yes I agree" :-)
<cpaelzer> thanks doko
<RikMills> LP: #1842382 any clue why /proc/self/maps in a live session now shows nothing much?
<ubottu> Launchpad bug 1842382 in vlc (Ubuntu) "vlc won't start; eoan 19.10 ubuntu/lubuntu/kubuntu/xubuntu/ubuntu-mate daily" [Undecided,Invalid] https://launchpad.net/bugs/1842382
<RikMills> cjwatson:
<RikMills> um cyphermox I mean
<RikMills> any clue why /proc/self/maps in a live session now shows nothing much?
<Laney> doko: will look at mhash
<Laney> first I've heard of it though
<Laney> quite an easy one, lucky :-)
<fredldotme> hello, fine folks!
<fredldotme> I'm here on behalf of UBports. We run into an ugly ICE with gcc-5 from xenial and would need some help to get this fixed.
<doko> unlikely
<Laney> doko: there you go
<Laney> nmued it too for good measure
<doko> ta
<fredldotme> the issue we encounter is here: https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1838419
<ubottu> Launchpad bug 1838419 in gcc-5 (Ubuntu) "ICE in emit_block_move_hints, at expr.c:1144" [Undecided,New]
<fredldotme> as I see it doko already fixed the issue on the Debian side with gcc-6.
<rafaeldtinoco> good morning o/
<rbalint> sil2100, what should i press to make bileto trigger autopkgtests? https://bileto.ubuntu.com/#/ticket/3798
<Laney> lander signoff I think
<choon> https://answers.launchpad.net/ubuntu/+source/systemd/+question/683624
<rbasak> xnox: incoming regression-update report: bug 1842651
<ubottu> bug 1842651 in systemd (Ubuntu) "Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70-persistent-network.rules" [Undecided,New] https://launchpad.net/bugs/1842651
<rbasak> Though it looks like the reported version isn't the current one in -updates?
<xnox> rbasak:  yes.
<xnox> hm
<rbasak> I would ask for verification about .28 but I thought maybe better to leave it with you then add another cook.
<rbasak> than
<xnox> rbasak:  that's a valid question, and i did ask that now. I fear this might be regression due to removal of the "retry renaming persistent interfaces" patch that was recently SRUed. Highlight ddstreet RAOF chrisccoulson
<xnox> rbasak:  but also i'm not sure if security update trumped the inflight proposed update or not
<xnox> chrisccoulson:  did https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.28 trump anything?
<chrisccoulson> xnox, it didn't - it's based on the version in -updates
<RAOF> xnox: we worked to get the security update based on that SRU
<xnox> ack
<chrisccoulson> well, it's in updates now - I based it on what was in the proposed pocket to avoid trumping it
<xnox> chrisccoulson:  tah =) so it was a chrisccoulson setup by having a regression in -proposed ;-)
<ddstreet> xnox rbasak i don't think i had anything to do with that, looks like FourDollars drove that change
<xnox> ddstreet:  ack
<chrisccoulson> xnox, RAOF, is this regression important enough for us to need to do a revert? We'd need to do that through the security pocket
<chrisccoulson> I can prepare uploads now if you think it's necessary
<FourDollars> ddstreet: In fact, that commit has been accepted in the git repository before I start to do another bug's SRU.
<ddstreet> FourDollars ok so the commit came from vicamo?  https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=832a06123f7b060b67394fe270123d80c8d7e37b
<FourDollars> ddstreet: Yes
<ddstreet> ok, sounds like we need that removed patch back then (i.e. Revert-udev-network-device-renaming-immediately-give.patch)
<xnox> ddstreet:  but that will then regress the "takes to long to connect to network upon duplicate macs"
<FourDollars> Yes. XD
<xnox> ddstreet:  somehow we need both, or like ignore/filter out duplciate mac nics....
<xnox> ddstreet:  FourDollars: vicamo: the duplicate MAC nics.... am I crazy, or should we simply take those two NICs and automatically create a bond out of them?
<xnox> as that is the intention, no?!
<FourDollars> xnox: Sorry. I don't know much about it. What I SRUed is majorly for https://bugs.launchpad.net/bugs/1740894.
<ubottu> Launchpad bug 1740894 in OEM Priority Project bionic "KEY_RFKILL is not passed to userspace" [Critical,Fix released]
<ahasenack> cpaelzer: so tl;dr for samba wrt opts header? Was a new upload of python done?
<cpaelzer> ahasenack: yes it was done
<cpaelzer> ahasenack: it reached proposed https://launchpad.net/ubuntu/+source/python3.7/3.7.4-4
<cpaelzer> so we can now hit rebuils on samba which I'll do now
<cpaelzer> if all fits as expected it will now build just fine
<cpaelzer> ubt I'll check the header on the new python first
<cpaelzer> oh someone started it already
<cpaelzer> and it builds fine
<cpaelzer> so things are good again
<ahasenack> ok, thx
<cpaelzer> ahasenack: here are the greens https://launchpad.net/ubuntu/+source/samba/2:4.10.7+dfsg-0ubuntu2
<cpaelzer> with the usual slow arm taking a while
<ahasenack> rafaeldtinoco: there is a history of test hints for ocfs2-tools
<ahasenack> rafaeldtinoco: what we could do there is use that skippable check, if arch == s390x
<rafaeldtinoco> ahasenack: yep. im giving a last look at 3 functions dealing with bit shifts
<rafaeldtinoco> and then right after will suggest that
<rafaeldtinoco> if nothing is conclusive
<ahasenack> ok, didn't want you getting into a rabbit hole
<ahasenack> can also do both: skippable, and then work on the bug without a hurry
<rafaeldtinoco> ahasenack: no no, good stuff you got in public bug also
<rafaeldtinoco> true. i was mostly worried if all ocfs2 was broken for s390 ..
<rafaeldtinoco> (because this comes from libocfs2)
<rafaeldtinoco> and if it is, more than skip, we would have to remove the arch
<rafaeldtinoco> thats why I havent decided yet for skip the test
<rafaeldtinoco> lets see :\
<ahasenack> rbasak: hi, I have a versioned build-dep question
<ahasenack> rbasak: libpmemobj(src) has build-dep libpmemobj-dev(>=1.6~), libdaxctl-dev, libndctl-dev
<ahasenack> sorry, let me rephrase
<ahasenack> packages have similar names
<ahasenack> rbasak: libpmemobj-cpp(src) has build-dep libpmemobj-dev(>=1.6~), libdaxctl-dev, libndctl-dev
<ahasenack> the 3 build-deps I listed come from the same source: pmdk
<ahasenack> libpmemobj-cpp is another src
<ahasenack> so
<ahasenack> with libpmemobj-dev 1.6.1 and later, the libdaxctl-dev and libndctl-dev build-deps can be dropped from libpmemobj-cpp
<ahasenack> so we would have only Build-depends: libpmemobj-devel(>= 1.6~)
<ahasenack> the question I got in review is if I shouldn't then update that version, since it's only with 1.6.1 and later that I can drop the libdaxctl-dev and libndctl-dev build-depends
<ahasenack> i.e., isn't this more correct for libpmemobj-cpp(src): Build-depends: libpmemobj-devel (>= 1.6.1~)
<ahasenack> I remember vaguely we talking about something similar in the past, that versioned build-depends shouldn't be that strict in general
 * rbasak reads
<fredldotme> do you think there's a possibility someone at Canonical will take a look at our issue and backport the patch (https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=261588) to gcc-5?
<rbasak> ahasenack: the usual thing I go for is to not use depends (or build depends) for bugfixes, since 1) then things get awkward when bugfixes are backported; and 2) if fixing a bug we update the archive, everything updates and so no dependency is actually required
<rbasak> ahasenack: for build-depends I think it's entirely up to ease of maintenance - if it holds a build back as needed, or will inform a backporter of a problem early, then it's useful
<ahasenack> rbasak: this package in particular (libpmemobj-cpp) only exists in eoan, but the mentioned build-deps go back
<rbasak> Otherwise there's no need.
<rbasak> So I think it's up to you.
<rbasak> (>= 1.6.1~) is correct if you want to express that in the build dependency
<rafaeldtinoco> fredldotme: you mean for Xenial ? why dont u open a launchpad bug and suggest that ?
<rafaeldtinoco> explain why you need that backport and what situation it would solve.
<ahasenack> rbasak: the reason to build-dep on 1.6~, is code-wise. To build-dep on 1.6.1~, is well, the build will just fail without the (now) missing build-deps
<rbasak> ahasenack: right. What I'm saying is: do you wish to express that in the build dependency?
<ahasenack> rbasak: for eoan that would be correct. For < eoan, it would be introducing a bug, because 1.6.1 is not there, and with 1.6, the build-dep is not needed
<ahasenack> not seeing me doing a backport, though
<rbasak> Because almost every unversioned build dependency probably could correctly be versioned with a >=, but we don't do that for everything. There's no requirement to do so, except when it's convenient for us.
<fredldotme> rafaeldtinoco already did: https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1838419
<ubottu> Launchpad bug 1838419 in gcc-5 (Ubuntu) "ICE in emit_block_move_hints, at expr.c:1144" [Undecided,New]
<ahasenack> rbasak: right
<rbasak> fredldotme: do you mean Canonical, or Ubuntu?
<rbasak> fredldotme: Canonical will generally only do things for customers or if there's a big impact to Ubuntu users, since everything else falls off the priority list.
<rbasak> fredldotme: however anybody can contribute to Ubuntu and all are welcome and encouraged to do so.
<rbasak> fredldotme: if you have a patch and would like to drive landing the fix in Ubuntu yourself, see https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1838419
<ubottu> Launchpad bug 1838419 in gcc-5 (Ubuntu) "ICE in emit_block_move_hints, at expr.c:1144" [Undecided,New]
<rbasak> Uh
<rbasak> https://wiki.ubuntu.com/StableReleaseUpdates
<fredldotme> rbasak I see, if someone from Ubuntu would like to help us that would be great. All the information required to get the backport in is in the launchpad bugreport
<rbasak> fredldotme: you'd be expected to work on as much as you can yourself, according to our documented policy and processes.
<fredldotme> rbasak ofc
<rbasak> fredldotme: if you have specific questions about our processes, you're welcome to ask here.
<rbasak> fredldotme: I would start by checking the page I linked to ensure that your proposed patch is acceptable to land according to our policies (which exist to protect Ubuntu users)
<rbasak> fredldotme: your goal would be to get the bug fully documented according to our requirements, and to present us with a debdiff ready for sponsorship.
<rbasak> (and then you'd be expected to help with QA afterwards)
<rafaeldtinoco> AND, for this case, in particular, you said gcc-6 in debian has a fix for the same issue
<rafaeldtinoco> you could even use that patch for the Ubuntu SRU (stable release update)
<fredldotme> that would be my first thing to try, backport the fix to gcc-5 with a PPA up and running, then we can discuss how to proceed with merging the patch.
<ahasenack> rafaeldtinoco: the bug you just filed on crmsh, about parallax
<ahasenack> rafaeldtinoco: I've seen that backtrace before
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/crmsh/+bug/1687095
<ubottu> Launchpad bug 1687095 in crmsh (Ubuntu Xenial) "crm cluster health does not work: python3-parallax and cluster-glue (hb_report) dependencies" [Undecided,Confirmed]
<rafaeldtinoco> ahasenack:i used your previous bug
<ahasenack> oh, wait
<rafaeldtinoco> changed its title to add eoan
<ahasenack> ok, sorry :)
<rafaeldtinoco> so its 2 issues
<rafaeldtinoco> =o)
<ahasenack> you did me a confuse
<rafaeldtinoco> ahasenack:im glad you still remember
<rafaeldtinoco> lol
<ahasenack> (dog speak)
<rafaeldtinoco> fredldotme: to be honest, after checking both build logs
<rafaeldtinoco> how are you sure that the backport would solve your issue ?
<rafaeldtinoco> make sure to test it before, cause its in the same internal (to gcc) function but different issues/failures
<rafaeldtinoco> make sure you explain that also (in the SRU).. having a working PPA would be +1 for the SRU acceptance also
<fredldotme> rafaeldtinoco I was just following the lead from the Debian bug to the upstream gcc patch. it's certainly possible the patch doesn't fix our specific issue, there's only one way to find out: testing it :)
<rafaeldtinoco> fredldotme: yep, I'd bet there are more fixes related to arm64<->armhf cross compiling
<rafaeldtinoco> fredldotme: "tip" you can always use the upstream gcc-5 version, with "debian/" directory from Xenial (without applying the patches from debian/patches/*) and bisect generating pkgs..
<rafaeldtinoco> so lets say from gcc5 to gcc7 this is fixed, you might be able to bisect the upstream source, by generating debian packages and testing, lets say.. just to give an example on what can be done
<rafaeldtinoco> after finding what fixed the issue, you can propose the SRU
<rcj> rbasak and the SRU team: Can I get a review of the test SRU test plan @ https://wiki.ubuntu.com/ec2-hibinit-agent-Updates ?
<rcj> sorry rbasak, that was meant for rbalint ^
<rcj> (happy to have the review, but I flubbed the autocomplete)
<rafaeldtinoco> cpaelzer: alright. so ill drop ocfs2-tools s390 builds and explain in the LP and do a merge request.
<cpaelzer> yeah, I mean all the years it was accepted that it doesn't work there but "kept"
<cpaelzer> yet I'd agree that if it isn't working (and not meant to be working) there then the right thing would be to remove it
<cpaelzer> maybe xnox or jfh have faced that (discussion) before
<rafaeldtinoco> cpaelzer: im putting into a comment, but.. they are basically doing shifts in a (char *) that points to a (void *) and checking addr mask
<xnox> cpaelzer:  que que?! more context =)
<rafaeldtinoco> xnox: ocfs2-tools s390
<rafaeldtinoco> you are aware of that already
<cpaelzer> it doesn't work on s390x, and AFAIK it never did
<rafaeldtinoco> anything against removing from s390 ? as libocfs2 is broken
<cpaelzer> it was force-badtest all the time
<cpaelzer> but I'd agree that if it doesn work then there should be no s390x biary for it
<rafaeldtinoco> ocfs2_set_bit does little endian operations only (for masking addresses of the inode bitmaps)
<ahasenack> some tests pass, I guess there was hope it would soon fully work
<xnox> cpaelzer:  rafaeldtinoco: ideally it would have a unittest and the package is attempted to build, but ftbfs
<ahasenack> or maybe some portions of it work
<cpaelzer> xnox: wouldn't that prevent the other architectures from entering proposed?
<rafaeldtinoco> xnox: bitwise passes.. test fails because asserts() fail (since bitwise are little endian aware only)
<rafaeldtinoco> building is ok, logic is broken
<xnox> such that it doesn't produce binaries, but like attempts to do that, and like all the time.
<xnox> cpaelzer:  it will be fine.
<xnox> cpaelzer:  we will need AA to remove debs from release pocket, and everything will be fine from then on.
<xnox> cpaelzer:  as it wouldn't be a regression in arches support from then on.
<cpaelzer> yeah if that works I'm ok with that approach
<cpaelzer> rafaeldtinoco: do you think such a unit test would be easy to add?
<xnox> rafaeldtinoco:  that's what i'm saying, add a build time unit test which shows this broken logic and fails.
<rafaeldtinoco> https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1745155/comments/4
<ubottu> Launchpad bug 1745155 in ocfs2-tools (Ubuntu) "o2image fails on s390x" [Medium,Confirmed]
<rafaeldtinoco> definitely
<rafaeldtinoco> i could check if arch is big endian by checking 0xfff0 to 0x0fff
<rafaeldtinoco> DEB_BUILD_ARCH_ENDIAN or just check that
<rafaeldtinoco> or DEB_HOST_ARCH_ENDIAN or DEB_TARGET_ARCH_ENDIAN
<cpaelzer> rafaeldtinoco: could we test this ocfs2_set_bit ?
<rafaeldtinoco> but if all big endians are broken
<rafaeldtinoco> cpaelzer: yep
<rafaeldtinoco> I can create this
<rafaeldtinoco> do a ocfs2_set_bit like test
<cpaelzer> not like "if big endian then die", but really call ocfs2_set_bit adn check against a expected value or so?
<rafaeldtinoco> sure
<cpaelzer> yep
<rafaeldtinoco> ill add a DEP8 about this then
<rafaeldtinoco> should I fail build ?
<rafaeldtinoco> or just the test ?
<rafaeldtinoco> (are we removing it from s390x still ?)
<cpaelzer> rafaeldtinoco: it must be a build time test, not a dep8
<rafaeldtinoco> perfect
<cpaelzer> otherwise it won't work out the way xnox and I discussed
<cpaelzer> xnox: btw while I always trust your advice, could you outline in a few words why this is better than Architceture: !s390x in d/control ?
<cpaelzer> for spotting when it ever starts to work?
<xnox> cpaelzer:  there is no way to declare !s390x, only explicit list of arches..... which is pain to maintain as whitelist especially when we are going to add more arches
<cpaelzer> ok, that is a reason
<cpaelzer> thanks
<marcoceppi> fginther`: ð I've spent a bit of time with livecd-rootfs - grabed the latest from git, built and installed it. I set what I assume are the correct parameters and did a `lb config` and `lb build`. I'm just not sure what the result of that is, as none of files resemble that which is foud at cdimages for rpi3 images
<smoser> rafaeldtinoco: around ?
<smoser> https://bugs.launchpad.net/cloud-utils/+bug/1842682 :-(
<ubottu> Launchpad bug 1842682 in cloud-utils "regression in test-growpart results in test fail device or resource busy" [High,Confirmed]
<rafaeldtinoco> yep, next in my queue
<smoser> sorry
<rafaeldtinoco> nah, i saw it yesterday
<smoser> humans (at least smoser) are so incompetant
<rafaeldtinoco> tks for the headsup!
<rafaeldtinoco> today is the ocfs2-tools s390 fun :\
<fginther`> marcoceppi, I wasn't aware you were going to try to build images from scratch with livecd-rootfs, just modify an existing image. We actually use a helper utility to build with livecd-rootfs: https://github.com/chrisglass/ubuntu-old-fashioned
<marcoceppi> fginther`: Oh, then I'm not sure how to modify an existing image
<fginther`> marcoceppi, that project is essentially a single bash script which does the setup and execution of a build
<marcoceppi> I'm happy to build from scratch or modify
<smoser> rafaeldtinoco: i'm just going to do an upload to eoan with that in it
<smoser> thanks to rharper for quick review
 * tribaal notices the highlight.
<tribaal> hi all :)
<marcoceppi> whichever you think would be the most sane fginther`
<fginther`> hey tribaal :)
<rafaeldtinoco> smoser: awesome, I can include the fix in the SRU
<rafaeldtinoco> if you are ok
<smoser> yeah.
<smoser> i'd let it get through an autopkg test though ;)
<rafaeldtinoco> +1
<fginther`> marcoceppi, since you're already down the build from scratch path. I suggest to continue. The ubuntu-old-fashioned has some assumptions about which livecd-rootfs project to build (it defaults to the cloud builds). The rpi3 builds will be under a different project
<marcoceppi> I'll take a look! thanks
<bdmurray> rbasak: Are you familiar with sphinxsearch at all?
<bdmurray> rbasak: I've discovered the answer to my question
<ahasenack> bdmurray: is he familiar or not? :)
<bdmurray> ahasenack: okay, I've discovered the answer to my original question! ;-)
<ahasenack> :)
<tarzeau> if a gui app creates a window, that window should be movable independant of the main other window. i wonder who came up with the idea to let the main window move with the sub window. braindead! QT5!
<tarzeau> can i turn that crap off somehow?
<marcoceppi> fginther`: hey - thanks for your help. I'll be authoring up a blog post about what it took, but in short I was using the wrong IMAGEFORMAT parameter. Needed `ubuntu-image` instead of `ext4`
<fginther`> ah, glad to hear! :)
<fginther> marcoceppi, I'd be interested in reading that post if you're willing to share :)
<marcoceppi> fginther: hopefully next week, depends on how far I get in baking in my changes needed for deployments
<CarlFK> marcustomlinson: long shot based on  "deployments" -  https://debconf-video-team.pages.debian.net/ansible/usb_install/usb_quick_start.html
#ubuntu-devel 2019-09-05
<tjaalton> LocutusOfBorg: hi, filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939472 about llvm-9, do you have an idea what's missing?
<ubottu> Debian bug 939472 in llvm-9-dev "libclangCodeGen.a: error adding symbols: archive has no index" [Normal,Open]
<GunnarHj> vorlon: Wondering if you noticed bug #1800794. In short we have an Ubuntu specific bug in the dispatcher, since we use an own C program instead of upstream's TCL script. I have talked with cyphermox, and it looks like there is no time/interest to maintain that program today. He also let me know that you were involved in the decision many cycles ago to go that route. The direct question I have is in the latest comment in the
<GunnarHj> bug report.
<ubottu> bug 1800794 in usb-modeswitch (Ubuntu) "usb-modeswitch can't apply Configuration=0 to Snapdragon X12 LTE" [Medium,In progress] https://launchpad.net/bugs/1800794
<doko> coreycb, cpaelzer: postfix ftbfs in eoan
<doko> coreycb, cpaelzer: xen ftbfs in eoan
<ahasenack> doko: link for the postfix one?
<doko> ahasenack: eoan-proposed
<ahasenack> the glibc rebuild
<ahasenack> sil2100: hi, there is no test case in https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1756595
<ubottu> Launchpad bug 1756595 in apport (Ubuntu Disco) "disk space info inadvertently provides all installed snaps" [Undecided,New]
<cpaelzer> doko: lets tell xen to smb ^^
<cpaelzer> IIRC that was sort of bad already last time he checked
<cpaelzer> All my involvement in it are my efforts to demote it some day :-)
<ahasenack> doko: wrt postfix, http://postfix.1071664.n5.nabble.com/build-failure-with-glibc-2-30-td102511.html
<cpaelzer> fixed in 3.5 is a bit late foe Eoan
<cpaelzer> ahasenack: do you know (or look for) isolated fixes or do you already know that there are massive reworks that are needed?
<ahasenack> cpaelzer: I'm looking for them
<ahasenack> 3.5 isn't even released upstream yet
<cpaelzer> pff, great
<cpaelzer> the discussion read like "why are you so outdated to not be on 3.5" but knowing that 3.5 isn't released yet ....
<ahasenack> cpaelzer: doko: it's in here: https://github.com/vdukhovni/postfix/commit/3274c3cea9d739f86e84b65664aabb692e37e83f
<ahasenack> https://github.com/vdukhovni/postfix/commit/3274c3cea9d739f86e84b65664aabb692e37e83f#diff-777bfb681a1cd539ddc8e1e606959ffa mor specifically, haven't checked if the other hunks are needed
<ahasenack> that is not an official postfix git repo, there isn't one publicly available
<ahasenack> this is just Viktor pulling in changes from wherever
<ahasenack> I think via tarball snapshots even
<ahasenack> that wietse releases periodically
<LocutusOfBorg> tjaalton, we are discussing on #debian-llvm right now
<LocutusOfBorg> I guess the fix is to use llvm-8
<LocutusOfBorg> cpaelzer, would you mind trying virtualbox 5.2.12?
<cpaelzer> LocutusOfBorg: I can do that later today (that bug is a private effort of mine)
<cpaelzer> LocutusOfBorg: is there a benfit we expect in adding 5.2.12 to that list of known good/bad ?
<rbasak> cpaelzer, ahasenack, Skuggen, bryyce: I'm preparing a minor version bump of MySQL 8 in Eoan. That won't cause any issues will it?
<cpaelzer> LocutusOfBorg: as we know <=18 good and >=20 bad, do you expect 5.2.12 might be special in that regard?
<cpaelzer> rbasak: you will actually trigger the right tests this time
<rbasak> That was my thinking.
<cpaelzer> rbasak: so you might not cause new problems, but might trigger hidden old ones
<rbasak> But I thought I'd check so as not to interfere with any other efforts
<cpaelzer> I think this is a case where you could use a bileto ticket
<cpaelzer> you would be able to trigger all the same tests without dirsturbing anyone
<rbasak> cpaelzer: what would be the benefit of doing that over doing it in the archive?
<rbasak> We need to make the bump anyway
<cpaelzer> ah ok then
<cpaelzer> the benefit for me sometimes is to be able to work on my own crap without entangling my upload with anyone elses
<doko> RAOF: there are MIRs missing for mir ...
<doko> libxml2.6++
<ahasenack> doko: cpaelzer: I'm picking postfix then, if there are no objections
<ahasenack> unless someone started it already
<cpaelzer> ahasenack: ok for me
<cpaelzer> ahasenack: but if you are busy with motd or others let me know and I'll try to give it a shot
<ahasenack> k
<cpaelzer> I can punt some other things to tomorrow if needed
<doko> ahasenack, cpaelzer, coreycb: mecab-ipadic wants to promote, there already is an approved MIR, but no package subscriber
<doko> ... for mysql-8.0
<cpaelzer> doko: that was mysql
<cpaelzer> yeah
<cpaelzer> we will sort out the subscription as soon as powersj is online
<cpaelzer> and ping you then
<cpaelzer> thanks for the reminder doko
<cjwatson> Is anyone looking at the MIRs needed for the new version of lintian?
<cjwatson> (It blocks the latest man-db for autopkgtest reasons)
<cpaelzer> I have not seen any MIRs incoming yet cjwatson
<doko> yes, promoted one package, and wrote a pseudo MIR for the others, and pinged cyphermox
<cpaelzer> wow, was that just the last few hours doko
 * cpaelzer needs to recheck his inbox ...
<tjaalton> LocutusOfBorg: well, I'm trying to move to llvm-9..
<tjaalton> for debian-experimental, then eoan
<tjaalton> it's not super urgent
<LocutusOfBorg> cpaelzer, sorry I mean 6.0.12
<LocutusOfBorg> and yes, it has some audio related fixes
<doko> tjaalton: https://launchpad.net/ubuntu/+source/xorg-server/2:1.20.5+git20190820-0ubuntu2/+build/17524450
<cpaelzer> LocutusOfBorg: sure I can try that later then ...
<tjaalton> doko: needs fe4cd0e7f5c58fa it seems
<tjaalton> and some others
<tjaalton> nope, just that
<tjaalton> compiler.h: Do not include sys/io.h on ARM with glibc
<LocutusOfBorg> tjaalton, sorry I don't really know...
<LocutusOfBorg> I hope upstream llvm will figure it out
<LocutusOfBorg> I just discovered that the llvm-dev package was 250MB
<LocutusOfBorg> so I got worried
<tjaalton> yeah I noticed the same
<jankoprowski> Hello. I have one question. What are advantages of pbuilder over building in docker image?
<doko> Laney, desktop: https://launchpad.net/ubuntu/+source/mozjs60/60.2.3-4build1/+build/17523444 ftbfs
<Laney> ok, can you file a bug?
<Laney> rls-ee-incoming, it'll get assigned that way
<rbasak> jankoprowski: if you want a reproducible build, you're best off using the build system that your distribution uses.
<rbasak> Otherwise in edge cases you'll get different behaviour.
<rbasak> That's always a risk but you can minimise that by building the same as others.
<rbasak> For Ubuntu, that's sbuild rather than pbuilder.
<jankoprowski> rbasak I'm compiling rust source code and put binary into deb. Anything I should be aware of?
<jankoprowski> rbasak also should I commit "debian" directory into source code?
<rbasak> jankoprowski: well those are different questions and I don't have good answers, sorry. This channel is for development of Ubuntu itself. If you want help developing your own non-distribution packages, you're not in the right place. Maybe try askubuntu.com.
<jankoprowski> rbasak - Thank you :)  I will try there.
<ahasenack> cpaelzer: doko: dep8 green, build green, but the non-intel arches haven't even started to build yet: https://code.launchpad.net/~ahasenack/ubuntu/+source/postfix/+git/postfix/+merge/372342
<sil2100> ahasenack: yes, I know - it was something I was in contact with Julian about on Monday, we discussed the fix and he said he'll update the test case in the nearest time
<sil2100> Reminded him about it right now
<ahasenack> sil2100: thanks
<sil2100> I should have left a note regarding that
<powersj> cpaelzer, doko ubuntu-server is now subscribed to mecab-ipadic
<cpaelzer> thanks powersj
<doko> powersj, cpaelzer: promoted
<powersj> doko, thanks
<cpaelzer> ahasenack: I'll look at the postfix MP between calls
<ahasenack> cpaelzer: I got a ping from Scott K. to submit it to debian and he can apply it then, and then we can sync
<ahasenack> if that's the only change he will add, then it's fine to sync
<cpaelzer> sounds even better
<rbasak> bryyce: https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/869017
<ubottu> Launchpad bug 869017 in linux (Ubuntu Zesty) "Ubuntu server enables screenblanking, concealing crashdumps (DPMS is not used)" [Undecided,Fix released]
<bryyce> rbasak, ah interesting, screen blanking issues are always fun
<bryyce> rbasak, but I think this is a regular video driver bug.  I got a nifty cool 6-output radeon card, and I'm sure it's sufficiently obscure to trip misc. X bugs.
<rbasak> ack
<rbasak> I didn't realise you were doing X.org things
<ahasenack> doko: can you wait a couple of days on the postfix ftbfs fix? Debian is willing to take that patch, even though they don't have that glibc yet, and this would avoid adding a delta to the postfix package
<ahasenack> if not, then I can upload ours, and sync from debian later
<ddstreet> juliank when you get in, i'd like your opinion on lp #1842947, it seems to me like a potentially serious problem with any native package that carries a 'configure' file
<ubottu> Launchpad bug 1842947 in dpkg (Ubuntu) "dpkg 1.19.0.5ubuntu2.2 build did not recreate 'configure' file, losing changes in 'configure.ac'" [Undecided,New] https://launchpad.net/bugs/1842947
<cjwatson> really not a problem with any package.  it'll be specific to dpkg's debian/rules
<cjwatson> it's relying on a make target for configure to call autoreconf *shrug*
<ddstreet> cjwatson removing that doesn't change anything
<cjwatson> I would not expect *removing* it to help!
<ddstreet> er, so you mean all native packages with configure files need to have special d/rules entry to make sure configure is recreated?
<cjwatson> changing "configure:" to "configure: configure.ac" might help, but really it ought to be rewritten to just use dh_autoreconf
<cjwatson> nativeness has nothing to do with anything
<ddstreet> cjwatson that won't help either if configure.ac is newer than configure
<cjwatson> wrong
<ddstreet> make doesn't check timestamps?
<cjwatson> dpkg is just using an obsolete style of regenerating configure; there's no need to overgeneralise this
<cjwatson> you have it backwards
<cjwatson> "configure: configure.ac" means consider configure out of date if configure.ac is newer
<ddstreet> cjwatson sorry i meant it backwards - if conjfigure is newer than configure.ac
<cjwatson> still, the correct approach would be just to use dh_autoreconf
<cjwatson> s/correct/modern/
<ddstreet> well that's good, at least it's confined to just dpkg
<cjwatson> anything using dh(1) and compat level 10 or above does that automatically; dpkg uses compat level 11 but it calls debhelper commands by hand rather than using dh
<ddstreet> cjwatson so dh_autoreconf will call autoreconf -v -i ?
<cjwatson> by default it runs autoreconf -f -i.  this is configurable by the package - see dh_autoreconf(1)
<ddstreet> aha, perfect, that's one suggestion i put in the bug
<ddstreet> use -f
<ddstreet> ok i'll just fix dpkg then, hopefully nothing else tries to manually run autoreconf
<cjwatson> the problem here isn't lack of -f AFAICS, it's just that autoreconf wasn't being run at all
<ddstreet> without -f
<ddstreet> er, no, autoreconf without -f won't rebuild configure if it's newer than configure.ac
<ddstreet> i just checked
<ddstreet> -f is definitely needed
<cjwatson> I'm not saying it's not needed, I'm saying that just adding -f doesn't help if autoreconf isn't called :)
<ddstreet> well, sure :)
<ddstreet> thnx!
<cjwatson> (in fact configure and configure.ac have equal mtimes in that dpkg source tarball)
<doko> ahasenack: no worry, I was just pointing to the ftbfs in main
<ahasenack> ok
<teward> does anyone know if there's an ETA on Thunderbird 68 being available in the repositories including for Bionic?  Because *some* update to Thunderbird in Bionic broke the ability for Enigmail to function properly, so I have to run a from-source Thunderbird 68 separately, and it's not kind to do that (because different TBird profiles)
<rcj> Could I get an Ubuntu Core dev to sponsor livecd-rootfs uploads for bug #1837254 (livecd-rootfs SRU)?
<ubottu> bug 1837254 in livecd-rootfs (Ubuntu Disco) "ubuntu-cpc parallel builds produce unused files" [Undecided,New] https://launchpad.net/bugs/1837254
#ubuntu-devel 2019-09-06
<RAOF> Grargh. How is libxml++ not already in main ð¿
<robert_ancell> RAOF, did you complete LP: #1837700 or did it get automatically completed by the security upload?
<ubottu> Launchpad bug 1837700 in HWE Next "Dell system takes a long time to connect network with external dock" [Undecided,New] https://launchpad.net/bugs/1837700
<RAOF> robert_ancell that SRU for released, yes.
<RAOF> Then the security upload went Bachelor immediately afterwards
<robert_ancell> RAOF, did anyone check the autopkgtest failures?
<RAOF> Yes. I resolved them all.
<robert_ancell> OK, good :)
<RAOF> (mostly by hitting the retry button until they passed, a couple by badtest-ing gvfs ð)
<robert_ancell> Shame there wasn't a test for the regression :/
<RAOF> Indeed
<RAOF> That said, we knew that regression was possible.
<RAOF> We just didn't think anyone would hit it.
<robert_ancell> ah
<robert_ancell> RAOF, you might know this - chrisccoulson said the fix should be uploaded via the security pocket in LP: #1842651
<ubottu> Launchpad bug 1842651 in systemd (Ubuntu) "Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70-persistent-network.rules" [Critical,In progress] https://launchpad.net/bugs/1842651
<robert_ancell> Is that just a matter of updating debian/changelog?
<RAOF> (because that mechanism had been deprecated since 2015(?) and we'd had automatic migration off it for a while)
<RAOF> I'm not sure. I *think* it is just a matter of updating the changelog, though.
<RAOF> I don't know if security goes through a private -proposed equivalent?
<robert_ancell> I always thought it did the old thing, i.e. straight to users.
<robert_ancell> That's a job for Monday I think.
<robert_ancell> Oh, I think I understand why Chris said it should go though security - it means everyone got that update, regardless of it they have updates enabled. So you want the fix to go through the same priority.
<robert_ancell> Though if only a minority of users are hitting it, they'll probably be happy to update for the fix.
<robert_ancell> Using debs feels so clumsy after using Snaps for managing things like this.
<cpaelzer> jamespage: the dpdk fix for 1841759 is in Debian and synced to Ubuntu now
<cpaelzer> jamespage: it is still building, but later today you should be able to push the OVS upload you were preparing
<cpaelzer> https://launchpad.net/ubuntu/+source/dpdk/18.11.2-4
<chrisccoulson> ah, I missed robert_ancell
<doko> jamespage, cpaelzer: swift wants to promote again. is this expected?
<jamespage> doko: yes xnox re-seeded it as we've switch to py3
<doko> jamespage: do all packages still have bug subscribers?
<doko> apparently yes, promoting
<jamespage> it was only unseeded
<jamespage> we never intended not to support it :)
<cpaelzer> jamespage: fully arrived in proposed, you can build OVS if you want
<jamespage> cpaelzer: already uploaded with a versioned BD
<cpaelzer> ok, great
<doko> jamespage, cpaelzer: https://launchpad.net/ubuntu/+source/liberasurecode/1.6.1-2/+build/17285632
<rbasak> Are there any good examples of conditionally applying quilt patches at build time based on a build time check in debian/rules?
<rbasak> For mysql-workbench Debian are adding a bunch of patches for MariaDB and they break the build with MySQL.
<rbasak> So I'd like for us to send up to Debian a patch that checks and only applies the patches when building against MariaDB.
<doko> xnox, Laney: deja-dup now depends on duplicity, but this one ftbfs on ppc64el now
<xnox> doko:  yes.... i did notice this on #ubuntu-desktop.
<xnox> doko:  imho, whilst upstream is trying to fix this, it is best to remove duplicity on ppc64le from the release pocket
<xnox> (there are two bugs open about test suite regressions on ppc64le)
<xnox> doko:  and deja-dup on ppc64le probably too.... as otherwise it will be uninstallable.
<xnox> would need ubuntu-mate-desktop refresh too.
<ddstreet> juliank cjwatson if you have time to peek at my patch to dpkg here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939516  it's not in debian yet, but I'd like to push it into eoan and sru for the dpkg zstd regression (lp #1842947)
<ubottu> Debian bug 939516 in dpkg "dpkg: debian/rules 'configure' rule does not always recreate configure file" [Normal,Open]
<ubottu> Launchpad bug 1842947 in dpkg (Ubuntu Eoan) "dpkg 1.19.0.5ubuntu2.2 build did not recreate 'configure' file, losing changes in 'configure.ac'" [Medium,In progress] https://launchpad.net/bugs/1842947
<ddstreet> but i'd prefer not to push to eoan before debian accepts it, without agreement it makes sense to do so
<juliank> ddstreet: looks ok
<juliank> ddstreet: I'm not sure it's what guillem wants for upstream, but um, I guess you'll see eventually
<ddstreet> lol yes :)  i'll defintely watch the debian bug in case he prefers something different
<ddstreet> thanks!
<cjwatson> looks OK
<doko> xnox: duplicity still depends on python-lockfile
<doko> RikMills: any idea about https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/p/plasma-framework/20190906_060041_bb836@/log.gz ?
<doko> tjaalton: could you have a look at https://launchpadlibrarian.net/440414264/buildlog_ubuntu-eoan-armhf.xosview_1.21-1build1_BUILDING.txt.gz ? same issue like the xserver ftbfs
<doko> same with xserver-xorg-input-mouse xserver-xorg-input-keyboard
<RikMills> doko: the history shows me identical fails followed by passes on a retry on the same trigger, so looks like that test has become 'flaky'
<tjaalton> doko: yeah, next week
<xnox> doko:  argh! will check/fix, but not today.
<rcj> vorlon: I see you're on the SRU rotation for today.  Could you look at the SRU exception @ https://wiki.ubuntu.com/ec2-hibinit-agent-Updates
<vorlon> rcj: that's not fair, you didn't highlight the SRU vanguard the other day when you asked for this and I ignored it hoping someone else would take it! :)
<vorlon> (or maybe you did, looking at the logs... but anyway :)
<vorlon> fwiw I wouldn't have considered review of a proposed SRU exception to be a vanguard task as these typically will want a single member of the SRU team taking it up and driving it, and it is likely to be a multi-day thing
<vorlon> but ok, I'll have a look
<rcj> vorlon: I can take it to an SRU team member early next week.  Someone may have erroneously pointed me at vanguard for this task.
<rcj> vorlon: and this one I sent to the mailing list but didn't hear anything.  What I asked for on IRC was uploads for the livecd-rootfs SRU, which I now have someone in mind to ask.
<vorlon> rcj: could you add an "SRU template" Ã  la https://wiki.ubuntu.com/walinuxagentUpdates to https://wiki.ubuntu.com/ec2-hibinit-agent-Updates ?
<rcj> vorlon: Sure, I can do that.  I happened to copy from one that didn't have that.  I'll name and shame https://wiki.ubuntu.com/gce-compute-image-packages-Updates to ask if that needs an update as well.
<rcj> ;)
<vorlon> I'm not in a hurry to go back and update older exceptions
<rcj> okay, just figured I'd mention it because it's a package I know well.
<rcj> vorlon: I've updated https://wiki.ubuntu.com/ec2-hibinit-agent-Updates with the SRU template
<vorlon> rcj: thanks, approved & added to https://wiki.ubuntu.com/StableReleaseUpdates
<rcj> vorlon: thank you for the review
<rcj> vorlon: the link on the page is a bit wonky
<rcj> mind if I fix it?
<rcj> nm, fixed it.
<vorlon> rcj: ack
#ubuntu-devel 2019-09-07
<doko> jamespage, coreycb: just as a heads up for openstack ftbfs ... https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190906-eoan.html
<oysteins> The wrapper script debian/initramfs/cryptroot-unlock contains texts that are not translatable (at least I cannot find cryptroot-unlock on translations.launchpad.net). An example is this text (shown upon boot when disk has LUKS encryption): "Please unlock disk $CRYPTTAB_NAME"
<oysteins> Can I report this as a bug?
<juliank> hey, who synced keepassxc without a FFe?
<juliank> I added a block-proposed bug 1843143
<ubottu> bug 1843143 in keepassxc (Ubuntu) "Needs FFe" [Undecided,New] https://launchpad.net/bugs/1843143
<juliank> ugh, it's already in release
<juliank> ah, damnit LocutusOfBorg
<juliank> Don't sync new major upstream releases without a FFe
<juliank> also, help appreciated, the clipboard tests are flaky, they are run in xvfb-run, and copying stuff to clipboard fails like 10% of the time
<LocutusOfBorg> juliank, sorry must have been a mistake, can I revert?
<LocutusOfBorg> I can upload an ubuntu1 that is the previous version so we are happy?
<LocutusOfBorg> I syncd some python2 removals and probably I got trapped by some mistake while parsing output...
<juliank> LocutusOfBorg: Or I file a FFe retroactively and then get it decided?
<juliank> I did want to file a FFe, but I did not get around to it yet
<juliank> Worst case, we revert if FFe is rejected
<juliank> I repurposed the bug for that
<LocutusOfBorg> as you wish, in the meanwhile I upload the old version in my ppa so I can copy it to eoan if needed
<LocutusOfBorg> juliank, do you happen to understand where they come from such packages? e.g. node-hapi-teamwork
<LocutusOfBorg> https://buildd.debian.org/status/fetch.php?pkg=node-sntp&arch=all&ver=3.1.2-2&stamp=1567681310&raw=0
<LocutusOfBorg> of course ubuntu is dep waiting on them...
<juliank> LocutusOfBorg: what  do you mean?
<juliank> what is they?
<LocutusOfBorg> juliank, node-sntp build-depends on node-hapi-teamwork
<LocutusOfBorg> but node-hapi-teamwork doesn't exist
<LocutusOfBorg> at least according to rmadison
<LocutusOfBorg> https://codesearch.debian.net/search?q=node-hapi-teamwork&literal=1
<LocutusOfBorg>  Provides: node-hapi-b64 (= 4.2.1), node-hapi-bounce (= 1.3.1), node-hapi-hoek (= 8.2.2+~4.2.1+~1.3.1+~3.3.1-2), node-hapi-teamwork (= 3.3.1)
<LocutusOfBorg> got it
<LocutusOfBorg> its a provide
<adrian15> Should I open a bug so that grub-efi-amd64-signed-template 2.04-3 version gets ported into Ubuntu? Or will it eventually ported into Ubuntu and I should not rush it ? Thank you.
<adrian15> * from Debian
#ubuntu-devel 2019-09-08
<Eickmeyer> cyphermox: If you're available, I have updated slideshow images and text for ubiquity-slideshow-ubuntu. bug 1843196 has everything you might need, but let me know if there's anything else you need. :)
<ubottu> bug 1843196 in ubiquity-slideshow-ubuntu (Ubuntu) "[Merge Request] Updated Ubuntu Studio Slideshow" [Undecided,New] https://launchpad.net/bugs/1843196
<mwhudson> cjwatson: i presume you've seen openssh-server in eoan-proposed depends on runit-helper?
<cjwatson> mwhudson: Yes.  I don't consider this a problem, although it might need to be MIRed
<cjwatson> It's a tiny package and IMO the cost of avoiding it (in the absence of support from dh-runit for it being conditional) is greater than the cost of including it
<mwhudson> cjwatson: yeah, it's keeping it from migrating, that's how i noticed
<cjwatson> mwhudson: This will especially be true as more packages get runit support added in Debian, which I imagine will happen.  openssh is probably just one of the first ones they filed a bug against
<mwhudson> can you use runit alongside systemd?
<cjwatson> Dunno
<mwhudson> does this all have any effect on ubuntu?
<cjwatson> mwhudson: Anyway - I didn't sync it, LocutusOfBorg did it without asking me and if they had asked I would have said not to bother
<mwhudson> ah
<cjwatson> mwhudson: Other than needing an MIR I don't see why it should
<cjwatson> LocutusOfBorg: Why did you sync this, anyway?  It has no benefit to eoan
<cjwatson> Like, there ought to be some kind of reason
<mwhudson> if it's going to happen to lots of packages, MIRing the support seems like the path of least resistance
<mwhudson> or patching dh-runit to be a noop on ubuntu or something
<cjwatson> From my end I mostly just accepted an MR
<mwhudson> certainly not making some change to each package
<cjwatson> Yeah, definitely not
<cjwatson> I don't know what the Debian runit plans are in any detail
#ubuntu-devel 2020-08-31
<bdmurray> vorlon: There are a lot of new grub-installer bug failures will older media fail to install grub?
<vorlon> bdmurray: should not
<bdmurray> vorlon: there are quite a few with the following error - "grub-installer: grub-install: error: failed to register the EFI boot entry: Operation not permitted."
<sarnold> I've seen a *lot* of those
<bdmurray> Is *lot* > "quite a few" ?
<sarnold> and I don't recall seeing a satisfying explanation of what causes those
<sarnold> bdmurray: well, it's more than several by a bunch
<ahasenack> such precise metrics :)
<vorlon> bdmurray: that's not a new failure; we have a number of older reports like that, and ultimately it comes down to some sort of incompatibility between libefivar and the firmware.  (Not sure if it's a firmware bug or a client software bug)
<seb128> those grubs error are probably the most reported issues on launchpad
<seb128> it feels wrong that we never tried to figure the problem out or to properly message it to user...
<vorlon> it's firmware-dependent
<vorlon> so if someone has a machine where they can reproduce it, I'm happy to debug
<seb128> still, it's hitting lot of users and we are not doing much for them
<seb128> well, we get almost daily reports for years but we ignore those
<vorlon> but all the reports we've gotten in LP have been drive-bys from people who don't follow up
<seb128> do we have any debug instructions we could end to users to get some data?
<vorlon> I don't ignore them; I follow up and get no response
<vorlon> dmidecode?
<seb128> I would disagree with that, most reports didn't get a reply
<vorlon> then I don't know where they're filing the bugs
<seb128> ubiquity or grub2 in most cases
<seb128> anyway, if we had a stock reply with instructions on what debug commands are useful that would be nice
<bdmurray> I should be able to script commenting on the bugs with the commands and we can see what happens.
<seb128> vorlon, replying to your question, https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bugs?orderby=-id&start=0
<seb128>  1377 New bugs
<seb128> it's daily report of install failures of that type or of Invalid argument errors
<vorlon> ok well it's non-trivial to sort through the logs that get attached to ubiquity bug reports to classify these bugs
<vorlon> the ones that get filed against shim-signed and grub2 have clear logs and generally get triaged... without follow-up from submitters
<seb128> follow-up is probably tricky indeed
<seb128> some have logs though
<vorlon> again, logs are useless, this is a firmware-specific problem and no one I know has affected firmware
<seb128> e.g https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1874610 from 'boot-repair' whatever that is, e.g https://launchpadlibrarian.net/481279131/plain so it's likely those users would reply if we had followed up
<ubottu> Launchpad bug 1874610 in grub-installer (Ubuntu) "error: failed to register the EFI boot entry: Operation not permitted." [Undecided,Confirmed]
<vorlon> boot-repair ugh
<vorlon> ah that one at least lists a machine model
<seb128> we should at least be able to tweak the apport hook to collect the info that would be useful
<seb128> if what we need is a list of hardware references
<seb128> vendor/model of laptops or similar
<vorlon> what we really need isn't to know what the machine is, but to have access to an affected machine to debug
<vorlon> I don't suppose cert has a Dell Latitude e7270
<seb128> well, knowing the machine could allow us to maybe talk to the vendor to get one of those
 * vorlon nods
<vorlon> also, fwiw, at least some of these are matters of firmware configurations that are incompatible with installing Ubuntu - because they have a firmware setting that locks the boot order
<vorlon> I don't know what we can do to improve the user's experience in that case; the failure happens at the end of the install, and requires a reboot to get into the firmware to fix the setting
<sarnold> could that be tested via a no-op write at the start?
<vorlon> possibly
<sarnold> I suppose if we actually had one of those machines to tst one, we'd know :) heh
<seb128> we started poking at bios setting to warn users upfront about issues with e.g rts disk setups
<seb128> maybe we could something similar for those situations?
<seb128> (rts->rst)
<mwhudson> Trevinho: hi do you know what the story is with gjs and its autopkgtests?
<Trevinho> mwhudson: not really, I've seen the failures this morning but I was a bit busy with other sides of the stack, but it's not clear to me what's failing, given they worked fine at build time
<mwhudson> Trevinho: ah i bet they need to be run with the libffi from proposed
<mwhudson> although no, i tried that yesterday
<Trevinho> mwhudson: I need to check it closely, however, ideally we're soon importing a new mozjs and gjs versions anyways
<Trevinho> mwhudson: yeah, I was thinking libffi could be related
<Trevinho> mwhudson: iirc I built with proposed in my sbuild and they went well
<mwhudson> Trevinho: the same tests are run at build and autopkgtest time?
<mwhudson> i guess i can retry with all-proposed=1
<mwhudson> Trevinho: how soon is "soon", it's one of the things blocking the libffi transition
<mwhudson> although ghc is also blocking the libffi transition and that has a few more days of hamster-wheel spinning at best
<Trevinho> mwhudson: so, I checked I tested with proposed... but let me retry
<Trevinho> mwhudson: as per "soon", I've uploaded mozjs78 in debian and it's in new there, so would just need a sync in ubuntu (and NEW approval), same for new gjs, it's in experimental...
<mwhudson> Trevinho: well as you say the builds passed on launchpad, so if that runs the same tests then it *should* work with all-proposed=1
<mwhudson> unless it's vm vs chroot or kernel versions or some such
<Trevinho> mwhudson: I didn't rebuild in LP after transition I think, as I did it before uploading... So it likely built there with previous ffi.
<mwhudson> oh
<mwhudson> no, it built with libffi8ubuntu1 amd64 3.4~20200819gead65ca871-0ubuntu3
<Trevinho> mwhudson: ok, so rebuilt locally... and went well as well
<Trevinho> with 3.4 as you say
<mwhudson> Trevinho: ok
<Trevinho> mwhudson: I've retriggered it and worked though https://autopkgtest.ubuntu.com/packages/gjs/groovy/amd64
<Trevinho> mwhudson: oh, no sorry... i misread the number I think
<mwhudson> yeah i was going to say, the pass is the version from release
<Trevinho> anyway sure something changed ffi.. as per "not ok 7 - Unicode encoding for symbols should be functioning properly for ARGV and imports."
<Trevinho> mwhudson: installed tests have changed install location in this release, I'm not sure if this affected though
<mwhudson> Trevinho: it passed with all-proposed=1 https://autopkgtest.ubuntu.com/packages/gjs/groovy/amd64
<Trevinho> \o/
<mwhudson> yeah
<Trevinho> without all-proposed it means it uses only part of proposed or what? :o
<mwhudson> only the package being tested
<mwhudson> the idea is to test if the package will make release worse
<mwhudson> so by default you test release + the package
<mwhudson> britney has gotten a bit smarter about this recently, it's clear that gjs isn't even installable unless libffi migrates as well, so it tests gjs + libffi from proposed and everything else from release
<mwhudson> clearly there is some other package version that gjs implicitly depends on and ideally we'd figure out what and add a versioned dependency i guess
<mwhudson> but well
<Trevinho> ah i see
#ubuntu-devel 2020-09-01
<Unit193> Hrm, any idea when riscv will be available for PPAs?
<sarnold> Unit193: I've got a checkbox on one of my ppas, though maybe I have that due to magic powers
<Unit193> My box is all grayed out.
<sarnold> oh :(
<Unit193> Which normally I don't care about riscv at all, but something is failing only there, and for some silly reason it's not migrating.
<sarnold> Unit193: probably the way to find out if you can have it flipped is to file a question on the launchpad questions section
<sarnold> Unit193: I think some of the biletto ppas have it enabled too, would that be any help?
<Unit193> sarnold: Well...I don't really want special treatment if it's not really ready yet. :3
<sarnold> (I've never tried these)
<Unit193> I have no idea how to use those either. :D
<sarnold> hehe
<sarnold> Unit193: heh, was it failing package tests? https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1891686
<ubottu> Launchpad bug 1891686 in dpkg (Ubuntu) "Please default to nocheck on riscv64" [Undecided,Fix released]
<Trevinho> mwhudson: if it helps, this is the diff of what has been installed in gjs (+ proposed) vs the failing one: https://paste.ubuntu.com/p/VDTQpzVWQT/
<Trevinho> mwhudson: gobject-introspection amd64 1.64.1-1build2 looks to be a good candidate
<mwhudson> Trevinho: yeah, sounds plausible
<Trevinho> mwhudson: you can probably do a build1 with that, or I can but tomorrow
<mwhudson> Trevinho: well it's also part of the libffi transition so they will migrate together
<Trevinho> yeah, sure,  I mean if we need to have a specific b-d for britney happyness
<mwhudson> i don't think so
<mwhudson> thanks for checking though!
<Unit193> sarnold: FTBFS.
<rs2009> Hi, I noticed that the filesystem.squashfs in the Groovy Gorilla daily builds have /boot/vmlinuz and /boot/initrd.img as broken symlinks. They point to initrd.img-* and vmlinuz-*, which do not exist. I was building a custom Ubuntu ISO from an existing Ubuntu 20.10 daily ISO using the chroot method. I copied the initramfs from the /casper/ directory
<rs2009> in the custom disk and installed the linux-image in the chroot, as I needed to change the plymouth logo. I then ran update-initramfs -u -k all inside the chroot. I copied /boot/initrd.img to /casper/ and built the ISO. When I booted the ISO in a VM, it showed the plymouth boot screen for one second, after which it dropped to the BusyBox initramfs
<rs2009> prompt. Did something change in 20.10? I'm not aware of any change apart from the switch to GRUB for both BIOS and UEFI.
<ddstreet> Laney i think the autopkgtest armhf lxd-worker needs to be restarted to pick up a worker.conf change, to make haveged a long_test; it is still running it with the default timeout, though haveged was added to long_tests a week or so ago
<ddstreet> could you check it when you have a chance?
<Laney> ddstreet: it does, who deployed it?
<Laney> they might need some education
 * Laney brings out the education stick
<ddstreet> Laney you mean who deployed autopkgtest? this is on the official builders https://autopkgtest.ubuntu.com/packages/h/haveged/groovy/armhf
<Laney> who merged the config change
<ddstreet> oh, i think vorlon
<ddstreet> https://git.launchpad.net/autopkgtest-cloud/commit/?id=5763aed3a3a1c1eb3839bf74263f885ae979527e
<Laney> right, missed being done on armhf
<Laney> done now
<ddstreet> thanks!
<xnox> rs2009: is this desktop or server?
<xnox> rs2009:  did you also specify environmental variable to trigger casper initrd to be generated with uuid checks?
<rs2009> xnox: This is the desktop variant. I wasn't building a daily image, rather was chrooting into the ISO and making some changes, and then rebuilding the ISO.
<xnox> rs2009:  when rebuilding initrd you must set CASPER_GENERATE_UUID environment variable.
<xnox> rs2009:  or have grub.cfg to have boot=casper
<xnox> in kernel commandline.
<rs2009> xnox: I already have boot=casper in the kernel commandline.
<xnox> rs2009:  by default we build initrd for the iso with CASPER_GENERATE_UUID=y set, matching uuid committed on the iso in .disk/, and with clean kernel commandline.
<xnox> rs2009:  in that case i don't know why your boot failed. and you do not give enough information for me to suggest antyhing to you.
<xnox> rs2009:  it sounds like you have missbuilt your kernel/initrd pair, and it doesn't match the rest of the iso.
<rs2009> xnox: I was building a custom Ubuntu ISO from an existing Ubuntu 20.10 daily ISO (using the chroot method) when I saw that /boot/initrd.img and /boot/vmlinuz are broken symlinks in filesystem.squashfs. I copied the initramfs from the /casper/ directory in the custom disk and installed the linux-image in the chroot, as I needed to change the
<rs2009> plymouth logo. I then ran update-initramfs -u -k all inside the chroot. I copied /boot/initrd.img to /casper/ and built the ISO. When I booted the ISO in a VM, it showed the plymouth boot screen for one second, after which it dropped to the BusyBox initramfs prompt.
<rs2009> xnox: the daily ISO has 5.4.0-42-generic (checked in /lib/modules) and the initrd kernel version corresponds to it.
<rs2009> xnox: This issue does not happen with the default initramfs, rather with an initramfs built with update-initramfs
<Laney> rbalint: https://launchpadlibrarian.net/495890903/buildlog_ubuntu-groovy-armhf.mozjs78_78.2.0-1~fakesync1_BUILDING.txt.gz does this interest you?
<Laney> also, I saw your ping on that autopkgtest-cloud MR, will review this week
<xnox> rs2009:  you should have no need to install linux-image.... as that one might be different from the rest of iso.
<xnox> rs2009:  and you should restore initrd&vmlinuz from casper into where the broken links point to.
<xnox> rs2009:  and you should generate new initrd for that same kernel version, not any other different one.
<xnox> rs2009:  calling update-initramfs without environment variables set, and without correct kernel version as installed in the chroot, will not generate a complete nor valid initrd usable for cd boot.
<rs2009> xnox: The issue happens without linux-image as well. I had restored the initrd and vmlinuz to where the broken links point to. I was building the initramfs for the kernel in the ISO only. I did not know that it was mandatory to build with CASPER_GENERATE_UUID=y set. I thought it wasn't required if boot=casper was being added to the command line.
<xnox> rs2009: and how did you rebuild the initrd? which kernel version did you specify?
<xnox> rs2009:  after you build with CASPER_GENERATE_UUID=y you also need to copy out the same uuid into the iso. otherwise there will be uuid-missmatch and you will fail to boot.
<rs2009> xnox: I used update-initramfs and specified 5.4.0-42-generic which I found in /lib/modules/.
<xnox> rs2009:  yeap that's the right version number, so that should have worked.
<rs2009> xnox: I'm trying out CASPER_GENERATE_UUID=y right now
<xnox> generate initrd with UUID, copy it out and place it on the iso in .disk/ dir, remaster the iso and hopefully things will start working
<xnox> if they don't, edit kernel cmdline and append ignore_uuid to ignore uuid missmatch, to doulbe check if that's what's causing the failure to boot
<rs2009> xnox: ignore_uuid works, so it looks to be an issue with the UUID. I couldn't find the UUID in the output of update-initramfs.
<xnox> rs2009:  it's inside the initrd.... one has to unpack it to copy it into the .disk/uuid
<rs2009> xnox: Yes, I was doing that :) Thank you for your help!
<rbalint> Laney, re: MR, thanks! re: mozjs, no, sorry, i'd like to get glibc rounds done first
